You are not logged in.
Hello.
When i'm boot my arch i got message waiting 10 secdonds for device /dev/sda1 (arch partition).
I have in mkinitcpio this modules:
ahci ext4 scsi_mod sd_mod libata.
That's all what can i do run arch wihout waiting 10 secodns?
Last edited by SpeedVin (2009-06-26 13:56:57)
Shell Scripter | C/C++/Python/Java Coder | ZSH
Offline
this is added option for "lazy" devices that take time to mount (eg some problems with ext4), system will boot as soon as device is available though. So ten sec for slow and less for fast. In other words, nothing to worry about.
Offline
That's strange before i don't get this message.
Shell Scripter | C/C++/Python/Java Coder | ZSH
Offline
I assume that this was added because a lot of people had problems with ext4 and boot.
Offline
Can i remove that from kernel (compile myself) ?
Shell Scripter | C/C++/Python/Java Coder | ZSH
Offline
I don't have this message in my custom kernels, but I don't think that this is worth your effort (re-compile to get rid of some benign message). If you want to build kernel from AUR, then you will need to check out provided config files. I am building kernels from vanilla (www.kernel.org)
Offline
considering i just spent some time yesterday shaving down my bootup time by a few seconds, this is rather annoying. if this was added to help a few people with ext4 problems, couldn't a kernel option be added for those people instead of adding 10 seconds to everyone's boot time?
i'm using reiserfs, and it does wait a whole 10 seconds before continuing after this message, despite broch's suggestion that it waits only until the device is available.
Offline
I've got the same delay/message with the new kernel for md0 (raid swap) - I'm pretty sure the device didn't need any additional time before. It took much less than 10 seconds to access it while resuming from suspend-to-disk.
I think I saw another related message a screen or so above, but it scrolls away too fast to read it and It shows in no log (same as the 10 seconds message - that's what my "how see boot messages that don't show [...]"-newbie-subforum-question is for ).
Last edited by whoops (2009-06-23 21:45:05)
Offline
this is a misunderstandig. You should interpret this message as follows:
kernel:
O.K. I will give you 10s to appear otherwise I will panic (I know that you are lazy)
FS: I am here already! (after 1sec or less)
kernel:
O.K. I am starting to load stuff, I don't nned to wait 10sec
in other words: you have 10sec max, but system will boot as soon as partition/fs will appear.
So for no problematic fs your delay = screen print
no too long I believe.
Offline
Hmh... ok, thx, gotta check again next time I boot. AFAIR there was a delay that was at least 5 seconds (of which I assumed it was 10 seconds, because I was busy trying to visualize what was left of the other md0 message that just scrolled away), but as for now I'm not sure my memory (brain, not motherboard) is working correctly so all I can say for sure is ATM:
- There's a least one new line somewhere above that 10-secs-message related to the same device (md0 in my case)
- There's a new delay while that 10-secs-message is showing or less than approx. 5 lines later.
Last edited by whoops (2009-06-24 00:38:57)
Offline
considering i just spent some time yesterday shaving down my bootup time by a few seconds, this is rather annoying. if this was added to help a few people with ext4 problems, couldn't a kernel option be added for those people instead of adding 10 seconds to everyone's boot time?
i'm using reiserfs, and it does wait a whole 10 seconds before continuing after this message, despite broch's suggestion that it waits only until the device is available.
Well,
maybe I was optimistic hoping that there is no delay if device appears quickly.
still before re-compiling kernel, take look at /etc/rc.sysinit and comment out what you don't need.
If this will not help and this delay is getting on your nerves, get vanilla kernel (not ABS/AUR) and build your own.
I would keep default kernel handy though in the case that custom fails.
I do not use initrd, which definitely sppeds up devices.
Last edited by broch (2009-06-24 01:04:38)
Offline
broch you're right but before I don't have to wait I will try my own kernel
Shell Scripter | C/C++/Python/Java Coder | ZSH
Offline
i saw in another forum post that there is a kernel option for setting how long the delay is
in /boot/grub/menu.lst, just add rootdelay=1 to the kernel line. it's been a while since i have used lilo, but i think you add append="rootdelay=1" somewhere.
i set it to 1 second and it is a big improvement. i don't get a kernel panic. it definitely waits 10 seconds otherwise.
you cannot set it to 0 seconds, as it will ignore the setting and wait 5 seconds. i tried 0.1 seconds and that didn't work either.
this delay isn't in rc.sysinit -- actually, i can't find it in any /etc or /boot file using grep.
Offline
after a little digging, i realized this is caused by mkinitcpio. it defaults to 10 seconds, but most drives don't need to wait at all. this delay is available for people booting off usb devices which take a few seconds to initialize. the default should be no waiting, with an option for those who need it (by setting the kernel rootdelay manually).
afaict this is a bug, here is the fix
edit /lib/initcpio/init; where it says
# If rootdelay is empty or not a non-negative integer, set it to 10
if [ -z "${rootdelay}" -o ! "${rootdelay}" -ge 0 ]; then
export rootdelay=10
fi
change it to export rootdelay=0 -- this way, the default is not to wait
also edit /lib/initcpio/init_functions; where it says
if [ "$2" -gt 0 ]; then
seconds="$2"
change -gt 0 to -ge 0 -- this way, it will accept a setting of 0 and not ignore it.
Offline
Interesting,
Thank you for digging this up.
Because I don't use initrd as I mentioned before, then this is the reason why I don't see 10s delay.
Offline
after a little digging, i realized this is caused by mkinitcpio. it defaults to 10 seconds, but most drives don't need to wait at all. this delay is available for people booting off usb devices which take a few seconds to initialize. the default should be no waiting, with an option for those who need it (by setting the kernel rootdelay manually).
afaict this is a bug, here is the fix
edit /lib/initcpio/init; where it says
# If rootdelay is empty or not a non-negative integer, set it to 10 if [ -z "${rootdelay}" -o ! "${rootdelay}" -ge 0 ]; then export rootdelay=10 fi
change it to export rootdelay=0 -- this way, the default is not to wait
also edit /lib/initcpio/init_functions; where it says
if [ "$2" -gt 0 ]; then seconds="$2"
change -gt 0 to -ge 0 -- this way, it will accept a setting of 0 and not ignore it.
Great that's working thamk you
Shell Scripter | C/C++/Python/Java Coder | ZSH
Offline
in my case with or without the above modification default Arch kernel (2.6.30-ARCH) with initrd boots instantly. It shows the message but boots without waiting. Maybe this is related to file system or something else.
Last edited by broch (2009-06-26 16:35:52)
Offline
I have multiple Arch systems, all boot without delay. All are ext4, but:
#1 - Lenovo T400
#2 - Dell 2850
#3 - Dell OptiPlex 755
#4 - Shuttle PC, Quad Core Intel
The T400 has a 7200 rpm 320G Seagate
The 2850 has a Perc4/i with a Raid 1 for root, Raid 5 for /home (hardware raid), 6x146G 10k rpm Seagate drives
The 755 has some 80G drive, never bothered to check which.
The Shuttle (has the GM45 chipset, forget the model) using MD (software raid 1) with two 1TB Seagate drives for root.
All were installed using ext4 root with 2009.02, all run 2.6.30 now.
Last edited by ormandj (2009-06-26 16:25:58)
Offline
I also have the issue where it waits exactly 10 seconds before booting (ext3), however if i change grub option to rootdelay=1 it boots straight away.
If it was added for people using ext4, shouldnt the default be 1 second or 5 seconds (whatever it was before), and they can add a rootdelay option?
Or do the number of people using ext4 outnumber all others?
Should we report it on the bugtracker?
Last edited by Kane (2009-06-28 10:23:55)
Offline