30 seconds of no activity during boot sequence

dismalscience · #1 22nd November 2009, 03:27 PM

Hello-
I have been enjoying Fedora 11 for sometime, and decided to try Fedora 12. All in all it is working, but the boot sequence seemed much slower. I decided to use bootchart to examine the boot process on my old F11 and new F12 installations. The result show F11 booting in ~34 seconds, and F12 booting in ~57 seconds. Interestingly, the first 30 seconds show that only kthreadd, khelper, and ata/0 are running. CPU and disk utilization are both zero during this 30 seconds span, then all of a sudden everything starts loading, CPU and Disk utilization spike up, and ~23 seconds later I get to the login screen. I sent an email to Harald Hoyer about this, and to my surprise he was kind enough to respond. He suggested I check the BIOS to make sure I had disabled the floppy drive, which I did. The problem persists, so I was wondering if anyone here was having a similar issue and if so how they have dealt with it.
I have blacklisted the floppy module (just to make sure) but this does not seem to help. Any thoughts?

damartin · #2 23rd November 2009, 09:34 AM

I had similar issues and found that my "pause" was due to have so many parttitions (I have 8 SATA drives that i partitioned into 10 partitions each and striped the RAID5 devices over these). Removing the partitions and the pause went away - I never solved this - just reduced the number of partitions in the end.

Gödel · #3 23rd November 2009, 11:05 AM

do you have anything suspicious in dmesg? (eg 'dmesg | grep error')

Do you have an intel graphics adapter? I am seeing a 10 second delay at boot, with a blank screen, then a "drm:i915_handle_error", then it boot normally into plymouth. I didn't see this at Fedora 12 beta.

Want to investigate further, but I am not seeing many reports of similar issues.

Edit: Well, I got my boot time back down to ~20 secs, but I'm not sure what exactly fixed it!

I suspected modesetting and/or the drm driver error with i915 was a problem, so I blacklisted i915, drm and drm_kms_helper (in /etc/modprobe/blacklist.conf) and rebuilt the initramfs

Code:

cp /boot/initramfs-$(uname -r).img .
sudo dracut --force /boot/initramfs-$(uname -r).img $(uname -r)

Then added 'nomodeset' to the kernel boot line and the reboot was much faster, the attached images show an improvement from ~80secs to ~20secs which is staggering, it didn't seem that great a difference. With 'nomodeset' option removed the boot time was 2-3secs slower.

The thing is, I copied the original initramfs back and it still boots as quick! So I removed the blacklisted modules from blacklist.conf, and rebuilt the initramfs again, and it still boots fast! So what's going on, I've fixed the annoying boot delay I had, but I'm not sure how, just by rebuilding the initramfs with dracut? Blacklisting modules doesn't seem to matter.

(for bootchart images, do 'yum install bootchart', then add 'init=/sbin/bootchartd' to kernel boot line, then after booting type 'bootchart')

fuege · #4 24th November 2009, 03:08 AM

Hi,
I can confirm the OP. After a yum upgrade from F11 to F12, I got around 30 seconds delay. (You don't wanna know about the grand total of my boot time on my 11 year old PIII box

...).

Kernel: 2.6.31.5-127.fc12.i686.PAE

bootchart shows about 27 seconds before starting the first process.

I even played around with dracut building a new (?) initramfs, or kernel parameters for it like rd_NO_LVM rd_NO_MD (which I do not need) but without Gödel's success.

So no solution, just confirmation.

Regards

dismalscience · #5 10th December 2009, 02:42 AM

Hello-
I noticed in dmesg:

Code:

ata2.00: status: { DRDY }
ata2: link is slow to respond, please be patient (ready=0)
ata2: device not ready (errno=-16), forcing hardreset
ata2: soft resetting link
ata2.00: configured for UDMA/33
ata2: EH complete

So it seems that the hard drive is not loading, consistent with my bootcharts. A little more researched from the hitachigst.com site showed that my drive (sata 2, hitachi travelstar HTS543225L9A300) does not support UDMA. To test this I ran

Code:

hdparm -i /dev/sda 
 Model=Hitachi, FwRev=FBEOC40C, SerialNo=090721FB2K00LEF4K57A
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=DualPortCache, BuffSize=7114kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=488397168
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
 AdvancedPM=yes: mode=0x80 (128) WriteCache=enabled
 Drive conforms to: unknown:  ATA/ATAPI-2,3,4,5,6,7

Which indicates that the drive does in fact support UDMA, and somehow sets itself to UDMA6, contrary to the dmesg output. Does anyone have any ideas on how to proceed? I am once more at the end of my experience.

citojaso · #6 10th December 2009, 04:48 AM

I had long delays during boot and when ever I needed to furnish a password. Turns out that in F12 fingerprint recognition is turned on by default. After turning it off in settings everything was back to normal