Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#28111 - System does not boot with vanilla kernel 3.2.2

Attached to Project: Arch Linux
Opened by Andrej Podzimek (andrej) - Thursday, 26 January 2012, 10:44 GMT
Last edited by Dave Reisner (falconindy) - Friday, 27 January 2012, 15:48 GMT
Task Type Bug Report
Category Kernel
Status Closed
Assigned To Dave Reisner (falconindy)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

I use vanilla kernels with ArchLinux. Everything worked fine till 3.2.1 (with mkinitcpio image generated before the recent updates of udev and kmod), but there is an issue with 3.2.2, possiby related to mkinitcpio / udev / kmod: The system does not boot at all, stopping in the boot image phase with weird messages like this:

/init: line 10: modprobe: not found
...
/init: line 36: udevadm: not found

Both modprobe and udevadm are available and the image is of almost the same size as the (working) one for a 3.2.1 kernel. The system will boot after issuing the following commands:

modprobe ahci
lvm vgchange -a y
exit

So obviously, the mkinitcpio image is capable to boot the system and contains all the necessary modules and binaries. In spite of that, it produces those weird "not found" messages (that seem to be totally unrelated to the reported lines of the /init script) and drops into the recovery shell.

The working 3.2.1 kernel has a mkinitcpio image generated *before* the recent kmod and udev updates. I haven't tried whether it would fail with the current tools, but could do so if anyone is interested.
This task depends upon

Closed by  Dave Reisner (falconindy)
Friday, 27 January 2012, 15:48 GMT
Reason for closing:  Not a bug
Additional comments about closing:  base must be the first hook. This should probably be documented more clearly somewhere.
Comment by Dave Reisner (falconindy) - Friday, 27 January 2012, 02:00 GMT
Please attach the faulty initramfs and your config.
Comment by Max Fierke (m4xm4n) - Friday, 27 January 2012, 04:11 GMT
I too am getting these errors but am unable to confirm whether the given commands will allow it to continue to boot as I am using a usb keyboard and the modules were not loaded by udev.

I'm using the stock config and preset on x86_64.

@Dave: I can't provide the files, because I can not boot into Arch and have no other operating system installed for which I can use to access the files. I also have no functioning optical drive for booting a Live CD.
Comment by Dave Reisner (falconindy) - Friday, 27 January 2012, 13:33 GMT
Please don't +1 this if you can't perform the simple task of providing the files I've asked for.
Comment by Andrej Podzimek (andrej) - Friday, 27 January 2012, 14:33 GMT
First of all, I think that anyone can and should +1 whatever they consider important, no matter if they can / want / cannot perform a task.
The requested files are attached.
Comment by Dave Reisner (falconindy) - Friday, 27 January 2012, 14:38 GMT
I asked for the entire initramfs (I guess i wasn't quite clear). If you consider an issue important, there's a vote button.
Comment by Andrej Podzimek (andrej) - Friday, 27 January 2012, 14:39 GMT
I cannot attach the faulty initramfs. It must have been skipped due to the limit of 2 MB per uploaded file. The image is about 3 MB big. So here it is: https://andrej.podzimek.org/initramfs.img
Comment by Andrej Podzimek (andrej) - Friday, 27 January 2012, 14:42 GMT
If you ask someone to attach a file, although you *know* this file may exceed the size limit, you can't be surprised when he/she doesn't do it immediately. :-)

Update: Here is a *working* initramfs created for a 3.2.1 kernel a week ago or so: https://andrej.podzimek.org/initramfs-old.img
Comment by Karol Błażewicz (karol) - Friday, 27 January 2012, 14:44 GMT
> First of all, I think that anyone can and should +1 whatever they consider important
I think that's what the votes are for.
Comment by Dave Reisner (falconindy) - Friday, 27 January 2012, 14:44 GMT
Your problem is that you have v86d before base. The symlink from /sbin -> /usr/bin doesn't get created properly and calls to /sbin/modprobe fail. busybox ash fails hard at counting.
Comment by Andrej Podzimek (andrej) - Friday, 27 January 2012, 15:07 GMT
Yes, you're right. It works when I move v86d elsewhere. (The previous versions of mkinitcpio/udev/module-init-tools tolerated my wrong configuration somehow.)

Loading...