Arch Linux

Could you try to add rootdelay=10 to the kernel line in grub entry before booting?
Myself could not test usb boot images, but give it a try...

I've originally tried with rootdelay=5 with no success. When i finish installing computer i'll retry with bigger rootdelays.

No luck with rootdelay=20. Sorry for double posting i forgot i couln't edit my comments.

The only sleep period which is affected is your first, after the udevadm things. (The second makes no sense)
So a sleep time of 4s works for you. Could you try decreasing this and report how many seconds you need minimum?
AFAIK this should be handled well by udevadm, settle should wait until all usb(device) events are finished.
Maybe it's better to put additional a short sleep period after this command.

with 3s i could boot 1/3 times.
with 4s i could boot 2/3 times.
with 5s i could boot 3/3 times.

Perhaps we could add notice like: "if it hangs, try again".

This is weird. It's almost like the udev "Wait for USB devices to settle" thing is doing nothing. Didn't we have another bug report about this?

I'm having the same problem using both i686 & x86_64 .img files.
How can I apply your archiso hook? Adding rootdelay to the kernel line in grub didn't work for me.

I've build a test usb image with a possible patch (based on this Mail: http://www.archlinux.org/pipermail/arch-releng/2009-January/000045.html)
Could you test if this solves the problem? I could not test usb images myself, so i hope <g> that the patch applied correctly...
http://users.archlinux.de/~gerbra/iso/test-usb/archlinux-2009.01-1-ftp-i686.img
http://users.archlinux.de/~gerbra/iso/test-usb/md5sum.txt

@Gerhard; thanks for the effort! However, the image you provided won't boot for me. After grub has loaded, the booting gets stuck at:

/bin/run-init: opening console: No such file or directory
Kernel panic - not syncing: Attempted to kill init!

This happens just after :
Binding /bootmnt to bootmnt
Passing control to Archlinux Initscripts.. Please wait

md5sum was correct

Gerhard, I tested the same and I got another error message, I'm not sure if it is related to this problem:

GRUB Loading stage 1.5Read Error

I also got this using 2008.06 ISO. See http://bbs.archlinux.org/viewtopic.php?pid=474774#p474774

Works for me.

GerBra, could you somehow dump to some file all the stuff that is seen during boot (after dmesg and before bash)? I think i've seen some other ugly stuff there but can't be sure.

Added the ability to use the kernel command line 'rootdelay' parameter to fix this.

I tried booting this image http://dev.archlinux.org/~aaron/archiso/archlinux-2009.01-beta2-ftp-x86_64.img yesterday and rootdelay=10 or 20 appears to make no difference. I also downloaded the i686 image with the same effect.

Sam, please try it with usbdelay parameter.

It worked! Thanks :)

Im still getting some issues here. Im working off an eeepc 901.

i tried to edit the grub menue and add usbdelay=5 (also tried 10 and 20) but to no effect)
Here is the full message im getting:

::Scanning usb drives...
EXT2-fs warning (device sda1): ext2_fill_super: mounting ext3 filesystem as ext2
EXT2-fs warning (device sdb1): ext2_fill_super: mounting ext3 filesystem as ext2
ERROR: cannot fint boot device, cannot continue...
Falling back to interactive prompt
ramfs$ scsi 2:0:0:0P Direct-Access SanDisk U3 Cruzer Micro 4.04 PQ: 0 ANSI: 2
sd 2:0:0:0: [sdc] 8027793 512-byte hardware sectors: (4.11 GB/3.82 GiB)
sd 2:0:0:0: [sdc] Write Protect is off
sd 2:0:0:0: [sdc] Assuming drive cache: write through
sd 2:0:0:0: [sdc] 8027793 512-byte hardware sectors: (4.11 GB/3.82 GiB)
sd 2:0:0:0: [sdc] Write Protect is off
sd 2:0:0:0: [sdc] Assuming drive cache: write through sdc: sdc1
sd 2:0:0:0: [sdc] Attached SCSI removable disk
ramfs$

and just to make sure im doing it right but you need to edit the kernel line in grub and after the ramdisk_size=75% you add usbdelay=10 so it looks like "...ramdisk_size=75% usbdelay=10" correct?

