Bug 1217578 - Atomic rawhide installer fails to unmount filesystems during install
Summary: Atomic rawhide installer fails to unmount filesystems during install
Alias: None
Product: Fedora
Classification: Fedora
Component: python-blivet
Version: 23
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Vojtech Trefny
QA Contact: Fedora Extras Quality Assurance
Whiteboard: RejectedFreezeException
: 1218005 (view as bug list)
Depends On:
Blocks: 1218846
TreeView+ depends on / blocked
Reported: 2015-04-30 17:28 UTC by Colin Walters
Modified: 2016-12-20 13:37 UTC (History)
18 users (show)

Fixed In Version: python-blivet-1.4-1.fc23
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1218846 (view as bug list)
Last Closed: 2016-12-20 13:37:18 UTC
Type: Bug

Attachments (Terms of Use)

Description Colin Walters 2015-04-30 17:28:15 UTC
Working: http://koji.fedoraproject.org/koji/taskinfo?taskID=9518375
First failing: http://koji.fedoraproject.org/koji/taskinfo?taskID=9528133
  This one looks like it was firewalling.

I think the way to debug this is to look at the package diff between the installer ISOs.

Comment 1 Colin Walters 2015-04-30 17:30:04 UTC
First failing with "umount failed" symptom: http://koji.fedoraproject.org/koji/taskinfo?taskID=9571961

Comment 3 Fedora Update System 2015-04-30 18:57:01 UTC
ostree-2015.5-5.fc22 has been submitted as an update for Fedora 22.

Comment 4 Fedora Blocker Bugs Application 2015-05-01 14:24:06 UTC
Proposed as a Freeze Exception for 22-final by Fedora user walters using the blocker tracking app because:

 Should fix the Atomic composes.

Comment 5 Fedora Update System 2015-05-01 16:37:33 UTC
ostree-2015.5-5.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 6 Colin Walters 2015-05-05 14:12:38 UTC
The ostree fix helped with one cause of this - anaconda no longer holds a directory fd open on /mnt/sysimage.

The problem now appears to be that API mounts such as /mnt/sysimage/dev/pts are not being unmounted before we're trying to umount /mnt/sysimage/dev.  I'm doing more debugging now.

Comment 7 David Shea 2015-05-05 14:23:58 UTC
*** Bug 1218005 has been marked as a duplicate of this bug. ***

Comment 8 Colin Walters 2015-05-05 16:26:20 UTC
I see in `program.log` that blivet is mounting `/mnt/sysimage/dev/pts`, but trying to unmount `/dev/pts`.

Comment 9 Colin Walters 2015-05-06 03:06:04 UTC
I think there may be different bugs going on between rawhide and f22.

I'd been kind of ignoring it until someone did something about https://bugzilla.redhat.com/show_bug.cgi?id=1197204

But at some point that appears to have gone away for some reason.  I need to find out why that is.

Anyways, I think the rawhide atomic bug is related to this:

Specifically blivet.py:mountFilesystems() is what passes the value of `getSysroot()` down to the mount points.  Before that commit, the chrooted mount was stored in the `_mountpoint` variable.  After it though, we're apparently trying to read from `/proc/self/mountinfo`...but we're not honoring the chroot when looking in the `systemMountpoint` property, and thus getting the real /dev/pts.

I'm not sure why this isn't actively exploding for mainline (i.e. dnfpayload).

*time passes*

Oh the answer to that seems to be pretty simple, mainline is only calling anaconda.storage.umountFilesystems in anaconda's exitHandler which is really only called when *systemd* is taking care of shutdown and unmounting, so any exceptions thrown will be lost/irrelevant.

Comment 10 Dan Mossor [danofsatx] 2015-05-11 19:59:01 UTC
Discussed at the 2015-05-11 blocker review meeting[0]. Voted as RejectedFreezeException.

AGREED: 1217578 - RejectedFreezeException - this bug now seems to be tracking a Rawhide-specific issue, and Rawhide issues are not F22 FEs. (adamw, 18:27:51)

[0]: http://meetbot.fedoraproject.org/fedora-blocker-review/2015-05-11/

Comment 11 Luke Macken 2015-05-12 01:39:47 UTC
Another user experienced a similar problem:

First attempt at a fresh F22 TC1 Atomic bare metal install.

addons:         com_redhat_kdump
cmdline:        /usr/bin/python2  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-22-x86_64 quiet
hashmarkername: anaconda
kernel:         4.0.0-1.fc22.x86_64
package:        anaconda-22.20.11-1
product:        Fedora
reason:         FSError: umount failed
release:        Cannot get release name.
version:        22

Comment 12 Vojtech Trefny 2015-05-12 12:23:13 UTC
Please attach program.log, storage.log and anaconda.log from failed installation. Thanks.

Comment 13 Colin Walters 2015-05-12 13:52:56 UTC
Hi Vojtech,

You should be able to get this information in more using the kickstart file from here, from today's failed build:


Comment 14 Luke Macken 2015-05-12 23:47:47 UTC
I am unable to reproduce this issue with F22 TC3.

Comment 15 Vojtech Trefny 2015-05-13 15:20:38 UTC
Proposed fix: https://vtrefny.fedorapeople.org/anaconda-images/1217578.img

Comment 16 Martín Cigorraga 2015-05-24 07:39:41 UTC
Another user experienced a similar problem:

Hello all,
These are the steps to reproduce this crash:
0. Verify that the wired interface is connected;
1. Configure language for English (American) and Suomi;
2. Configure keyboard for English and French (English international AltGr) <-- this last set as default;
3. Change my host name;
4. At the disk partitioning screen, choose "Own layout" and "Encrypted volumes";
5. Enter your desired password: mine consisting of {lower,upper}-case letters, numbers and symbols (traditional, nothing really strange);
6. Delete all unknown partitions;
7. Create /boot as ext4 w/ 330mb;
8. Create swap as swap encrypted (LUKS) w/ 2gb
9. Create / as btrfs filling remaining space, almost 300gb. First glitch I found here: there's no way to set this / btrfs partition as encrypted, the encrypt checkbox remains grayed. On my F21 Workstation install on my laptop I had no problems setting both the swap partition and the / partition as LUKS-encrypted;
10. Done, begin installation, define a root password and create a user with non-admin rights;
11. Anaconda will say 'downloading fedora-atomic/f22/docker-host IIRC then will invariably crash.

addons:         com_redhat_kdump
cmdline:        /usr/bin/python2  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-22-x86_64 quiet
hashmarkername: anaconda
kernel:         4.0.0-1.fc22.x86_64
package:        anaconda-22.20.11-1
product:        Fedora
reason:         FSError: umount failed
release:        Cannot get release name.
version:        22

Comment 17 Martín Cigorraga 2015-05-24 07:42:59 UTC
Hi again, I thought the bug report will add more 'header' information.

Anyway, I was trying to install the bare-metal install based on F22 beta, http://dl.fedoraproject.org/pub/alt/stage/22_TC1/Cloud_Atomic/x86_64/iso/Fedora-Cloud_Atomic-x86_64-22_TC1.iso.

At the time this bug is a blocker as it doesn't let me install the OS.


Comment 18 Jan Kurik 2015-07-15 14:12:36 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:

Comment 19 Fedora End Of Life 2016-11-24 11:45:29 UTC
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 20 Fedora End Of Life 2016-12-20 13:37:18 UTC
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

Thank you for reporting this bug and we are sorry it could not be fixed.

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