Bug 1478 - Boot process of Rosa 2012.1 Fresh is frozen for the 1-2 minutes after install second OS
: Boot process of Rosa 2012.1 Fresh is frozen for the 1-2 minutes after install...
Status: RESOLVED WORKSFORME
Product: Desktop Bugs
Classification: ROSA Desktop
Component: Main Packages
: Fresh
: All Linux
: Normal normal
: ---
Assigned To: ROSA Linux Bugs
: ROSA Linux Bugs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-17 14:16 MSK by FirstLevel
Modified: 2013-11-21 23:44 MSK (History)
3 users (show)

See Also:
RPM Package:
ISO-related:
Bad POT generating:
Upstream:


Attachments
diagnostic information (9.76 KB, text/plain)
2013-01-17 14:16 MSK, FirstLevel
Details
dmesg (63.25 KB, text/plain)
2013-01-17 14:16 MSK, FirstLevel
Details
bootlog (7.98 KB, text/plain)
2013-01-17 20:41 MSK, FirstLevel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description FirstLevel 2013-01-17 14:16:48 MSK
Created attachment 1065 [details]
diagnostic information

Description of problem:
I have installed ROSA 2012.1 Fresh nn my computer with several harddisks. After installation of second OS Fedora 18 Beta (when I did not install new bootloader and use current grub2 from ROSA) I see that ROSA Boot process of Rosa 2012.1 Fresh is frozen for the 1-2 minutes on the message
"«[ok] Started Reconfigure the system on administrator request» "
After some minutes the boot process is continued.
I have deinstalled Fedora 18 Beta but such strange situation with frozen booting process exists.
I have attached my disk configuration, grub.cfg  and dmesg from ROSA.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
Comment 1 FirstLevel 2013-01-17 14:16:59 MSK
Created attachment 1066 [details]
dmesg
Comment 2 Alexander Burmashev 2013-01-17 14:24:22 MSK
attach boot.log please
Comment 3 FirstLevel 2013-01-17 20:41:39 MSK
Created attachment 1069 [details]
bootlog
Comment 4 FirstLevel 2013-01-17 20:41:53 MSK
(In reply to comment #2)
> attach boot.log please

It is attached
Comment 5 FirstLevel 2013-02-04 21:18:23 MSK
User has solved the problem. Bootloader is linked swap partition from other linux.
 файла /etc/fstab:

# Entry for /dev/sdb1 :
UUID=0b16ba37-f7fd-4f9e-8ea9-0384cbd99c48 / ext4 defaults 1 1
# Entry for /dev/sdb6 :
UUID=c8e7dbfc-3ac7-409a-91d6-4330ad4bc8e0 /home ext4 defaults 1 2
none /proc proc defaults 0 0
# Entry for /dev/sda1 :
#UUID=a4cf2bb3-358d-47d4-89d3-f7a2a88af5fc swap swap defaults 0 0 - this string cause the problem and user has commented it
# Entry for /dev/sdb5 :
UUID=e666cda8-e22d-43d8-9892-48e43f04f10a swap swap defaults 0 0
Comment 6 FirstLevel 2013-02-05 10:52:55 MSK
I see that such misconfiguration had to be analyzed and solved.
Comment 7 Denis Silakov 2013-02-28 23:39:14 MSK
These lines from the log:

[ TIME ] Timed out waiting for device dev-disk-by\x2duuid-a4cf2bb3\x2d358d\x2d47d4\x2d89d3\x2df7a2a88af5fc.device.
[DEPEND] Dependency failed for /dev/disk/by-uuid/a4cf2bb3-358d-47d4-89d3-f7a2a88af5fc.

indicate that there is no partition with uuid=a4cf2bb3-358d-47d4-89d3-f7a2a88af5fc in the system. You can rub 'blkid' command to check uuids of partitions. Likely that swap partition was reformatted/recreated and now has different uuid.

If so, then this should help:

tune2fs -U a4cf2bb3-358d-47d4-89d3-f7a2a88af5fc /dev/sdb1

One can also try to change uuid in fstab or even use /dev/sda1 instead of uuid, but it is possible that this uuid is also included in initrd, so one will have to regenerate it.
Comment 8 Denis Silakov 2013-11-21 23:44:39 MSK
I would finally close this bug. The reason of the issue likely was reusage of the same swap partition which was reformatted when the second distribution was installed. If user is experienced enough to install several distributions with several swap partitions, then he should be prepared for manual tweaking of swap configuration.