Kernel maldito

73du4rd0
(usa Void Linux)

Enviado em 04/09/2017 - 11:58h

Ultimamente uma instalação minha do gentoo deu kernel panic, tentei recuperar com o genkernel e mesmo assim não funcionou (wtf?), sendo que sempre fazia a instalação compilando o kernel "manualmente" e ia de boas, porém atualmente sempre que tento instalar a distro dá kernel panic assim que o sistema liga. Passei pelo mesmo que o Uruk tá passando e acabei desistindo depois de compilar o kernel mais de 9 vezes, usando todo tipo de config aleatória que funcionava em outras distros, inclusive a do slackware huge, tá [*****]. Vou ver se reinstalo do 0 de novo depois, seguindo a wiki nos mínimos detalhes, porque não sei onde posso tá errando que dá kernel panic aleatoriamente.

removido
(usa Nenhuma)

Enviado em 04/09/2017 - 12:16h

Um chute de alguém completamente leigo que pode estar passando bem longe, mas lá vai.

Se o segundo HD era o sdb e quando ele troca passando para primeiro, não deveria ser setado como sda? Se isso faz sentido e foi feito, não deve ter ficado em algum lugar configurado como sdb e acaba conflitando com o kernel?

"Failure is an option here. If things are note failing, you are not innovating enough" - Elon Musk

luiztux
(usa Gentoo)

Enviado em 04/09/2017 - 12:25h

Eu também estou pensando a mesma coisa...


-----------------------------------''----------------------------------

Larry, The Cow, uses Gentoo GNU/Linux

^__^
(oo)
(__)

"If it moves, compile it."

removido
(usa Nenhuma)

Enviado em 04/09/2017 - 13:31h

Não faz sentido.
Meu fstab e extlinux.conf (configuração do syslinux, o gerenciador de boot) estão com o UUID, nada de caminhos dentro do /.
Meu celular não tem câmera, vou tentar copiar o erro na íntegra. Compilarei o mesmo .tar.xz com a mesma config do kernel vannila no Alpine e Gentoo. Aguardem umas 2 horas, também tenho que fazer outras coisas.

Nem tudo que é ouro fulgura, nem todo vagante é vadio.

O velho que é forte perdura, raiz funda não sofre frio.

Das cinzas um fogo há de vir, das sombras a luz vai jorrar;

A espada há de, nova, luzir, 

O sem corôa há de reinar  

Buckminster
(usa Debian)

Enviado em 04/09/2017 - 13:32h

msg pci 0000:00:01.0: PCI bridge window [io 0xe00-0exefff]

Veja a mensagem acima, está claro, é um problema com o Windows!

Mas falando sério, pelo que eu li nos links

https://sourceforge.net/p/android-x86/kernel/ci/f3dbd802b3caf8da92173870bc270dda6b3f84ba/log/?path=/...

e

https://unix.stackexchange.com/questions/205253/syslog-flooded-with-pci-00000014-4-pci-bridge-to-bus...

esses problemas são, ou bug no kernel ou alguma configuração que tu fizeste no kernel ou algum problema com alguma limitação de algum barramento pci (hardware).

E veja se na mensagem do kernel panic aparece algo semelhante a isso:

kernel panic - not syncing: Fatal exception in interrupt

Como resolver?
Primeiro tu terá que identificar qual dos três problemas está causando o kernel panic.

Veja isto:
When the CRS Software Visibility feature is disabled (as it is by default),
a Root Complex must handle a CRS Completion by re-issuing the Configuration
Request. This is invisible to software. From the CPU's point of view, an
endpoint that always responds with CRS causes a hang because the Root
Complex never supplies data to complete the CPU read.

Quando o recurso CRS Software Visibility está desativado (como é por padrão),
um Complexo de Raiz deve lidar com uma Conclusão de CRS ao reemitir o pedido de Configuração.
Isso é invisível para o software. Do ponto de vista da CPU, um
ponto final que sempre responde com CRS causa um bloqueio porque o Root Complex
nunca fornece dados para completar a leitura da CPU.

Talvez o texto acima tenha alguma coisa a ver.

Veja aqui o que é Root Complex: https://en.wikipedia.org/wiki/Root_complex

E antes de me xingar de novo, estou somente dando algumas sugestões que, talvez não se apliquem ao teu caso, mas talvez sejam uma luz.

