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

lilsirecho · 2009-06-23 23:31:59

System was booting in "29" kernel with rootdelay=8...

System fails to boot USB HDD with either of two HDD's upgraded to kernel "30" with various rootdelay entries attempted.

What parameter has been changed in the new kernel? Is it mkinitcpio?

What might I try?

Last edited by lilsirecho (2009-06-30 14:15:08)

lucke · 2009-06-23 23:43:48

Downgrade the mkinitcpio to 0.5.24, rebuild the image and try booting.

lilsirecho · 2009-06-24 00:08:05

Lucke:

Thanks for reply. One of the HDD's is ext4 and the other ext3. Neither boots to enable any downgrade.

Perhaps there is a way to downgrade mkinitcpio with a Live system?

lucke · 2009-06-24 00:24:04

Get 0.5.24 from http://archlinux.alouche.net/, mount your root and boot partitions, mount --bind /dev root_partition/dev, chroot into root_partition, pacman -U that mkinitcpio.pkg.tar.gz and run mkinitcpio -p kernel26 (if using stock kernel).

lilsirecho · 2009-06-24 04:35:28

Lucke:

Perhaps I have a more serious problem than is apparent from the data given.

I have two USB HDD's, each is x86-64, one is ext4 and the other is ext3.

I used USB img to install.

My only method of arch boot is now FaunOS, an i686 system. As such, it cannot chroot into x86-64 HDD's, and never mount an ext4fs.

What might be another solution or should I wait until the smoke clears via upgrades?

The situation looks bleak...something that isn't supposed to happen when upgrading which I do very frequently.

I have no other desirable method..no other HDD's to work with in creating an x86-64 environment.

I have only FaunOS of an older kernel version but it is STABLE and virtually indestructive.

Perhaps a USB solution via flash devices will work........

I note others having similar failures after upgrade to the new kernel. Their error displays look identical to mine with reference to uuid's.

Guess I need to pray a lot!!!

My /var/cache/pacman/pkg has the previous version which I could install with pacman -Uf but I need the chroot.................

Woe is me.............

R00KIE · 2009-06-24 10:22:14

You could try to boot from the x86-64 install image and then chroot into your drives I guess.

lilsirecho · 2009-06-24 15:48:29

Rookie: Are all the needed utilities available in live usb.img to permit chroot in x86-64?

Perhaps a description of the process steps needed to chroot will be helpful.

How does the HDD to be modified appear in the Live USB boot?

I have never before ran a chroot in x86-64 and don't enjoy guessing which is likely to cause more trouble.

I have to mount the HDD partition(s) but have no ID for the HDD to begin with so the guessing begins!!!

lucke · 2009-06-24 15:58:54

You can use cfdisk to figure out your partition scheme. To chroot you just mount the partition somewhere and then "chroot /somewhere" makes /somewhere your /.

I know nothing about i686<->x86-64 chrooting, but if it indeed causes problems, do as R00KIE suggests. Chrooting is a very basic operation, any live media will do (with the possible caveat of it being the same architecture, as noted in the previous sentence).

Last edited by lucke (2009-06-24 15:59:40)

lilsirecho · 2009-06-24 16:39:52

Lucke:

Booted with USB.img , entered root and determined that HDD must be sdb with cfdisk.

mount -t ext3 /dev/sdb3 /mnt

chroot /mnt

pacman -Uf /var/cache/pacman/pkg/mkinitcpio-0.5.24-1-x86_64.pkg.tar.gz

Operation failed.

Notes: Replacing packages with -U is not supported yet....you can replace packages manually using -Rd and -U......mkinitcpio conflicts with cryptsetup.

I am confused with the remarks since -U is reported as not supported yet and yet it states to use it in the next breath!!!

Perhaps some clarification will enable better results.

I am carefully approaching this problem because of the newness of the x86-64 systems (i.e. replacing packages with -U is not supported yet).

What does one do with the cryptsetup conflict? Is it eliminated with -Rd or does another conflict erupt when mkinitcpio-0.5.24-1 is successfully enabled?

lucke · 2009-06-24 16:57:12

I presume cryptsetup is only needed for encrypted partitions. It wasn't even installed on my system. -R it and -U mkinitcpio.

R00KIE · 2009-06-24 17:09:02

