Bug 505433 - System is booting more than 2 minutes when snapshot of root filesystem is active
System is booting more than 2 minutes when snapshot of root filesystem is active
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-11 17:21 EDT by Alexey Torkhov
Modified: 2010-06-28 08:54 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-28 08:54:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg output (45.75 KB, text/plain)
2009-06-11 17:21 EDT, Alexey Torkhov
no flags Details
Bootchart (15.21 KB, image/svg+xml-compressed)
2009-06-11 17:22 EDT, Alexey Torkhov
no flags Details

  None (edit)
Description Alexey Torkhov 2009-06-11 17:21:58 EDT
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.
Comment 1 Alexey Torkhov 2009-06-11 17:22:34 EDT
Created attachment 347480 [details]
Bootchart
Comment 2 Alexey Torkhov 2009-06-11 17:27:27 EDT
And sure, boot time was sane on F-10.
Comment 3 Gilboa Davara 2009-06-16 02:29:25 EDT
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
Comment 4 Gilboa Davara 2009-06-16 03:00:59 EDT
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
Comment 5 Chuck Ebbert 2009-06-20 07:26:08 EDT
(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.
Comment 6 Alexey Torkhov 2009-06-20 07:39:54 EDT
Gilboa, this looks like a different issue. Could you open other ticket?
Comment 7 Gilboa Davara 2009-06-21 06:04:35 EDT
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
Comment 8 Gilboa Davara 2009-06-21 07:38:38 EDT
Sorry for the piglish. first-post-pre-coffee...

- Gilboa
Comment 9 Alexey Torkhov 2009-06-25 17:48:43 EDT
Looks like my problem was with LVM snapshot of root filesystem. As I delete it, boot time returns to normal.
Comment 10 Gilboa Davara 2009-06-28 03:48:35 EDT
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
Comment 11 Bug Zapper 2010-04-27 10:47:39 EDT
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
Comment 12 Bug Zapper 2010-06-28 08:54:45 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.