Created attachment 6178 [details] Installer report The scanning hard disks step used to be fairly quick (a few seconds), but is now taking over a minute. The message set_partition_flag: unknown type: recovery appears a number of times, at intervals of 3-4 seconds. These messages also appear when running some of the drakxtools from the command line (e.g. drakx11). This is using the current mdkinst.sqfs on my mirror, dated Mar-30. The slowness and the messages may or may not be related, but both are new since the last time I downloaded a mdkinst.sqfs (within the last couple of weeks).
CC: (none) => thierry.vignaudAssignee: bugsquad => thierry.vignaud
commit 034f62def330bcfae17a40c0eac45fb306e2a01d Author: Thierry Vignaud <thierry.vignaud@...> Date: Fri Apr 3 18:08:13 2015 +0200 really try to detect recovery partitions on GPT fix "set_partition_flag: unknown type: recovery" (mga#15621) --- Commit Link: http://gitweb.mageia.org/software/drakx/commit/?id=034f62def330bcfae17a40c0eac45fb306e2a01d
The messages no longer appear, and on my desktop machine the speed is now OK. On my laptop it still takes over a minute to run the partition_table::gpt::read_one subroutine. The thing taking the time is the calls to c::get_partition_flag. May or may not be important, but about the time of the first call, the following messages appear in the journal: kernel: ACPI Warning: \_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20141107/nsarguments-95) kernel: ACPI: \_SB_.PCI0.PEG0.PEGP: failed to evaluate _DSM kernel: ACPI Warning: \_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20141107/nsarguments-95)
P.S. This doesn't just affect the installer, it happens every time you run drakboot or add/remove a new kernel version.
The ACPI warnings are unrelated. The thing that's causing the delay is that ped_disk_new/ped_disk_destroy is called each time c::get_partition_flag or c::is_recovery_partition is called, and ped_disk_new/ped_disk_destroy is taking 1 second on average.
Summary: Installer stage 2 scanning hard disks step very slow, generates many "set_partition_flag: unknown type: recovery" messages => Installer/Live boot/drakxtools scanning hard disk partitions step very slow
Created attachment 6316 [details] Patch to speed up reading of partition flags Here's a possible solution to this problem.
(In reply to Martin Whitaker from comment #5) > Created attachment 6316 [details] > Patch to speed up reading of partition flags > > Here's a possible solution to this problem. Thanks, Martin :-) CC'ing pterjan and tmb, because tv is absent until April 26
CC: (none) => marja11, pterjan, tmb
Comment on attachment 6316 [details] Patch to speed up reading of partition flags That should work but can you at least create a function used in both places to not repeat the list? Or maybe kill is_recovery_partition or make it a helper taking a part object and called in get_disk_partitions.
Also, please commit locally and create the patch with git format-patch, so that we can apply it and give you credit.
Created attachment 6317 [details] Patch to speed up reading of partition flags Yes, I meant to suggest removing is_recovery_partition, as I couldn't find it being used anywhere else, but converting it to a helper function is a better idea.
Attachment 6316 is obsolete: 0 => 1
commit 1daabebda57976579465e5c281eaa14088e0e37f Author: Martin Whitaker <mageia@...> Date: Sun Apr 19 21:35:31 2015 +0100 Speed up reading of flags from GPT partition table. On some machines, calls to ped_disk_new() in libparted take of the order of seconds, so doing this for each flag and partition in turn makes partition_table::gpt::read_one take an inordinate amount of time (mga#15621). Instead, collect the flags during the call to c::get_disk_partitions. --- Commit Link: http://gitweb.mageia.org/software/drakx/commit/?id=1daabebda57976579465e5c281eaa14088e0e37f
Thank you, committed.
Fixed
Status: NEW => RESOLVEDResolution: (none) => FIXED
Though we could cache the PedDisk object in a perl object during the whole execution of partition_table::gpt::write()...
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
But that's another subject
Status: REOPENED => RESOLVEDResolution: (none) => FIXED