FS#34568 - [linux] 3.8.4-1 fails with fsck boot error on raid0
Attached to Project:
Arch Linux
Opened by Dutch de Ruyter (straykat59) - Tuesday, 02 April 2013, 03:54 GMT
Last edited by Tobias Powalowski (tpowa) - Thursday, 23 May 2013, 19:59 GMT
Opened by Dutch de Ruyter (straykat59) - Tuesday, 02 April 2013, 03:54 GMT
Last edited by Tobias Powalowski (tpowa) - Thursday, 23 May 2013, 19:59 GMT
|
Details
Description: linux 3.8.4-1 (x86_64) fails with fsck boot
error on raid0
I am however, able to boot the linux-lts & my own custom kernels. Custom kernel is built from the abs linux package. The / partition is on a raid0 with an ext4 filesystem. fsck -f /dev/md127 comes back clean & the raid & two SATA hard drives are healthy. Additional info: Boot error message: [code]Loading ../initramfs-linix.img......ready. Probing EDD (edd=off to disable)... ok early console in decompress_kernel Decompressing Linux... Parsing ELF... done. Booting the kernel. :: running early hook [udev] :: running hook [udev] :: Triggering uevents... Waiting 10 seconds for device /dev/md127 ... :: performing fsck on '/dev/md127' ... fsck.ext2: Invalid argument while trying to open /dev/md127 /dev/md127: The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 <device> ERROR: fsck failed on '/dev/md127' :: mounting '/dev/md127' on real root mount: you must specify the filesystem type You are now being dropped into an emergancy shell. sh. can't access tty; job control turned off [rootfs /]#[/code] The error message is transcribed from a photo taken of the screen as the error is not being logged (or I can't find it). * package version(s): linux-3.8.3-1, linux-3.8.3-2 & linux-3.8.4-1 * config and/or log files etc: I have attached my config file from my current custom kernel (which does boot). [code]HOOKS="base udev autodetect modconf block mdadm_udev filesystems keyboard fsck"[/code] Steps to reproduce: Reboot into linux-3.8.4-1. I first put this up on the Kernel & Hardware forums: [url]https://bbs.archlinux.org/viewtopic.php?id=160230[/url] |
This task depends upon
The upgraded stock kernel is still failing with the same boot error.
Both the linux-lts & linux-custom kernels boot successfully.
I have for the last few weeks been recompiling the stock (abs) kernel with one item from the menuconfig uncommented each time trying to find the problem. I suspected that, because my custom kernel booted, the problem was something compiled into the stock kernel. Last night I uncommented the very unlikely:
Processor type and features ---> [ ] Symmetric multi-processing support
And the resulting kernel booted.
My CPU is the single core AMD Athlon 64 4000+.
I am not sure as to why having multi-core support in the 3.8.* kernel would cause raid to fail on a single core system?
To date, I have established that I can only get a stock Arch 3.8.* kernel to boot by disabling SMP but found my custom kernel will boot with SMP enabled!
I am now at a loss isolating this bug. Any help would be appreciated.
Bug status is the same with the stock linux failing with the same boot error.
Bug status is the same with the stock linux failing with the same boot error.
Another set of upgrades to linux & linux-lts. Linux is now at 3.8.8-2 as is my custom kernel.
Bug status is the same with the stock linux failing with the same boot error.
Bug status is the same with the stock linux failing with the same boot error.
As an added bonus my printing system now also works again after not working with linux 3.8.*.
Can I suggest holding off closing this bug report till linux 3.9 goes to stable & still boots please.
So I am back to trying to debug this issue.
Can I please again ask for help in isolating this bug.
Thanks.
Fails to boot with the usual boot error message.
I was able to get linux 3.9-2 to boot, but 3.9.1 & 3.9.2 fail!
What changed between 3.9 & 3.9.1?
Closing this one due to not reproducable anymore.