Bug 1236937 - anaconda does not write /etc/fstab on live install
Summary: anaconda does not write /etc/fstab on live install
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 23
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F23AlphaBlocker
TreeView+ depends on / blocked
Reported: 2015-06-30 04:14 UTC by Chris Murphy
Modified: 2015-07-20 23:22 UTC (History)
19 users (show)

Fixed In Version: anaconda-23.16-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-07-20 23:22:02 UTC
Type: Bug

Attachments (Terms of Use)
bad fstab (428 bytes, text/plain)
2015-06-30 04:15 UTC, Chris Murphy
no flags Details
anaconda.log (42.04 KB, text/plain)
2015-06-30 04:15 UTC, Chris Murphy
no flags Details
program.log (37.66 KB, text/plain)
2015-06-30 04:15 UTC, Chris Murphy
no flags Details
storage.log (232.95 KB, text/plain)
2015-06-30 04:15 UTC, Chris Murphy
no flags Details

Description Chris Murphy 2015-06-30 04:14:30 UTC
Description of problem: /etc/fstab is malformed, /boot, /boot/efi, /home are not mounted, and swap is not activated. (Actually I don't mind that /boot and /boot/efi aren't persistently mounted, they shouldn't be anyway, but this is probably unintended).

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

How reproducible:

Steps to Reproduce:
1. Default automatic installation to a blank drive, only added option was encryption enabled.
2. install and reboot

Actual results:

Per above, things that are normally mounted/activated aren't. See /etc/fstab attached.

Expected results:

A proper fstab so the system assembles correctly at boot time.

Additional info:

Comment 1 Chris Murphy 2015-06-30 04:15:06 UTC
Created attachment 1044542 [details]
bad fstab

Comment 2 Chris Murphy 2015-06-30 04:15:18 UTC
Created attachment 1044543 [details]

Comment 3 Chris Murphy 2015-06-30 04:15:28 UTC
Created attachment 1044544 [details]

Comment 4 Chris Murphy 2015-06-30 04:15:38 UTC
Created attachment 1044545 [details]

Comment 5 Fedora Blocker Bugs Application 2015-06-30 04:23:37 UTC
Proposed as a Blocker for 23-alpha by Fedora user chrismurphy using the blocker tracking app because:

 "The installed system must be able to download and install updates with the default console package manager."

Since /boot isn't in fstab, kernel updates definitely won't succeed. There may be other things that fail too, but /home not mounting just means the /home directory on root fs is used instead, which is a silent soft fail.

Comment 6 Adam Williamson 2015-06-30 05:51:36 UTC
what image, exactly, did you install with?

Comment 7 Chris Murphy 2015-06-30 14:32:02 UTC

Comment 8 Chris Murphy 2015-07-06 19:02:54 UTC
100% reproducible on vbox uefi with Fedora-Live-Workstation-x86_64-rawhide-20150704.iso, even without encryption. I haven't tried BIOS yet. +1 blocker.

Comment 9 Chris Murphy 2015-07-07 14:24:10 UTC
Also happens in qemu-kvm (virt-manager and boxes), so BIOS is affected. This happens with both automatic/guided and custom installations. So far I can't avoid hitting this bug.

Comment 10 Kamil Páral 2015-07-10 11:28:13 UTC
The same problem has been reported today by twohot on #fedora-qa IRC.

Comment 11 David Lehman 2015-07-10 16:15:43 UTC
This /etc/fstab was written by systemd or dracut -- not anaconda or blivet. Note the missing header indicating it was written by anaconda.

Comment 12 David Lehman 2015-07-10 16:19:02 UTC
I think the problem is actually that anaconda isn't writing out an /etc/fstab so the system is getting the /etc/fstab from the live environment. My money's on commit 3e800998.

Comment 13 Adam Williamson 2015-07-13 16:26:46 UTC
Discussed at 2015-07-13 F23 blocker review meeting: http://meetbot-raw.fedoraproject.org/fedora-blocker-review/2015-07-13/f23-blocker-review.2015-07-13-16.03.log.txt . Accepted as an Alpha blocker per criterion cited in comment #5.

Comment 14 Adam Williamson 2015-07-15 20:52:13 UTC
Looks like this doesn't affect boot.iso installs, only lives - I did an install from the 2015-07-14 nightly boot.iso (with updates.img fixing the various other bugs in that) and got a /etc/fstab written by anaconda which has a /boot entry. I agree with dlehman that 3e800998 looks like the obvious suspect, I'll try and dig into that and figure out what's going wrong.

Comment 15 Adam Williamson 2015-07-15 21:45:15 UTC
So it seems that self.method.method is 'harddrive' when that test is triggered, not 'liveimg'. That's why the test fails. I don't know if that's right or wrong.

Comment 16 Adam Williamson 2015-07-15 21:46:57 UTC
Oh, sorry, missed a bit. Where this goes wrong is the first 'if' statement in writeStorageLate():

if self.data.method.method == "liveimg" and not flags.dirInstall:

I stuck in a debug log message to report what self.data.method.method actually is, and it seems that with a 2015-07-04 nightly live install (the last image I have handy that works), it's 'harddrive', not 'liveimg'. That's the problem. I don't know if the 'if' statement is incorrect or if self.data.method.method really ought to be 'liveimg'.

Comment 17 Adam Williamson 2015-07-15 21:50:36 UTC
Note that before 3e800998 , the equivalent test looked like this:

    write_storage_late = (flags.flags.livecdInstall or ksdata.ostreesetup.seen
                          or ksdata.method.method == "liveimg")

i.e. it also checked for flags.flags.livecdInstall (and OStree cases). The only other point in anaconda source which looks for a 'liveimg' method is the Anaconda class's 'payload' property:

                elif flags.livecdInstall:
                    from pyanaconda.packaging.livepayload import LiveImagePayloa
                    klass = LiveImagePayload
                elif self.ksdata.method.method == "liveimg":
                    from pyanaconda.packaging.livepayload import LiveImageKSPayload
                    klass = LiveImageKSPayload

that leads me to suspect that the 'liveimg' method is something fairly unusual (some kind of kickstarted live payload?) and we should be checking for flags.livecdInstall as well as 'liveimg' method here, as the old check did.

Comment 18 Adam Williamson 2015-07-15 21:51:57 UTC
Per https://github.com/rhinstaller/pykickstart/blob/master/docs/kickstart-docs.rst#liveimg , I think ksdata.method.method is only 'liveimg' if we're installing from a kickstart with the 'liveimg' parameter, it isn't 'liveimg' on a normal live image install.

Comment 19 Adam Williamson 2015-07-15 22:41:43 UTC

Comment 20 Adam Williamson 2015-07-20 23:22:02 UTC
This is fixed in 23.16, and the 07-17 nightlies.

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