As far as I know everything you need is on the boot image, besides the more important things you need are on your hard disk.
Once you chroot into your hd install it's almost the same as booting from it, you should do the same as if you want to use a 32bit chroot (at least it makes sense), here's what I would do.

Create a directory to mount your hd in /mnt (or anywhere else that you want)
Mount your HD into /mnt/hd

then mount the following:

mount --bind /proc /mnt/hd/proc
mount --bind /proc/bus/usb /mnt/hd/proc/bus/usb
mount --bind /dev /mnt/hd/dev
mount --bind /dev/pts /mnt/hd/dev/pts
mount --bind /dev/shm /mnt/hd/dev/shm
mount --bind /sys /mnt/hd/sys
mount --bind /tmp /mnt/hd/tmp

then

chroot /mnt/hd

Now you are inside your chroot and can you can downgrade the packages you need. After all is done type exit to exit the chroot and unmount all the things you have mounted before and reboot your machine, it should be working fine again.

lilsirecho · 2009-06-24 17:15:52

Lucke:

Many thanks for the replies altho not yet correcting my problem.

pacman -R cryptsetup

Removed cryptsetup.

pacman -U /var/cache/pacman/pkg/mkinitcpio-0.5.24-1-x86_64.pkg.tar.gz

Installed it.

Verified...........

pacman -Q |less

reboot

Did not unmount the partition but rebooted directly.

Reboot from HDD failed as before.

Perhaps mkinitcpio is not the culprit?

lilsirecho · 2009-06-24 17:22:07

Perhaps I should now re-install the new mkinitcpio?

lucke · 2009-06-24 17:27:11

You have to rebuild the image (mkinitcpio -p kernel26).

lilsirecho · 2009-06-24 17:28:26

Pardon my forgetfulness!!!!!!!!!!!!!!!! I am too old for this?

lilsirecho · 2009-06-24 17:45:52

Lucke:

Rebooted into live usb.img, mounted sdb3 as before, chrooted to /mnt.

mkinitcpio -p kernel26

System proceeded to exercise mkinitcpio with SUCCESS at the finish. During the procedure the following note:

Note: /etc/modprobe.d/usb-load-ehci-first does not exist.

Repeated with fallback.

Reboot to HDD gave the same error as before.

Perhaps the usb-load-ehci-first is the answer?

lucke · 2009-06-24 17:52:38

What error(s) do you get when booting?

lucke · 2009-06-24 17:57:19

You could try moving "/etc/modprobe.d/usb-load-ehci-first.conf" to "/etc/modprobe.d/usb-load-ehci-first" and perhaps adding "ehci_hcd ohci_hcd uhci_hcd" (do you know what module your disks use?) to /etc/mkinitcpio.conf - don't forget to rebuild the image.

lilsirecho · 2009-06-24 18:14:52

Answering your error request:

Notes:

