Red Hat Bugzilla – Bug 505433
System is booting more than 2 minutes when snapshot of root filesystem is active
Last modified: 2010-06-28 08:54:45 EDT
Created attachment 347479 [details]
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 : 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):
Steps to Reproduce:
Boots more than 2 minutes
Boot happens for 20 second as advertised on
Smolt hardware profile:
Dmesg output and bootchart attached.
Created attachment 347480 [details]
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...)
(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
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?
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?
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.
Sorry for the piglish. first-post-pre-coffee...
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.
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:
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.