[gentoo-user] Re: Need help interpreting kernel panic
Johannes Rosenberger writes: > I found something interesting: >> request_module: runaway loop modprobe binfmt-464c >> Short answer: If you are getting this error right after linux kernel >> initialization, you are likely booting a 32-bit kernel with a 64-bit OS. >> >> Long answer: If you boot a 32-bit kernel with a 64-bit OS, when the >> kernel tries to start /sbin/init (a 64-bit binary), it won't recognize >> the binary format, and it'll try to load the binfmt-464c kernel >> module, which is ELF support. (ELF support is generally compiled into >> the kernel, not built as a module, by the way.) >> >> The reason for the loop error is that the kernel is trying to invoke >> modprobe to load the module, and modprobe is itself an ELF binary, >> resulting in a recursion loop... Just a bit ago I had one of those slap myself in the head moments. Just realized that the host I took the .config to do oldconfig from is a 32 bit host. Now, I did set the switch when menuconfig rolled around for a 64 bit kernel but still the whole thing is based on an a .config from a 32 bit host running a 32 bit kernel. So no telling what all might get jimmied up in that mess. I'd already trashed all disks from the test vm and am starting from scratch again but this time I won't get tricky with the .config file. Had I not done so (trashed the disks from my first go around), I probably could have just reconfigged the kernel from scratch and been ok...
[gentoo-user] Re: Need help interpreting kernel panic
Johannes Rosenberger writes: > I found something interesting: >> request_module: runaway loop modprobe binfmt-464c >> Short answer: If you are getting this error right after linux kernel >> initialization, you are likely booting a 32-bit kernel with a 64-bit OS. >> >> Long answer: If you boot a 32-bit kernel with a 64-bit OS, when the >> kernel tries to start /sbin/init (a 64-bit binary), it won't recognize >> the binary format, and it'll try to load the binfmt-464c kernel >> module, which is ELF support. (ELF support is generally compiled into >> the kernel, not built as a module, by the way.) >> >> The reason for the loop error is that the kernel is trying to invoke >> modprobe to load the module, and modprobe is itself an ELF binary, >> resulting in a recursion loop... > -- > http://saalwaechter-notes.blogspot.de/2008/10/requestmodule-runaway-loop-modprobe.html > > I hope it helps. Sounds promising, but a couple of things makes it seem unlikely. 1) I'm installing from a 64 bit ISO on a a 64 bit host. 2) one of the very earlier things on menuconfig one is asked if they want a 64 bit kernel... I checked that. At least this is true of kernel 4.9.6-r1 I'm going to verify that again in a bit.
Re: [gentoo-user] Re: Need help interpreting kernel panic
On 11.02.2017 21:18, Harry Putnam wrote: > Johannes Rosenberger writes: > >> On 11.02.2017 20:47, Rich Freeman wrote: >>> On Sat, Feb 11, 2017 at 2:12 PM, Harry Putnam wrote: Again I get a kernel panic but this time its different. It seems to mount the disks ok but then fails to find a working `init' command. Checking that with sysrescueCD I see /sbin/init does exist on that new vm. and is executable. The disk setup is sda1=/boot sda2=swap sda3=/home sda4=/ >>> My guess is that it is mounting the wrong filesystem as root. It >>> might be detecting /dev/sdb as /dev/sda. Also, the root device might >>> be named /dev/xda4 depending on the kernel/etc. Systemrescuecd isn't >>> using the same kernel/etc so it might not see the disks the same way. >>> >>> An initramfs with root=UUID="505f850e-b26a-4d0f-a02f-6ba573a48ad8" (or >>> a label) would be a more reliable way to handle this, or you can >>> probably just fiddle with the device names until you stumble on the >>> right one. >>> >>> >> Well, if you look at the kernel messages you see that the init is found >> but not executable (error -8). I don't know what the error number means, but >> have you set CONFIG_BINFMT_ELF and CONFIG_BINFMT_SCRIPT in your .config? >> Is /bin/sh executable? > Error means ENOEXEC I think from browsing a bit on google > > About BINFMT > > Yes. (grepping from chroot at /usr/src/linux/) > grep BINFMT .config > > CONFIG_BINFMT_ELF=y > CONFIG_BINFMT_SCRIPT=y > # CONFIG_BINFMT_AOUT is not set > # CONFIG_BINFMT_MISC is not set > > > I just chrooted and re-emerged sysvinit but no help. From chroot, I > ran /sbin/init 3 and it did try to go to runlevel 3 (just brought me > out of chroot), so it appears to be working. > > The stuff about `runaway loop' at modprobe (in the kernel messages) > seems like it might mean something. > > I think I'll test about modprobe for that module binfmt-46-4c > > > > > I found something interesting: > request_module: runaway loop modprobe binfmt-464c > Short answer: If you are getting this error right after linux kernel > initialization, you are likely booting a 32-bit kernel with a 64-bit OS. > > Long answer: If you boot a 32-bit kernel with a 64-bit OS, when the > kernel tries to start /sbin/init (a 64-bit binary), it won't recognize > the binary format, and it'll try to load the binfmt-464c kernel > module, which is ELF support. (ELF support is generally compiled into > the kernel, not built as a module, by the way.) > > The reason for the loop error is that the kernel is trying to invoke > modprobe to load the module, and modprobe is itself an ELF binary, > resulting in a recursion loop... -- http://saalwaechter-notes.blogspot.de/2008/10/requestmodule-runaway-loop-modprobe.html I hope it helps.
[gentoo-user] Re: Need help interpreting kernel panic
Johannes Rosenberger writes: > On 11.02.2017 20:47, Rich Freeman wrote: >> On Sat, Feb 11, 2017 at 2:12 PM, Harry Putnam wrote: >>> Again I get a kernel panic but this time its different. It seems to >>> mount the disks ok but then fails to find a working `init' command. >>> >>> Checking that with sysrescueCD I see /sbin/init does exist on that new vm. >>> and is executable. >>> >>> The disk setup is sda1=/boot sda2=swap sda3=/home sda4=/ >>> >> My guess is that it is mounting the wrong filesystem as root. It >> might be detecting /dev/sdb as /dev/sda. Also, the root device might >> be named /dev/xda4 depending on the kernel/etc. Systemrescuecd isn't >> using the same kernel/etc so it might not see the disks the same way. >> >> An initramfs with root=UUID="505f850e-b26a-4d0f-a02f-6ba573a48ad8" (or >> a label) would be a more reliable way to handle this, or you can >> probably just fiddle with the device names until you stumble on the >> right one. >> >> > Well, if you look at the kernel messages you see that the init is found > but not executable (error -8). I don't know what the error number means, but > have you set CONFIG_BINFMT_ELF and CONFIG_BINFMT_SCRIPT in your .config? > Is /bin/sh executable? Error means ENOEXEC I think from browsing a bit on google About BINFMT Yes. (grepping from chroot at /usr/src/linux/) grep BINFMT .config CONFIG_BINFMT_ELF=y CONFIG_BINFMT_SCRIPT=y # CONFIG_BINFMT_AOUT is not set # CONFIG_BINFMT_MISC is not set I just chrooted and re-emerged sysvinit but no help. From chroot, I ran /sbin/init 3 and it did try to go to runlevel 3 (just brought me out of chroot), so it appears to be working. The stuff about `runaway loop' at modprobe (in the kernel messages) seems like it might mean something. I think I'll test about modprobe for that module binfmt-46-4c
