new kernel breaks boot...rootdelay=xx does not permit boot(solved)

lucke · 2009-06-24 19:22:37

mkinitcpio 0.5.24 looks for "usb-load-ehci-first" and 0.5.25 for "usb-load-ehci-first.conf". That's why I suggested removing the "conf" from the filename.

I presume it's the mkinitcpio/kernel26 issue, can't think of anything else that might be involved. rootdelay behaviour has been changed a bit in mkinitcpio 0.5.25, that's why I suggested using 0.5.24.

Try kernel 2.6.29, mkinitcpio 0.5.24 and removing "conf" from the filename.

lilsirecho · 2009-06-24 20:31:36

Lucke:

Assuming the kernel is "29" and mkinit (29) I have removed .conf from the modprobe.d usb-load-ehci-first.conf with nano saved without .conf. Verified it was removed with ls showing .....usb-load-ehci-first

Rebooting gave the same problem on the HDD.

I suspect there are other .conf problems within this HDD but don't have a clue as to where they may be.

Don't know why the usb file is within modprobe.d among the blacklists group since it isn't blacklisting anything!!!!

Again, when booting from the HDD, I have no keyboard or mouse (both usb) so I cannot enter "reboot" nor "exit".

It seems that -load-ehci first is not active....the HDD is connected to a USB 2.0 port and the keyboard and mouse to another USB 2.0 port with a hub to allow keybd,mouse,and usb audio.

This arrangement has been active for a loooong time prior to this problem.

It seems related to the .conf message given in the arch news but how is beyond me because I don't follow the explanation nor the cause of .conf changes as given therein.

Perhaps I need to rerun mkinitcpio -p kernel26?

lucke · 2009-06-24 20:37:22

You need to rerun mkinitcpio -p kernel26 after you remove "conf".

I never had a working USB keyboard when boot was failing during initrd phrase.

lilsirecho · 2009-06-24 21:00:00

Verified all elements..kernel.mkinit, and usb file.

Ran mkinitcpio -p kernel26 and had no usb errors such as before. Reboot into HDD and result was identical to all others.

lucke · 2009-06-24 21:09:19

Hm, perhaps it's not a mkinitcpio problem then - unless we've missed something. Did you try running fallback images as well?

I don't have a USB disk to look into the problem myself, alas.

There was a bunch of other updates as well, as you've noted - filesystem, module-init-tools, udev, klibc stuff. Perhaps you should just downgrade everything liable.

lilsirecho · 2009-06-24 21:48:35

Ran fallback with same result.

During mkinitcpio -p kernel26 activity there occurred a ...find: /sys/devices ...no such file or directory....

This appeared during the default sequences but not during th fallback sequences....for what its worth.

The .conf requirement is now the norm according to my reading of the arch news. I do not understand the extent of such .conf arrangements from reading the statement. Most info is abbreviated too much and loses impact and does not communicate important aspects.

I think I will try the previous module-init-tools package and then quit.

R00KIE · 2009-06-25 11:29:01

I would mount them all anyway, if it is needed for a 32bit chroot to work in a 64bit OS then it should also be needed for a 64bit chroot on a 64bit OS.
If it really is needed or not ... give it a try until it doesn't complain, I know that for some things you don't need to mount so many things but when in doubt mount them all anyway , for the chroot I have followed this guide in the wiki http://wiki.archlinux.org/index.php/Arc … bit_system

lilsirecho · 2009-06-25 16:44:53

Lucke and Rookie:

Many thanks for the many responses.

I have determined the cause for my difficulties.

It seems the ich7 chip in my mobo has failed...slowly but surely and now cannot boot even the Live Faunos system. The usb devices fail to be recognized.

I am on with another computer in i686 and may upgrade the mobo on the failed system.

I plan to have the mobo checked soon and then make the decision for upgrade.

Quite a coincidence since it happened at the upgrade to a new kernel.

Nothing lasts forever!!!!

zoidby · 2009-06-26 18:35:03

Hi,

after i upgraded to kernel .30 i got:

