Bug 15627 - ESP not mounted in running system, when Mageia is the only EFI system on external HD (hybrid BIOS)
Summary: ESP not mounted in running system, when Mageia is the only EFI system on exte...
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: High critical
Target Milestone: ---
Assignee: Thierry Vignaud
QA Contact:
URL:
Whiteboard:
Keywords: PATCH
Depends on:
Blocks:
 
Reported: 2015-04-05 01:00 CEST by Barry Jackson
Modified: 2015-05-18 04:31 CEST (History)
0 users

See Also:
Source RPM:
CVE:
Status comment:


Attachments
report.bug.xz (167.52 KB, application/x-xz)
2015-04-05 01:06 CEST, Barry Jackson
Details
do not set noauto for /boot/EFI (344 bytes, patch)
2015-05-07 13:25 CEST, Thierry Vignaud
Details | Diff

Description Barry Jackson 2015-04-05 01:00:54 CEST
Description of problem:
Installed RC to an external gpt USB hard drive in EFI mode, using classic KDE DVD iso on a USB stick (created for UEFI by isodumper)

Current cauldron media also enabled plus efibootmgr from updates_testing in another local repo.

Install went fine and system rebooted without problem.
However on further testing I notice that the ESP is not mounted in the running system, despite it being in fstab.
grub2-install fails with error reporting it can't find ESP.
Mounting the ESP manually fixes this.


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


How reproducible:


Steps to Reproduce:
1.
2.
3.


Reproducible: 

Steps to Reproduce:
Comment 1 Barry Jackson 2015-04-05 01:06:21 CEST
Created attachment 6186 [details]
report.bug.xz

report.bug.xz from system.
Comment 2 Barry Jackson 2015-04-05 01:22:32 CEST
fstab: (The ESP is commented as"# Entry for /dev/sdj1 :"

# Entry for /dev/sdi5 :
UUID=24cc4668-8284-4946-854f-3062b027f70c / ext4 noatime,acl 1 1
# Entry for /dev/sdi1 :
UUID=F4C3-3A1B /boot/EFI vfat umask=000,users,iocharset=utf8,exec,noauto,nofail 0 0
# Entry for /dev/sdi7 :
UUID=ea6ff462-7704-4e1b-852a-68bc144730ee /home ext4 noatime,acl,nofail 0 0
# Entry for /dev/sdj1 :
UUID=9154-7FF4 /mnt/hd vfat umask=000,users,exec,iocharset=utf8,noauto,nofail 0 0
none /proc proc defaults 0 0
# Entry for /dev/sdb5 :
UUID=ccb587c1-6761-4261-b402-b48aa1d8842e swap swap defaults 0 0
# Entry for /dev/sdb6 :
UUID=1097bb8c-3820-4b3a-b796-b417c9aa56d8 swap swap defaults 0 0
# Entry for /dev/sdi6 :
UUID=bf663611-062d-4482-b2a8-20656dfa9979 swap swap defaults,nofail 0 0


However there is also an fstab.old:

# Entry for /dev/sdi5 :
UUID=24cc4668-8284-4946-854f-3062b027f70c / ext4 noatime,acl 1 1
# Entry for /dev/sdi1 :
UUID=F4C3-3A1B /boot/EFI vfat umask=0,users,iocharset=utf8,exec,noauto,nofail 0 0
# Entry for /dev/sdi7 :
UUID=ea6ff462-7704-4e1b-852a-68bc144730ee /home ext4 noatime,acl,nofail 0 0
# Entry for /dev/sdj1 :
UUID=9154-7FF4 /mnt/hd vfat umask=0,users,exec,iocharset=utf8,noauto,nofail 0 0
none /proc proc defaults 0 0
# Entry for /dev/sdb5 :
UUID=ccb587c1-6761-4261-b402-b48aa1d8842e swap swap defaults 0 0
# Entry for /dev/sdb6 :
UUID=1097bb8c-3820-4b3a-b796-b417c9aa56d8 swap swap defaults 0 0
# Entry for /dev/sdi6 :
UUID=bf663611-062d-4482-b2a8-20656dfa9979 swap swap defaults,nofail 0 0

The only difference is that the umask on the ESP was changed 14 minutes after the initial file creation on first reboot I guess.
No idea yet if this is affecting anything - just observations.

Priority: Normal => release_blocker

Comment 3 Barry Jackson 2015-04-05 01:31:13 CEST
Bah! It's late! Sorry. The ESP is UUID=F4C3-3A1B /boot/EFI obviously.

/OT
The other vfat entry (UUID=9154-7FF4 /mnt/hd vfat) is the USB stick used for the install - not sure why that would be in fstab.
Comment 4 Barry Jackson 2015-04-05 02:09:23 CEST
Changing the fstab entry from:
UUID=F4C3-3A1B /boot/EFI vfat umask=000,users,iocharset=utf8,exec,noauto,nofail 0 0
to:
UUID=F4C3-3A1B /boot/EFI vfat umask=000,iocharset=utf8 0 0
Does mount the ESP on boot

[baz@localhost ~]$ df
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        3.9G     0  3.9G   0% /dev
tmpfs           3.9G  1.3M  3.9G   1% /dev/shm
tmpfs           3.9G  824K  3.9G   1% /run
/dev/sdf5        50G  4.1G   43G   9% /
tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
tmpfs           3.9G  4.0K  3.9G   1% /tmp
/dev/sdf1       299M  132K  299M   1% /boot/EFI
/dev/sdf7        48G  301M   48G   1% /home
tmpfs           789M   12K  789M   1% /run/user/1000

I'm not suggesting that this would be correct in this case, just testing that it works (the replacement line was pulled from a working fstab I have in a VM).
Comment 5 Barry Jackson 2015-04-05 10:38:42 CEST
Dropping priority as I now realize that this is more of a corner case, since 99% of systems would have a normally mounted ESP on a non-removable drive.

I have no other UEFI systems on this machine as it has a dual BIOS, so Mageia has put the ESP on the USB drive.

However, I think this should still work, and provision should be provided so it does.

Many people switching from legacy BIOS to UEFI will want to make test installations on a removable drive before committing to a full change over, so this situation can arise.

Priority: release_blocker => High
Summary: ESP not mounted in running system => ESP not mounted in running system, when Mageia is the only EFI system on external HD (hybrid BIOS)

Comment 6 Thierry Vignaud 2015-05-07 13:25:27 CEST
Created attachment 6464 [details]
do not set noauto for /boot/EFI

This should do it
(side effect of http://gitweb.mageia.org/software/drakx/commit/perl-install?id=745849cdace7ed86ce12a9a7564bffb42edf0ef3)
Thierry Vignaud 2015-05-07 13:27:27 CEST

Keywords: (none) => PATCH

Comment 7 Mageia Robot 2015-05-08 15:19:59 CEST
commit ae5b3ce9845669227ef06c90dfaa1065a7ceebe8
Author: Thierry Vignaud <thierry.vignaud@...>
Date:   Thu May 7 07:36:41 2015 -0400

    do not set noauto for /boot/EFI (mga#15627)
    
    side effect of (side effect of commit 745849cdace7ed86ce12a9a7564bffb42edf0ef3)
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx/commit/?id=ae5b3ce9845669227ef06c90dfaa1065a7ceebe8
Comment 8 Thierry Vignaud 2015-05-18 04:31:32 CEST
Closing

Status: NEW => RESOLVED
Resolution: (none) => FIXED


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