Bug 846001

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