Yeah, and I think I just noticed a problem with the way we handled usbdelay. Adding Thomas to check.

If we use usb-storage's use_delay param, we sleep for exactly that time, whereas we should probably sleep for longer than that time. Perhaps usbdelay+1. Do you think this is a good idea, or should we always set use_delay to 0 and use usbdelay for the sleep time only?

use_delay should be 0 by default, but might be longer as some old hardware could fail with it. What did we do in the old images? use_delay is 5 by default and we slept for 10 seconds, right? Let's try +1 or +2. Or make it configurable in a test image (sleep use_delay+somethingextra).

It works nice with usbdelay parameters.

It also displays someting fancy as "Usbdelay waiting for n seconds"

I have a eeepc, i try usdelay=10 without success.
After i try rootdelay=10 and work correct.
Now the installation is finish correctly.
Bye

Also tried rootdelay=10 on my EEE Box and the problem is resolved.

There was another problem when booting from USB (it's _very_ slow without disconnecting and connecting the USB stick again at boot drive prompt, but I don't think that's related to the boot loader, Syslinux in my case).

Also a problem on my IBM ThinkPad T41 using the http://dev.archlinux.org/~aaron/archiso/archlinux-2009.01-beta2-ftp-i686.img image.

'usbdelay=x' does not work, nor does 'rootdelay=1'... 'rootdelay=10' works.

Just a note: I think there is a discrepancy between the x86_64 and i686 images. i686 use rootdelay, whereas x86_64 uses usbdelay.

Can we make some tests to set nice defaults? Also, how exactly are rootdelay and usbdelay used right now? usbdelay sets use_delay=sleeptime and rootdelay only sets sleeptime and use_delay isn't touched (so in that case, rootdelay must be at least 5 seconds for the USB devices to be there).

@Thomas: rootdelay was used just as a param to 'sleep' before you figured out the usbdelay thing. It was replaced with usbdelay now, unless you think it's a good idea to support BOTH.

usbdelay sounds good, but we should figure out a good default and whether we should sleep a bit longer than the kernel waits for USB.

I added a +1 to the archiso hook

So what's our default? use_delay=0 and sleep 1? If we don't set anything, use_delay is 5, so we should at least sleep 6.

use_delay is set to usbdelay, which defaults to 0. So the defaults are use_delay=0, sleep 1

We need to built the i686 images with that as well, because all the testers above had i686. We need to know if 0 is okay here (I can test on my other machine, that can boot from USB).

rootdelay=5 was just enough for me.

@Thomas: Agreed. I will be upload beta3 ISOs in about 4 or 5 hours.

I successfully with the beta3 ISOs (with the fix to the archiso-early hook from the other bug) on x86_64, without any extra parameters (careful, the beta3 i686 ISOs don't have that fix yet).

With the beta3 ISO for i686, rootdelay didn't function anymore, but usbdelay=5 did also work for me.

On the ISOs with usbdelay, we need to figure out a good default value. For me they work with usbdelay=0 (meaning no parameter), please decrease usbdelay and tell us which is your minimum value? 5 is too much IMO (it is Linux's default though).

I tested the new img on my eee 901. The lowest value i was able to set it to to boot was usbdelay=4 which causees it to sleep for a total of 5 seconds. I tested this by trying to boot with usbdelay=3 several times but not once would it boot. Which usbdelay=4 however it has workd each time i tried it. As always YMMV!

On my new EEE Box B202 I had to use usbdelay=2. On my older P4 (an HP DC7100) I even had to use usbdelay=3.

okay, it could be decreased, but by default, the beta3 works right?

No, default is 0 right now, we should increase to 4 or 5.

Default should be 5 in the RC1 images

Can any usb user confirm that rc2 works?
See http://dev.archlinux.org/~aaron/archiso/
I personally don't use the usb stuff, but I did see with rc2-i686-core the kernel has param usbdelay=5 and the archiso hooks waits 6 (shouldn't that be 5?) seconds for usb devices to settle.

USB install iso RC2 ftp x86_64 works for me, just reinstalled my arch system with it using ext4, all fine! This on a Dell Inspiron 1520.

Good to hear!