This occurs in both Mag5 installs, using stage2-16.105.2, and in Mga6 installs, using stage2-17.71. System in question is a AMD FX-9150 with 3 SSDs. /dev/sda and /dev/sdb are both GPT and contain a UEFI install of Mga6. /dev/sdc is MSDOS table and is where a CSM install of Mga6 is to be made and it will be booted from /dev/sdc sdc contains 3 partitions, / /home and swap, and "use existing partitions" was used during this install but this BUG will occur in All partitioning modes. The Mga6 install, itself, was textbook and completed without any visible issue and I was able to reboot to a working lxde desktop. By chance I ran df [charles@localhost ~]$ uname -r 4.9.5-desktop-1.mga6 "[charles@localhost ~]$ df Filesystem Size Used Avail Use% Mounted on devtmpfs 12G 0 12G 0% /dev tmpfs 12G 124K 12G 1% /dev/shm tmpfs 12G 1.1M 12G 1% /run /dev/sdc1 49G 5.5G 44G 12% / tmpfs 12G 0 12G 0% /sys/fs/cgroup /dev/sdc6 170G 47M 170G 1% /home tmpfs 12G 4.0K 12G 1% /tmp /dev/sda1 300M 276K 300M 1% /boot/EFI tmpfs 2.4G 8.0K 2.4G 1% /run/user/1000 [charles@localhost ~]$" which looked off|wrong I look at /etc/fstab expecting to see this: # Entry for /dev/sdc1 : UUID=f16bfb76-e142-4738-853e-ace245fcf46b / reiserfs relatime,user_xattr,notail 1 1 # Entry for /dev/sdc6 : UUID=28527933-12ac-4567-a8ef-16be83378b19 /home reiserfs relatime,user_xattr,notail 1 2 none /proc proc defaults 0 0 # Entry for /dev/sdc5 : UUID=18f9cb85-763c-4e49-8a1f-607f7beef949 swap swap defaults 0 0 but instead I find this: # Entry for /dev/sdc1 : UUID=f16bfb76-e142-4738-853e-ace245fcf46b / reiserfs relatime,user_xattr,notail 1 1 # Entry for /dev/sda1 : UUID=6756-839C /boot/EFI vfat umask=0,iocharset=utf8 0 0 # Entry for /dev/sdc6 : UUID=28527933-12ac-4567-a8ef-16be83378b19 /home reiserfs relatime,user_xattr,notail 1 2 none /proc proc defaults 0 0 # Entry for /dev/sda3 : UUID=8a8aa4c8-c761-42e4-82ca-4721b970b22b swap swap defaults 0 0 # Entry for /dev/sdc5 : UUID=18f9cb85-763c-4e49-8a1f-607f7beef949 swap swap defaults 0 0 Notice the 2 /dev/sda partitions that the installer needlessly and wrongly added. I am attaching the report.bug created at the completion of the Mga6 installation.
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, pterjanAssignee: 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 => enhancementCC: (none) => tmbSummary: 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)
Summary: 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) => Support installing in CSM mode to a disk, when an UEFI disk is present, and vice versa (Currently, a CSM install adds and mounts 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
Keywords: (none) => PATCH
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) => FIXEDStatus: 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