Bug 1060595 - upgrade hangs on boot: global name 'log' is not defined
Summary: upgrade hangs on boot: global name 'log' is not defined
Keywords:
Status: CLOSED DUPLICATE of bug 1044484
Alias: None
Product: Fedora
Classification: Fedora
Component: fedup
Version: 19
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Will Woods
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-02 23:41 UTC by toddb
Modified: 2014-02-03 17:36 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 980663
Environment:
Last Closed: 2014-02-03 17:36:05 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
boot screen during upgrade (203.80 KB, image/jpeg)
2014-02-03 00:05 UTC, toddb
no flags Details
boot screen during upgrade (203.80 KB, image/jpeg)
2014-02-03 00:37 UTC, toddb
no flags Details

Description toddb 2014-02-02 23:41:04 UTC
+++ This bug was initially created as a clone of Bug #980663 +++

I pre-tested the upgrade by installing a VM with vanilla fedora 18, updating it, and then running fedup. No issues with that upgrade (except I needed to reinstall the virtualbox guest additions before X would work).

My problem is upgrading F18->F19 on a i7-3770/Asus motherboard, raid 5 with a single md device, lvm on top of that with 6 LV.

Upgrade initiated with 'yum update' and then fedup --network 19. The download and check of packages worked OK.

Initial symptoms are a hang on first re-boot into upgrade boot with the progress bar about 20% across (identical to #980663 description)

If I hit delete it switches out of plymouth but never makes any progress. past about 15 lines of output.

I'll try disabling plymouth (plymouth-set-default-theme -R details), and turning off 'rhgb' and 'quiet' (by editing /boot/grub2/grub.cgf), and then enter another comment.

I must say that Bug #980663 was a bit unsatisfying after Ricky said that upgrading fedup fixed the problem.

I do have 
systemd-201-2.fc18.9.x86_64
fedup-0.8.0-3.fc18.noarch

and the newer version has no effect.

Comment 1 toddb 2014-02-03 00:05:02 UTC
Well, a bit different. The last three lines (see attached photo for more details) are:
[ ok ] Reached target Initrd Default Target.
[ 11.895637] systemd-journald[172]: Received SIGTERM
[ 12.300643] systemd[1]: Failed to initialize SELinux context: No such file or directory

And nothing after that.  I do have SELinux disabled (via /etc/sysconfig/selinux). So it would seem there is an assumption in the fedup scripts that SELinux is present. Presumably this bug is because each file on the file system must be labeled with an SELinux context.

I have these packages installed (but disabled)

policycoreutils-2.1.13-59.fc18.x86_64
setroubleshoot-3.2.3-3.fc18.x86_64
libselinux-python-2.1.12-7.3.fc18.x86_64
selinux-policy-3.11.1-108.fc18.noarch
libselinux-2.1.12-7.3.fc18.i686
selinux-policy-doc-3.11.1-108.fc18.noarch
libselinux-devel-2.1.12-7.3.fc18.x86_64
selinux-policy-devel-3.11.1-108.fc18.noarch
libselinux-utils-2.1.12-7.3.fc18.x86_64
libselinux-2.1.12-7.3.fc18.x86_64

Comment 2 toddb 2014-02-03 00:05:38 UTC
Created attachment 858331 [details]
boot screen during upgrade

Comment 3 toddb 2014-02-03 00:37:37 UTC
Created attachment 858342 [details]
boot screen during upgrade

Comment 4 toddb 2014-02-03 01:09:36 UTC
I have tried re-enabling selinux, but it refuses, probably for a variety of reasons (yes, I updated /etc/sysconfig/selinux to be permissive).

# /usr/sbin/load_policy -i
SELinux: unable to find usable policy file:  No such file or directory
/usr/sbin/load_policy:  Can't load policy:  No such file or directory

The log I attached seems similar to #912058, but reviewing comments by wwoods

> a) mdraid disks that require mdadm.conf to be configured (bug 895805)

I do have mdraid, but I don't believe they need to be configured. It works fine under fedora 18.

> b) multiple encrypted partitions (bug 896010)
> c) encrypted /home only (bug 894242)
> d) old version of systemd in F17 (bug 910326)

No, no and no.

Could it be that fedup has trouble with lvm on top of md on top of disks?

Comment 5 toddb 2014-02-03 01:16:37 UTC
Oh, yes, and I did 'dracut -f' as suggested in #845194. No change.

Comment 6 toddb 2014-02-03 03:54:06 UTC
... and installing a two packages for selinux (listed here: http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Working_with_SELinux-Enabling_and_Disabling_SELinux.html) allowed selinux to be enabled.

And that allowed fedup 18-->19 to proceed.

So that's the bug: enabled selinux is required for fedup to work. I'm sure there's much more subtlety than that last sentence, but I would hope that someone cares enough to put this on the to-do list.

Comment 7 Will Woods 2014-02-03 17:36:05 UTC

*** This bug has been marked as a duplicate of bug 1044484 ***


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