Created attachment 367318 [details] excerpt from syslog (I am honestly not sure where to file this bug. It might be more appropriate on kernel.org, but although the problem is showing up in the ext2 file system module, I am not convinced it is completely kernel/filesystem related: everything used to work, and has only recently stopped, leading me to suspect some recent upgrade to some other package has destabilized the system. I am not sure how to track down what, and hope that someone can provide some debugging guidance.) /boot is an ext2 file system (the only ext2 system on this machine). It is not mounted by default; when needed, I manually mount it. This has always worked in the past, but not the last couple of times I've tried to access it. The partition mounts without error, but as soon as I try to read from it (via "ls"), my terminal responds with "Killed", and I get a lot of syslog output (which I've attached), starting with the lines: BUG: unable to handle kernel paging request at ff96b004 IP: [<f8026506>] ext2_get_page.clone.10+0xe6/0x261 [ext2] *pde = 377fd067 *pte = 00000000 Oops: 0000 [#1] SMP There is nothing actually wrong with the /boot partition: GRUB and the kernel both work correctly to boot the machine. It is only on the running system that I can no longer access /boot. The consequent problem is that, without access to /boot on the running system, I can do nothing to change the kernel or boot loader. A newer kernel may have already fixed the bug that syslog is reporting, or a change to the current kernel's config may solve the issue or provide more info helpful to debugging. But until I can access /boot, I cannot change the kernel.
Created attachment 367320 [details] /usr/src/linux/.config
Created attachment 367322 [details] emerge --info
3.2.12 is a 2 years old kernel; can you try the newest kernel and report back?
I would very much like to; however, for the reason explained in the last paragraph of comment #0, I cannot until this bug is resolved.
(In reply to Dave Kemper from comment #4) > I would very much like to; however, for the reason explained in the last > paragraph of comment #0, I cannot until this bug is resolved. Can you try to access it from a livecd? Might it be the case that there is a problem with the partition and not with the kernel?
Hi Tom, It seemed unlikely there was a problem with the partition; if /boot were corrupted, the machine wouldn't be able to boot. But I did try booting the machine from a (non-Gentoo) CD-based Linux. I was then able to mount /boot and successfully access it. So the partition is fine.
Is this feasible? Compile a kernel while in the livecd. mount the /boot Copy over the new kernel, fix the grub cfg and boot into it?
Mike: Yes, that did the trick. I upgraded the kernel and /boot now mounts successfully. Thank you!
Awesome.
