Created attachment 347479 [details] dmesg output Description of problem: After I did upgrade to F-11, system is booting more than 2 minutes. If boot without rhgb and quiet kernel params, then in kernel log significant delay happens after: -------- ... raid0: done. raid0 : md_size is 8385536 sectors. raid0 : conf->spacing is 8385536 sectors. raid0 : nb_zone is 1. raid0 : Allocating 8 bytes for hash. md2: unknown partition table usb 8-1: New USB device found, idVendor=046d, idProduct=c03e usb 8-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 8-1: Product: USB-PS/2 Optical Mouse usb 8-1: Manufacturer: Logitech usb 8-1: configuration #1 chosen from 1 choice input: Logitech USB-PS/2 Optical Mouse as /devices/pci0000:00/0000:00:1d.2/usb8/8-1/8-1:1.0/input/input4 generic-usb 0003:046D:C03E.0001: input,hidraw0: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-0000:00:1d.2-1/input0 -------- After that log continues and system is starting normal init process: -------- kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. -------- Version-Release number of selected component (if applicable): kernel-2.6.29.4-167.fc11.x86_64 How reproducible: Always. Steps to Reproduce: 1. Boot Actual results: Boots more than 2 minutes Expected results: Boot happens for 20 second as advertised on https://fedoraproject.org/wiki/Features/20SecondStartup :) Additional info: Smolt hardware profile: http://www.smolts.org/client/show/pub_8f2b574a-46aa-4037-8818-e6934babf2fd Dmesg output and bootchart attached.
Created attachment 347480 [details] Bootchart
And sure, boot time was sane on F-10.
Seems that I'm not as lucky as you are, after - my machine hard locks and doesn't resume normal reboot after 120 seconds. LVM over software RAID 5. (3 x 320GB SATA drives) raid5: device sdc5 operational as raid disk 0 raid5: device sdb5 operational as raid disk 2 raid5: device sda5 operational as raid disk 1 raid5: allocated 3226kB for md1 raid5: raid level 5 set md1 active with 3 out of 3 devices, algorithm 2. RAID5 conf printout: --- rd:3 wd:3 disk 0, o:1, dev:sdc5 disk 1, o:1, dev:sda5 disk 1, o:1, dev:sdb5 md1: unknown partition table
As expected, booting in rescue mode from the F11/x86_64 DVD works just fine. Currently running the machine using the rescue DVD kernel. I assume that the kernel DM autostart code assumes that there -must- be a partition table on each device, even if it's an MD device. (Bad assumption.) Any chances of getting a fixed kernel in -testing within the next couple of days? (Given the fact the I've already migrated a number of partitions to ext4, it's going to be pure joy to reinstall F10...) - Gilboa
(In reply to comment #4) > As expected, booting in rescue mode from the F11/x86_64 DVD works just fine. > Currently running the machine using the rescue DVD kernel. > > I assume that the kernel DM autostart code assumes that there -must- be a > partition table on each device, even if it's an MD device. (Bad assumption.) > > Any chances of getting a fixed kernel in -testing within the next couple of > days? The rescue DVD kernel should be exactly the same as the on-disk one.
Gilboa, this looks like a different issue. Could you open other ticket?
Chuck, AFAICS, the LiveCD doesn't attempt to auto-start MD devices. The array is only being initialized once Anaconda starts. Do bot kernels have CONFIG_MD_AUTODETECT=y? Alexey, Looks to me like we are hitting the same problem following the same circumstances. I could open a new ticket but it'll most likely get marked as duplicate as this one. - Gilboa
Sorry for the piglish. first-post-pre-coffee... - Gilboa
Looks like my problem was with LVM snapshot of root filesystem. As I delete it, boot time returns to normal.
As I don't have an open LVM snapshot, I can assume that we are seeing two different issues with LVM handling during boot under F11. I'll open a new bug report. - Gilboa
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.