waiting 8 seconds for device (root device uuid...very long ID

Root device by uuid doesn't exist...attempting to create it....

ERROR: failed to parse block device ids for (dev/disk/byuuid.................)

ERROR: unable to detect or create root device (uuid info again....)

You are being dropped to a recovery shell:

type "reboot" to reboot
type "exit" to try and continue booting
Try adding rootdelay=10 or greater to kernel line

Noted that the keyboard and mouse (usb devices) were inoperative when trying to enter data at the prompt...could not enter "reboot"

lucke · 2009-06-24 18:22:04

Now that you've learned to chroot, you can try dowgrading the kernel too.

zajca · 2009-06-24 18:34:07

I have 2 external USB HHD and not same problem.
On boot i see message

UUID="7D97-009A" Does not exist
UUID="d9472c6a-4124-441c-a38b-1ef674c2d982" Does not exist

my /etc/fstab

none                   /dev/pts      devpts    defaults            0      0
none                   /dev/shm      tmpfs     defaults            0      0


/dev/sr0 /media/cdrom   auto    ro,user,noauto,unhide   0      0
/dev/sr0 /media/dvd   auto    ro,user,noauto,unhide   0      0
UUID=4ca742e5-c01d-496b-8c86-9a9383e565a6 / reiserfs defaults 0 1
UUID=a45cdead-dbe1-4e4e-bf10-9735e1cbe41a /home reiserfs defaults 0 1
UUID=f98075a7-c0db-4caa-8ea0-4a0a2765008a swap swap defaults 0 0
UUID=bca3a41e-7944-4ac7-9711-2844676db6ed /media/disk ext3 defaults 0 0
UUID=7D97-009A /media/Muj_book vfat umask=111,dmask=000,gid=500,uid=500,iocharset=utf8,codepage=852 0 0 0 0
UUID=d9472c6a-4124-441c-a38b-1ef674c2d982 /media/pul_tera ext3 defaults 0 0

blkid:

/dev/sda1: UUID="4ca742e5-c01d-496b-8c86-9a9383e565a6" TYPE="reiserfs"
/dev/sda5: UUID="a45cdead-dbe1-4e4e-bf10-9735e1cbe41a" TYPE="reiserfs"
/dev/sda6: TYPE="swap" UUID="f98075a7-c0db-4caa-8ea0-4a0a2765008a"
/dev/sdb1: UUID="bca3a41e-7944-4ac7-9711-2844676db6ed" SEC_TYPE="ext2" TYPE="ext3"
/dev/sdg1: LABEL="Muj_book" UUID="7D97-009A" TYPE="vfat"
/dev/sdh1: LABEL="pul_tera" UUID="d9472c6a-4124-441c-a38b-1ef674c2d982" TYPE="ext3"

after boot i try "mount /dev/sdh1 /media/pul_tera" and its OK

my everything.log

Last edited by zajca (2009-06-24 18:44:21)

lilsirecho · 2009-06-24 18:36:13

Lucke: Rookie:

Rookie responded with a large entry calling for many mounts...is all that pertinent?

His post is earlier in this thread.

If I downgrade the kernel, what happens to the mkinitcpio change I have made?

To downgrade the kernel, I assume all I need to do is use : pacman -U (kernel package in /var/cache/pacman/pkg).

However, this may not work since "-U is not yet implemented".

What is correct procedure?

lucke · 2009-06-24 18:47:02

-U is implemented, replacing conflicting packages using -U isn't (i.e. you have to -R the conflicting package first).

mkinitcpio is run in kernel26.install. so it gets run when you -U kernel.pkg.tar.gz.

Binding /dev is needed for mkinitcpio to work, all other binds don't seem necessary.

It's as you said, just run "pacman -U kernel.pkg.tar.gz" in the chrooted environment with bound /dev (you can bind /proc too, to be on the safe side), preferably with mkinitcpio 0.5.24 and with "conf" removed from that usb-ehci file.

Last edited by lucke (2009-06-24 18:49:39)

lilsirecho · 2009-06-24 18:51:33

Lucke:

I hope I understand correctly...just run pacman -U (former kernel26 .pkg.tar.gz from /var/cache/pacman/pkg)...

I will do same........

lilsirecho · 2009-06-24 19:11:20

Lucke:

Performed the install of kernel26-2.6.29.4-1-x86_64.pkg.tar.gz....mkinitcpio reported same missing /etc/modprobe.d/usb-load/ehci-first..error but reported SUCCESS.

Verified kernel was installed.

Rebooted to HDD and same result..no boot.

Gotta believe the usb error is the problem...

Do you have such an entry in /etc?

Since I am booting from usb it does seem pertinent.

There were many upgrades when I did the kernel upgrade in addition to the "30" version.

Perhaps I should check the pacman log?

Arch Linux

#1 2009-06-23 23:31:59

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

#2 2009-06-23 23:43:48

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

#3 2009-06-24 00:08:05

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

#4 2009-06-24 00:24:04

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

#5 2009-06-24 04:35:28

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

#6 2009-06-24 10:22:14

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

#7 2009-06-24 15:48:29

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

#8 2009-06-24 15:58:54

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

#9 2009-06-24 16:39:52

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

#10 2009-06-24 16:57:12

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

#11 2009-06-24 17:09:02

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

#12 2009-06-24 17:15:52

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

#13 2009-06-24 17:22:07

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

#14 2009-06-24 17:27:11

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

#15 2009-06-24 17:28:26

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

#16 2009-06-24 17:45:52

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

#17 2009-06-24 17:52:38

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

#18 2009-06-24 17:57:19

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

#19 2009-06-24 18:14:52

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

#20 2009-06-24 18:22:04

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

#21 2009-06-24 18:34:07

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

#22 2009-06-24 18:36:13

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

#23 2009-06-24 18:47:02

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

#24 2009-06-24 18:51:33

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

#25 2009-06-24 19:11:20

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

Board footer