Waiting 10 seconds for device 801 ...

I'm using LILO so i had to change

root=/dev/sda1

to

append="root=/dev/sda1"

in the lilo.conf

hth, zoidby

lilsirecho · 2009-06-26 23:05:47

zoidby:

My system boots from grub using the standard install details for x86-64 system.

Both ext4 and ext3 HDD's fail to boot after upgrade to kernel "30".

Each HDD is connected to usb and usb boot is enabled for the selected usb HDD.

Worked in previous kernel but not now.

Usb flash devices permit boot in Live system.

Root uuid is not detected in usb HDD's. Rootdelay=16 does not solve the problem. The error message does not necessarily reflect the exact error but provides a suggestion for troubleshooting.

Both HDD's are x86-64 devices and I feel that is the problem with the new kernel upgrade.

Some indications suggest that mkinitcpio has been modified which causes the difficulty.

Pacman downloaded about thirty items along with the kernel.

I am using a Live system for arch at this time.

Perhaps the grub menu list needs a change? Why that would happen is not apparent.........

lilsirecho · 2009-06-27 17:58:23

Installed x86-64 in new HDD with usb.img flash device.

After completing the install with grub, rebooted.

Received the identical failure as obtained with the upgraded HDD's in this thread. Root device not recognized, probably due to failed USB during initrd.

lilsirecho · 2009-06-30 14:14:00

Problem solved using wiki for kernel re-install info.

Initial problem suspected to be cause by defective usb hdd enclosure which does not now boot the latest kernel.

Another usb enclosure is able to boot the system.

Initial problem was caused by defective usb enclosure used during upgrade.

Many kudos to the support given by rookie and lucke!!!

Beware the hardware!!!!!

sfauzia · 2009-07-04 05:03:17

I had a very similar issue with the latest kernel from testing (2.6.30.1-1). When I would startup my computer, my computer would begin an endless cycle of rebooting (going only barely past the grub screen, just to where it mounts root). Had to use the live CD to downgrade before it would boot normally.

I was using a more recent version than 2.6.30-5 before the upgrade which caused the problems, I think, but I downgraded to 2.6.30-5 as it was the most recent version from http://archlinux.alouche.net.

[edit] Nevermind, my problem relates to the problem everyone else is having if they are using the JFS filesystem. Simply chrooting into my hard disk from the live CD and upgrading the kernel from there fixes this. [/edit]

Last edited by sfauzia (2009-07-08 19:07:37)

Arch Linux

#26 2009-06-24 19:22:37

Re: new kernel breaks boot...rootdelay=xx does not permit boot(solved)

#27 2009-06-24 20:31:36

Re: new kernel breaks boot...rootdelay=xx does not permit boot(solved)

#28 2009-06-24 20:37:22

Re: new kernel breaks boot...rootdelay=xx does not permit boot(solved)

#29 2009-06-24 21:00:00

Re: new kernel breaks boot...rootdelay=xx does not permit boot(solved)

#30 2009-06-24 21:09:19

Re: new kernel breaks boot...rootdelay=xx does not permit boot(solved)

#31 2009-06-24 21:48:35

Re: new kernel breaks boot...rootdelay=xx does not permit boot(solved)

#32 2009-06-25 11:29:01

Re: new kernel breaks boot...rootdelay=xx does not permit boot(solved)

#33 2009-06-25 16:44:53

Re: new kernel breaks boot...rootdelay=xx does not permit boot(solved)

#34 2009-06-26 18:35:03

Re: new kernel breaks boot...rootdelay=xx does not permit boot(solved)

#35 2009-06-26 23:05:47

Re: new kernel breaks boot...rootdelay=xx does not permit boot(solved)

#36 2009-06-27 17:58:23

Re: new kernel breaks boot...rootdelay=xx does not permit boot(solved)

#37 2009-06-30 14:14:00

Re: new kernel breaks boot...rootdelay=xx does not permit boot(solved)

#38 2009-07-04 05:03:17

Re: new kernel breaks boot...rootdelay=xx does not permit boot(solved)

Board footer