Bug 20164

Created attachment 8891 [details]
report.bug from Mga6 CSM install

part of this sounds very familiar, but i didn't find matching bug reports

CC: (none) => marja11, pterjan
Assignee: bugsquad => mageiatools

On QA ml, Martin Whitaker said: 

> Linux will use all the swap partitions it can find. If you run 'free -m', I
> would expect you to see a total swap size equal to the sum of the two swap
> partition sizes. So adding /dev/sda3 may be unexpected, but is not necessarily
> wrong.

Which matches what I remembered, but couldn't find.

About the other issue, https://wiki.mageia.org/en/Installing_on_systems_with_UEFI_firmware#When_to_choose_the_UEFI_mode says:

> You have other OS installed in UEFI mode (e.g. Windows 8.1 64bit), never mix
> both modes, even on separate disks. 

@ perjan

Can you please decide whether this report should be changed into an enhancement request or whether there's a real bug that needs to be fixed, or ... ?

Severity: major => normal

s/perjan/pterjan/ :-(

This is nothing new and mostly expected (I expected the swap, not the EFI but that's because I know nothing about it :) ) so even if that was a bug that's not a high priority one.

Changing this report into a request to support "mixing" UEFI and CSM mode on separate disks, because I understand the existing /dev/sda ESP getting mounted on /boot/EFI in a CSM install to /dev/sdc is Charles' biggest issue.

Lowering priority to enhancement, because to the best of my knowledge, mixing modes was never supported in Mageia, not even on separate disks.

Severity: normal => enhancement
CC: (none) => tmb
Summary: Partitions wrongly added and mounted. => Support installing in CSM mode to a disk, when an UEFI disk is present, and vice versa (Currently, a CSM install adds and mount the EFI partition on the other disk)

Created attachment 8900 [details]
Proposed fix

Tested by patching a Live system in VirtualBox and running the Live installer.

CC: (none) => mageia

commit 4367a94baced65123f56351b7dd94defd23ad931
Author: Martin Whitaker <mageia@...>
Date:   Fri Jan 27 21:18:06 2017 +0000

    Don't suggest mountpoint for ESP when doing a legacy boot install (mga#20164).
    
    When doing a UEFI install, we add a fstab entry to mount the ESP on
    /boot/EFI. This is neither required nor desirable when doing a legacy
    boot install, even if an ESP is present on the disk.
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx/commit/?id=4367a94baced65123f56351b7dd94defd23ad931

I don't think this is a real issue.
We're offering mount points for windows partitions but would no more offer one for ESP despite not using it.
I'm not strongly against the patch but I don't agree this is a bug.
I guess we'll just disagree :-)

CC: (none) => thierry.vignaud

I don't feel strongly about it either, but mounting the ESP does allow any user to write to it, and hence potentially delete important files, so I can see an argument for not mounting it unless necessary.

The counter-argument to your point about offering mount points for Windows partitions is that we don't offer them for the Windows recovery partitions. I'd suggest the guiding principle should be whether the user would reasonably want/need to access that partition.

Well only root can write there and there's already plenty of ways for root to shoot himself in the foot so...
There's plenty of other locations than root can shoot (first 10kb of each disk, randomly alter /boot/vmlinuz, deleting /lib*/libc.so*, ...).

But like I said, I don't strongly disagree so I won't go after you with a chainsaw :-)
Let's push it then...
But maybe rewrite it in order to use "return if !is_efi();" rather than adding complexity to the grep (complexity which is unrelated as what we really want is a "if (is_efi()) {...}" or my suggested "return" (less indentation)

(In reply to Thierry Vignaud from comment #11)
> Well only root can write there and there's already plenty of ways for root
> to shoot himself in the foot so...

Actually no, with a default install, any user can write to /boot/EFI. I don't know if this is something we can fix - it's a FAT filesystem, so doesn't have much protection.

commit 88b671e838dbd86b1d34e137e3979fd8cff7b29c
Author: Martin Whitaker <mageia@...>
Date:   Fri Jan 27 21:18:06 2017 +0000

    Don't suggest mountpoint for ESP when doing a legacy boot install (mga#20164).
    
    When doing a UEFI install, we add a fstab entry to mount the ESP on
    /boot/EFI. This is neither required nor desirable when doing a legacy
    boot install, even if an ESP is present on the disk.
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx/commit/?id=88b671e838dbd86b1d34e137e3979fd8cff7b29c

(In reply to Thierry Vignaud from comment #11)
> But maybe rewrite it in order to use "return if !is_efi();" rather than
> adding complexity to the grep (complexity which is unrelated as what we
> really want is a "if (is_efi()) {...}" or my suggested "return" (less
> indentation)

I rewrote it to use if_(is_uefi(), ...), as done in the suggest_mount_points() subroutine immediately above.

I still think the return line would be simpler :-)

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

(In reply to Thierry Vignaud from comment #15)
> I still think the return line would be simpler :-)

Yes, but then it wouldn't go on to suggest mount points for the Windows partitions. I guess I could have reordered the code...

(In reply to Martin Whitaker from comment #12)
> (In reply to Thierry Vignaud from comment #11)
> > Well only root can write there and there's already plenty of ways for root
> > to shoot himself in the foot so...
> 
> Actually no, with a default install, any user can write to /boot/EFI. I
> don't know if this is something we can fix - it's a FAT filesystem, so
> doesn't have much protection.


Yeah, we should really protect EFI better...

We could mount it with:

-o rw,uid=0,gid=0,umask=133,dmask=022

That would lock it down to root only

Following tmb's advice in comment 17
(ref: https://bugs.mageia.org/show_bug.cgi?id=20164#c17 )

I modified my /etc/fstab entry for /boot/EFI as follows:

a) identify line with "/boot/EFI
b) Inserted: ",rw,uid=0,gid=0,umask=133,dmask=022" after "=utf8" before "0 0"

(Note: in example below the UUID shown will probably be different on your system)

Original:
UUID=8CF0-2B13 /boot/EFI vfat umask=000,iocharset=utf8 0 0

Modified (as per tmb):
UUID=8CF0-2B13 /boot/EFI vfat umask=000,iocharset=utf8,rw,uid=0,gid=0,umask=133,dmask=022 0 0


Rebooted and checked system started OK.

After reboot, checked that /boot/EFI/ and contents are now only writable for root:

$ ls -ld /boot/EFI
drwxr-xr-x 5 root root 4096 Jan  1  1970 /boot/EFI/

$ ls -l /boot/EFI/
total 12
drwxr-xr-x 2 root root 4096 Oct 12  2022 '$RECYCLE.BIN'/
drwxr-xr-x 3 root root 4096 Jul 16  2022  EFI/
drwxr-xr-x 2 root root 4096 Oct 12  2022 'System Volume Information'/

So, this update looks like it has addressed the issue.

CC: (none) => paul.blackburn