Silverblue fails to boot since 29.20190124.0

Project Discussion
1

Since the update from 29.20190123.0 to 29.20190124.0 my Silverblue setup fails to boot.
Output of rpm-ostree status:

  ostree://fedora-workstation:fedora/29/x86_64/silverblue
                   Version: 29.20190128.0 (2019-01-28T02:37:24Z)
                BaseCommit: ec51f3a812f763cf00f7f7ef3255d7200fee0dee60620a4945dedbbe9826aed5
              GPGSignature: Valid signature by 5A03B4DD8254ECA02FDA1637A20AA56B429476B4
             SecAdvisories: 1 unknown severity, 2 low, 1 moderate
                      Diff: 65 upgraded, 6 added
       RemovedBasePackages: firefox-64.0.2-1.fc29.x86_64
           LayeredPackages: baobab chromium snapd

● ostree://fedora-workstation:fedora/29/x86_64/silverblue
                   Version: 29.20190123.0 (2019-01-23T01:18:07Z)
                BaseCommit: c44dbb8bed4e1e3b6a94c51749e96f9c6d4f5841a5179ef89ebd7472263ca93f
              GPGSignature: Valid signature by 5A03B4DD8254ECA02FDA1637A20AA56B429476B4
       RemovedBasePackages: firefox-64.0.2-1.fc29.x86_64
           LayeredPackages: baobab chromium snapd
                    Pinned: yes

  ostree://fedora-workstation:fedora/28/x86_64/workstation
                   Version: 28.20181027.0 (2018-10-27T16:02:21Z)
                BaseCommit: 1692d98fe75635c855f619ecb5a6915b31d58cdc98de056714e346a17d0dbd23
              GPGSignature: Valid signature by 128CF232A9371991C8A65695E08E7E629DB62FB1
           LayeredPackages: snapd
                    Pinned: yes

The 29.20190123.0 Version works still fine, but all newer versions fail to boot. I am using full disk encryption in case that’s relevant.

The output of journalctl -b -1 can be found here: https://paste.fedoraproject.org/paste/9PBXHrUYBtAriwXPELBSYg

2

I run my entire LVM as a LUKS encrypted disk and have no such issues. Are you dual booting Windows with this Lenovo?

3

Silverblue is the only system on the disk. Why is this relevant?

4

I was just wondering mostly from looking at your logfile, but I realized it is pretty much pertaining to UEFI in this case. As for LUKS, I use it and have for a few years now with no issues so I don’t believe that is your problem.

5

it looks like SELinux might be causing issues mounting your /home/:

Jan 28 09:13:04 localhost.localdomain audit[1]: AVC avc:  denied  { getattr } for  pid=1 comm="systemd" path="/home" dev="dm-3" ino=820738 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=lnk_file permissive=0
Jan 28 09:13:04 localhost.localdomain audit[1]: AVC avc:  denied  { read } for  pid=1 comm="systemd" name="home" dev="dm-3" ino=820738 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=lnk_file permissive=0
Jan 28 09:13:04 localhost.localdomain audit[1]: AVC avc:  denied  { read } for  pid=1 comm="systemd" name="home" dev="dm-3" ino=820738 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=lnk_file permissive=0
Jan 28 09:13:04 localhost.localdomain systemd[1]: home.mount: Failed to check directory /home: Permission denied
Jan 28 09:13:04 localhost.localdomain systemd[1]: Mounting /home...
Jan 28 09:13:04 localhost.localdomain kernel: EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: (null)
Jan 28 09:13:04 localhost.localdomain systemd[1]: home.mount: Mount process finished, but there is no mount.
Jan 28 09:13:04 localhost.localdomain systemd[1]: home.mount: Failed with result 'protocol'.
Jan 28 09:13:04 localhost.localdomain systemd[1]: Failed to mount /home.
Jan 28 09:13:04 localhost.localdomain systemd[1]: Dependency failed for Local File Systems.
Jan 28 09:13:04 localhost.localdomain systemd[1]: Dependency failed for Mark the need to relabel after reboot.
Jan 28 09:13:04 localhost.localdomain systemd[1]: selinux-autorelabel-mark.service: Job selinux-autorelabel-mark.service/start failed with result 'dependency'.
Jan 28 09:13:04 localhost.localdomain systemd[1]: local-fs.target: Job local-fs.target/start failed with result 'dependency'.

