Bugzilla – Bug 846001
recognizing Linux volumes on installation lasts extremely long (~1 hour)
Last modified: 2014-03-22 03:26:34 UTC
User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.21 (KHTML, like Gecko) konqueror/4.11.2 Safari/537.21 Installing openSUSE 13.1 RC1 on my SilverSeraph machine I had to wait for about an hour today until it had finished with the step "recognize other Linux volumes". This is a regression since the installation procedure used to be much faster on this particular machine. Reproducible: Always
Created attachment 563509 [details] yast2 log package as produced by save_y2logs
may be linked to the same component as Bug 846003.
Some commands for probing need very long, e.g. "blkid" needs 2451s, "btrfs filesystem show" needs 39s and "mdadm --examine --scan" 184s. I suspect a kernel driver problem when accessing a certain device.
Created attachment 563598 [details] full installation logs (save_y2logs after install) Now; finally after almost a whole day the installation is ready. It has hung more often than once: on bootloader installation for sure and once very soon on package installation as I believe.
Arvin, it would be really nice if we could do something about it. What shall I do?
I'm not a kernel developer so I cannot fix the problem. For further debugging I would run "strace -tT -o blkid.log blkid -c /dev/null". The file blkid.log should then make it clear which system call takes so long. Additionally I would look at kernel messages.
Unfortunately this way I could not reproduce any hang. There must either have been used some other command line parameters or it was a totally different command that hung.
During installation that command took very long. From the log: SystemCmd.cc(doExecute):279 stopwatch 2451.727396s for "BLKID_SKIP_CHECK_MDRAID=1 /sbin/blkid -c /dev/null" Sorry, that's all I can say.
Unfortunately this did not do the trick (at least not by executing it normally under the console at runlevel 3). Even grub-install - the bootloader installation was known to cause another hang - did not cause a hang no more. The third hang was somewhere during normal package isntallation (you may also see for these issues in the final log). However I guess we can not reproduce it unless I boot into the installation system again. Too bad that we won`t even have an strace utility there. Arvin; can we still do something about it?
Running 'extend gdb' in a shell session while running the installation image will install strace.
I also noticed that detecting other Linux partitions took longer than I expected. Though in my case it only took several minutes and not an hour. At the time I attributed this to my setup of two SATA HDDs in a RAID 0 (stripping) configuration. -A
Created attachment 566798 [details] blkid.log
Created attachment 566799 [details] stderr messages on stracing blkid
Created attachment 566800 [details] mdadm.log Sorry for the delay but openSUSE13.1 has still some flagrant issues which have discouraged me from continuing my testing effort (Bug 845287 & others).
Elmar, I can also report that the time period for recognising Linux volumes on Install is excessive. It related to CPU and overall performance of the PC. One of my older X_64 quad cores running at 3200 click takes up to 20 minutes and as you’ve found the demand on resources at this point in time is about 100%. I have a feeling that all of the faults relating to the failure of the boot loader taking an inordinate amount of time to write; the success rate of the boot loader actually completing successfully as well as all reported issues with the partitioner's behaviour; complete all related bugs. I tried a test loaded 13.1 13 times yesterday all with different system suggested partitioning and my own and not one installation left a functional state of being able to boot from the HDD / or /boot or /boot/efi All the fixes related to the partitioner etc etc and resolved in bug # 850056 should be retro compiled to the download of final product. I have tried to capture so many faults myself but without a system that will boot and work its just too hard..I'd expunge 13.1 out of existence
Jeff, would you have a look at the mdadm.log and why the command invocation lasts for so long? Any other information I could provide?
According to my analysis in bug#773058 comment#43, this is a duplicate. If this turns out not to be the case later, please reopen. Thanks. *** This bug has been marked as a duplicate of bug 773058 ***
In deed fd0 is only at installation time in /proc/partitions; when normally booting into kernel 3.11.6-4-desktop it is not there (Perhaps I should also test it with the -default variant).
*** Bug 845650 has been marked as a duplicate of this bug. ***
With 13.1 I have several problems I'll summarise specially in regard to X_64 architecture and BIOS recognition. 1. The suggested default partitioning made by 13.1 cannot determine if the BIOS has or has not /boot/efi demands. It treats all X_64 BIOS the same. On my X_64 which has no BIOS UEFI mode the partitioner cant tell if the BIOS has or nas not an extended UEFI mode. 2. The partitioner once overridden with a user defined partition setup issues warnings and almost demands /boot/efi regardless. 3. Further warnings that when the user makes sound decision to use a particular drive which has not the correct label based on the non presence of a NTFS label being present issues warning after warning based solely on the Drives Label. These are all reproducible and I have previously summarised in great deal. The time delay is a reflection on the base on the rated FLOPS of the CPU which could be anything from 5 mins in my experience to over an hour on I586/686 CPU as is this and other bug duplicates. Once installed any disparity that exists based on the user accepting the auto proposed partitioning yields an unusable O/S based on the auto bootloader info. Once installed with sound reasoning in partitioning the drives based of BIOS and X_64 architecture the auto bootloader yields an unusable stable O/S. Other issues of a 13.1 fully online updated, given that the user can get that far are SHOWSTOPPER and I wont use 13.1 period and my humble un-emotive conclusion is that 13.1 should be simply expunged. It should not have never got past alpha testing on just 1 X_64 PC there is just way way too many things wrong with the O/S after default install to even gain access to online updates...Just expunge it...and I have never in my life recommend to the same conclusion...Im really sorry
2 of My X_64 offer boot from BIOS UEFI or NON-UEFI 'Hit T to boot Turbo UEFI....HIT H to turn OFF Turbo UEFI' A there is suggestion in Bug 773058 and swamp to create WIFI page on the management of installing 11.x on X_64 PC Best to cover the optional boot to users to set at time of installation.... ...Possible impact after installation....?????? I myself have no ideas