kowalskii
(usa Ubuntu)

Enviado em 04/09/2017 - 13:40h

Postando só para acompanhar. Boa sorte.

CheshireCat
(usa Linux From Scratch)

Enviado em 04/09/2017 - 13:53h

[2]

removido
(usa Nenhuma)

Enviado em 04/09/2017 - 14:25h

Todos os logs que consegui coletar: http://ix.io/zAT
Vou fazer o restante, volto já com mais novas.

Nem tudo que é ouro fulgura, nem todo vagante é vadio.

O velho que é forte perdura, raiz funda não sofre frio.

Das cinzas um fogo há de vir, das sombras a luz vai jorrar;

A espada há de, nova, luzir, 

O sem corôa há de reinar  

Grinder
(usa Slackware)

Enviado em 04/09/2017 - 16:13h

Outra coisa nada a ver, mas vai que...

Eu pensava que você estivesse usando mbr/dos, mas pelo visto você disse que está usando uefi.
Bom, seu hd deve estar em GPT então você terá que criar uma partição uefi correto? Mas pelo o que eu vi você está usando uma partição /boot em ext2

Já tentou criar uma partição /boot/efi em fat32 e alterar seu fstab para o boot do kernel ser feito na tua partição uefi /boot/efi
O estranho também é o genkernel all não estar criando o initramfs, era para criar.

/dev/sda1		/boot/efi	vfat		defaults			1	0 

Não esquece de alterar o bootloader
grub-install --target=x86_64-efi --efi-directory=/boot/efi
grub-mkconfig -o /boot/grub/grub.cfg

Caso não tenha gerenciador de entradas uefi no seu pc, copie
/boot/efi/EFI/gentoo/grubx64.efi para /boot/efi/EFI/Boot/bootx64.efi

EDIT: caso queira ter um initramfs


EDIT2:

Tirei do wiki do gentoo


- - - - -
www.github.com/ericfernandesferreira

albfneto
(usa openSUSE)

Enviado em 04/09/2017 - 16:59h

Uruk, Gentoo é muito sensível ao seu hardware...

o fato de não estar funcionando, pode ser as FLAGS... seu make.conf é muito enxuto?
pq se for enxuto demais,pode não compilar legal

No Gentoo, eu costumo usar o kernel geral dele, recomendado, o gentoo-sources
às vêzes uso o git-sources....

experimentou a compilação geral, do kernel completo? com genkernel? é um kernel para hardware geral, mas é rápido, não é lento. Comigo, Genkernel costuma funcionar bem.

agora, se tiver UEFI, precisa fazer uma partição /boot/efi. Aí já não tenho prática, nenhum dos meus comps tem UEFI,

. o Ext2, vc só precisa se fez partição de /boot separada, e mesmo assim dá para fazer em ext4, por exemplo. até sem partição de boot separada, dá;

tem como postar o log do erro que o kernel dá com o OpenRC?
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
Albfneto,
Ribeirão Preto, S.P., Brasil.
Usuário Linux, Linux Counter: #479903.
Distros Favoritas: Sabayon, Gentoo, openSUSE, Mageia e OpenMandriva.

removido
(usa Nenhuma)

Enviado em 04/09/2017 - 18:10h

Sei do lance com o UEFI, mas eu não gosto de instalar nesse modo. Já levei Arch e Debian em dualboot assim, mbr e BIOS. Também já utilizei UEFI, com o Void é Alpine.
Também sei do make.conf. Todos os kernels que conpilei foi com make -j2.
Escolhi ext2 por não ter journal. Vou mover os arquivos de /boot para uma só partição, /, em ext4 e tentarei.
Já fiz initramfs, com o Dracut, também deu errado.

Nem tudo que é ouro fulgura, nem todo vagante é vadio.

O velho que é forte perdura, raiz funda não sofre frio.

Das cinzas um fogo há de vir, das sombras a luz vai jorrar;

A espada há de, nova, luzir, 

O sem corôa há de reinar  

removido
(usa Nenhuma)

Enviado em 04/09/2017 - 18:59h

Talvez seja a falta da initramfs. Gentoo é muito chato com relação a iniciar sem ela. Outro ponto é que a configuração padrão do kernel, feita pelo genkernel espera uma. O Gentoo também aconselha o parâmetro 'rootfstype=type' na linha de comando do kernel.