Here are the changes from 29.20190123.0 to 29.20190124.0:

[dustymabe@media fedora-ostree-repo-mirror]$ rpm-ostree --repo=./ db diff c44dbb8bed4e1e3b6a94c51749e96f9c6d4f5841a5179ef89ebd7472263ca93f  a8b5679616474f4280ec45025066d4f971d16acf6835d49e1718dd305365eb62                                
ostree diff commit old: c44dbb8bed4e1e3b6a94c51749e96f9c6d4f5841a5179ef89ebd7472263ca93f
ostree diff commit new: a8b5679616474f4280ec45025066d4f971d16acf6835d49e1718dd305365eb62
Upgraded:
  appstream-data 29-8.fc29 -> 29-9.fc29
  container-selinux 2:2.79-1.git6f01752.fc29 -> 2:2.80-1.git1b655d9.fc29
  curl 7.61.1-6.fc29 -> 7.61.1-7.fc29
  flatpak-builder 1.0.1-1.fc29 -> 1.0.2-1.fc29
  gcr 3.28.0-2.fc29 -> 3.28.1-1.fc29
  ibus-libpinyin 1.10.92-1.fc29 -> 1.11.0-1.fc29
  ibus-libzhuyin 1.8.93-1.fc29 -> 1.9.0-1.fc29
  ibus-typing-booster 2.4.1-1.fc29 -> 2.5.0-1.fc29
  libcurl 7.61.1-6.fc29 -> 7.61.1-7.fc29
  libpinyin 2.2.1-1.fc29 -> 2.2.2-1.fc29
  libpinyin-data 2.2.1-1.fc29 -> 2.2.2-1.fc29
  librsvg2 2.44.11-1.fc29 -> 2.44.12-1.fc29
  libsolv 0.7.2-1.fc29 -> 0.7.2-2.fc29
  libwebp 1.0.0-2.fc29 -> 1.0.2-1.fc29
  libxcrypt 4.4.2-3.fc29 -> 4.4.2-6.fc29
  libzhuyin 2.2.1-1.fc29 -> 2.2.2-1.fc29
  llvm-libs 7.0.1-1.fc29 -> 7.0.1-2.fc29
  osinfo-db 20181214-1.fc29 -> 20190120-1.fc29
  poppler 0.67.0-6.fc29 -> 0.67.0-10.fc29
  poppler-glib 0.67.0-6.fc29 -> 0.67.0-10.fc29
  poppler-utils 0.67.0-6.fc29 -> 0.67.0-10.fc29
  python3 3.7.2-1.fc29 -> 3.7.2-4.fc29
  python3-libs 3.7.2-1.fc29 -> 3.7.2-4.fc29
  rpm-ostree 2018.10-1.fc29 -> 2019.1-1.fc29
  rpm-ostree-libs 2018.10-1.fc29 -> 2019.1-1.fc29
  virtualbox-guest-additions 5.2.22-1.fc29 -> 5.2.24-1.fc29
Added:
  jack-audio-connection-kit-1.9.12-6.fc29.x86_64
  libconfig-1.7.2-2.fc29.x86_64
  libffado-2.4.1-4.fc29.x86_64
  libxml++-2.40.1-7.fc29.x86_64
  portaudio-19-28.fc29.x86_64
  python3-pyaudio-0.2.11-1.fc29.x86_64

So maybe a bug introduced in that set of updates?? For now you could try setting SELinux to permissive mode (edit kernel command line in grub to add enforcing=0) to see if that works. This is not a long term solution but would give us more information.

6

possibly related bug: After upgrade: Failed to mount /home · Issue #1742 · coreos/rpm-ostree · GitHub

7

Let’s track this in 1669982 – Selinux context for /home symlink to /var/home wrong (silverblue, causes failed boots)

8

After setting SELinux to permissive mode the system boots successfully.