Description of problem: UEFI install in VM system with 3 existing installations on 2 HD has problems if another HD is added and the "use free space" is selected. sda had two installs, ESP and swap with about 4GB free space. sdb was full with the root of an installation sdc was a new un-formatted 8GB GPT drive On selecting "Use free space" the installer stopped, complaining that there was insufficient space for a minimal mate install, so I switched to LXDE and on again selecting "use free space" it instantly formatted something (far to quick to read) and immediately set off installing. On completion it booted OK, however on inspecting the partition layout it had created another ESP (300MB) and /, both in the small free space on sda and allocated half of the new sdc drive (4GB) to another swap partition. Surely it should use the existing ESP and swap if they already exist. More importantly with a new 8GB drive available why did it fail to install Mate saying there was insufficient space? Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Reproducible: Steps to Reproduce:
Created attachment 6058 [details] Partition allocation view
The 2ns ESP issue was fixed today (bug #15366) The "use free space" uses free space on the selected disk. So you should have selected the right disk in the selector on top of the wizard. *** This bug has been marked as a duplicate of bug 15366 ***
Status: NEW => RESOLVEDCC: (none) => thierry.vignaudResolution: (none) => DUPLICATE
There was no "right disk" as I asked it to "use free space" which it did across two disks. What the bug is about is the bad choices made regarding what (and how much) to put where. Why say that there is insufficient space (for Mate) when an 8GB drive is empty? Why allocate 4GB of swap when a swap already exists? Are you sure that the drive selection at the top affects this? There was a lot of discussion recently about the "use free space" option and it was determined that free space anywhere could be used, which is partly confirmed by the fact that space was used on two drives in this test. I would have expected that the existing swap would have been used and that the / would have been put on the empty drive using possibly all of it, since at the partitioning stage the installer does not know what DE etc. will be chosen. So, are you saying that if the empty drive had been 'selected' then that would have happened? I will re-test. I don't see how this is a duplicate of (bug #15366) as "use free space" is not mentioned there.
I re-tested this install after deleting the partitions created by the previous test, leaving sdc empty, and around 3GB free on sda. I switched to sdc in the partitioning stage and selected "use free space". The GUI showed Mageia occupying the whole of the drive, which looked promising as you had indicated. I continued with the install but again hit the "Insufficient space" issue, and the used/available gauge in the package selection dialog showed only 2555 MB available. I completed a minimal install, selecting to put the bootloader in the system '/' so as not to write into the ESP, intending to boot from another system on sda2. On reboot the system booted into the new install's grub2 (which it should not have done). I will open another bug about this. On checking the drive layout it is exactly as in the previous test install, so having sdc selected when choosing "use free space" made no difference.
Status: RESOLVED => REOPENEDResolution: DUPLICATE => (none)
First: again please don't mix tons of issues in the same bug. The original issue in the title is fixed. This is becoming unreadable... So please open new bug reports about specific issues. With report.bug.xz as an attachment. With the drakx version used. Last but not least, the disk selector is at top of wizard: See "Here is the content of your disk drive" at: https://doc.mageia.org/installer/4/en/content/doPartitionDisks.html
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
(In reply to Thierry Vignaud from comment #5) > Last but not least, the disk selector is at top of wizard: > See "Here is the content of your disk drive" at: > https://doc.mageia.org/installer/4/en/content/doPartitionDisks.html Which is exactly where I selected it.
Created attachment 6135 [details] report.bug.xz
Comment on attachment 6135 [details] report.bug.xz Please stop testing outdated installer (DrakX v16.65) We are currently at 16.71...
Attachment 6135 is obsolete: 0 => 1
Created attachment 6138 [details] report.bug.xz Re-tested using boot.iso Same result - attaching new report.bug.xz Also a second ESP is still created (another issue I know, should I re-open the specific bug about that?)
(In reply to Thierry Vignaud from comment #8) > Please stop testing outdated installer (DrakX v16.65) > We are currently at 16.71... (In reply to Barry Jackson from comment #9) > Created attachment 6138 [details] > report.bug.xz > > Re-tested using boot.iso > Same result - attaching new report.bug.xz Sorry, Barry, your mirror wasn't up-to-date, you used 16.70, which didn't contain the fix "* second stage install running (DrakX v16.70)" A lot of mirrors are lagging behind, and even if Jussieux last synced around midnight, so after the fixed stage2 was pushed, it did not contain the updated package when I checked this morning
CC: (none) => marja11
I notice the above was using DrakX v16.70 so I will repeat later when mirror syncs with 16.72.
This one is up to date: http://mageia.c3sl.ufpr.br/distrib/cauldron/x86_64/
Attachment 6138 is obsolete: 0 => 1
Created attachment 6139 [details] report.bug.xz OK retested with 16.72 installed with sdc 'selected' and 'use free space' option. sda had 3GB only free space sdb was full (8GB) sdc was empty (8GB) No change: A second ESP is created as sda5 A second 3.9GB swap is added as sdc1 Root is created as sda6 *NOT* sdcX [baz@localhost ~]$ df Filesystem Size Used Avail Use% Mounted on devtmpfs 1.5G 0 1.5G 0% /dev tmpfs 1.5G 76K 1.5G 1% /dev/shm tmpfs 1.5G 488K 1.5G 1% /run /dev/sda6 3.0G 1.4G 1.5G 49% / tmpfs 1.5G 0 1.5G 0% /sys/fs/cgroup tmpfs 1.5G 4.0K 1.5G 1% /tmp /dev/sda5 300M 132K 300M 1% /boot/EFI /dev/sda1 299M 136K 299M 1% /media/windows tmpfs 300M 8.0K 300M 1% /run/user/1000 /dev/sr0 39M 39M 0 100% /run/media/baz/Mageia-5-x86_64-netinstall
blkid from running new install (in case it's of use) [root@localhost baz]# blkid /dev/sda1: UUID="C4F1-B06B" TYPE="vfat" PARTUUID="c2d241ea-884b-419a-ba48-4c24934773b1" /dev/sda2: LABEL="Mate_root" UUID="40dde9af-7826-411a-af7d-2e57daa99aaf" TYPE="ext4" PARTUUID="9b170d03-68e8-4e1f-ba6f-76a0f4668d37" /dev/sda3: UUID="c9bc0f6d-5015-4a0a-959d-a07cadc83c88" TYPE="swap" PARTUUID="42ebede7-4690-4524-881b-49ce68c146c8" /dev/sda4: LABEL="KDEMga4" UUID="b6fd4dae-1031-45df-a031-999b7e9ae2f2" TYPE="ext4" PARTUUID="b79fee32-7d75-4ef0-b983-33b2b8a9f32f" /dev/sda5: UUID="9CD0-1CDF" TYPE="vfat" PARTUUID="88f452a5-9f71-47ab-b06a-2065abed9146" /dev/sda6: UUID="b07f8768-9977-4b41-951f-049573c30af1" TYPE="ext4" PARTUUID="08804400-4e7d-4610-bc6d-1d78dbd777ad" /dev/sdb1: UUID="51c4911d-336b-4867-9b3a-3e4aa7c5d02c" TYPE="ext4" PARTUUID="9deb8d21-8123-4567-aa74-94999dc57cc9" /dev/sdc1: UUID="99d10b5c-ca5d-4c91-a4d2-fe42f4e82afa" TYPE="swap" PARTUUID="8d39c613-43f6-4229-b392-ae978cd7dbf0" /dev/sr0: UUID="2015-03-24-21-23-34-00" LABEL="Mageia-5-x86_64-netinstall" TYPE="iso9660" PTUUID="15076b4b" PTTYPE="dos"
Created attachment 6140 [details] Screen shot at partitioning screen showing sdc selected
If a 2nd ESP partition was created, I guess it's b/c previous one wasn't tagged as ESP. Check with fdisk or cfdisk which must show "EFI System" in the "Type" Column. For ESP, the partition GUID _must_ be "C12A7328-F81F-11D2-BA4B-00A0C93EC93B" Else it's treated as a standard FAT partition See https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs
(In reply to Thierry Vignaud from comment #16) > If a 2nd ESP partition was created, I guess it's b/c previous one wasn't > tagged as ESP. > Check with fdisk or cfdisk which must show "EFI System" in the "Type" Column. > > For ESP, the partition GUID _must_ be "C12A7328-F81F-11D2-BA4B-00A0C93EC93B" > Else it's treated as a standard FAT partition > See https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs Thanks for the explanation, Thierry (in Barry's logs, fdisk did indeed see the first "ESP" as "Linux filesystem" instead of as "EFI System") CC'ing docteam, because it might be good to add this to the documentation about EFI-installing
CC: (none) => doc-bugs
(In reply to Thierry Vignaud from comment #16) > > For ESP, the partition GUID _must_ be "C12A7328-F81F-11D2-BA4B-00A0C93EC93B" @ docteam It is probably overkill to tell users how to see the partition GUID, but in case we decide it is useful: if the ESP is on sda, do : # gdisk /dev/sda and type the ESP partition number after "Command (? for help):" and then type "q" to quit as shown below: [root@Mga5RC_EFI marja]# gdisk /dev/sda GPT fdisk (gdisk) version 0.8.10 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Command (? for help): i Partition number (1-12): 2 Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI System) Partition unique GUID: 74A19D5C-6445-4E6A-8FB0-FE7E46E5B33C First sector: 2050048 (at 1001.0 MiB) Last sector: 2582527 (at 1.2 GiB) Partition size: 532480 sectors (260.0 MiB) Attribute flags: 0000000000000000 Partition name: 'EFI system partition' Command (? for help): q [root@Mga5RC_EFI marja]#
Note that having a bogus ESP partition tagged as "linux filesystem" instead of "EFI System" would likely be the result of a previous bogus Mageia install (mainly beta3).
Yes that's about when I created this VM. I fixed the ESP with gdisk: Partition number (1-6): 1 Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI System) Partition unique GUID: C2D241EA-884B-419A-BA48-4C24934773B1 First sector: 2048 (at 1024.0 KiB) Last sector: 614400 (at 300.0 MiB) Partition size: 612353 sectors (299.0 MiB) Attribute flags: 0000000000000000 Partition name: '' On re-installing as per previous tests the installer still creates a second 300MB vfat partition at sda5 in the 3GB free space which is mounted as /boot/EFI but it has the wrong GUID: Partition number (1-6): 5 Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem) Partition unique GUID: AD01FB3F-5C75-444E-9D46-49C6AD22A0A8 First sector: 23330816 (at 11.1 GiB) Last sector: 23945215 (at 11.4 GiB) Partition size: 614400 sectors (300.0 MiB) Attribute flags: 0000000000000000 Partition name: ' [root@localhost baz]# df Filesystem Size Used Avail Use% Mounted on devtmpfs 1.5G 0 1.5G 0% /dev tmpfs 1.5G 80K 1.5G 1% /dev/shm tmpfs 1.5G 488K 1.5G 1% /run /dev/sda6 3.0G 1.4G 1.5G 49% / tmpfs 1.5G 0 1.5G 0% /sys/fs/cgroup tmpfs 1.5G 20K 1.5G 1% /tmp /dev/sda5 300M 132K 300M 1% /boot/EFI /dev/sda1 299M 508K 298M 1% /media/windows tmpfs 300M 8.0K 300M 1% /run/user/1000 /dev/sr0 39M 39M 0 100% /run/media/baz/Mageia-5-x86_64-netinstall [root@localhost baz]# It puts the / at sda6 and creates a second swap 3.9GB on sdc as before. I will attach report.bug.xz later - g2g just now.
Created attachment 6142 [details] report.bug.xz
Attachment 6139 is obsolete: 0 => 1
Oh dammit !! Looks like my mirror updated with d-c and downgraded drakx. Forget #20 and #21 Back to the drawing board :\
Comment on attachment 6142 [details] report.bug.xz (In reply to Barry Jackson from comment #22) > Oh dammit !! Looks like my mirror updated with d-c and downgraded drakx. > Forget #20 and #21 > Back to the drawing board :\ I never tried to rsync with the -u switch, but maybe that would prevent downgrading: -u, --update skip files that are newer on the receiver
Attachment 6142 is obsolete: 0 => 1
OK with a correct ESP and the correct drakx the installer stops after the partitioning page with this dialog: "You must have a ESP FAT32 partition mounted in /boot/EFI" After OK, it dropped back to the partitioner which still offered using the free space on sdc, which was the remaining 4GB as the un-needed extra swap had already been created. Accepting this failed with "Partitioning failed. Not enough free space for auto-allocating." So with larger disks this would probably have worked *if* it had found the ESP. After the last message I opted for custom partitioning and the ESP mount point was already correctly set to sda1!
(In reply to Marja van Waes from comment #23) > > I never tried to rsync with the -u switch, but maybe that would prevent > downgrading: > > -u, --update skip files that are newer on the receiver Thanks for that - I will check it out!
Created attachment 6143 [details] report.bug.xz Note that the custom partitioning was continued to completion with the extra swap on sdc removed and / placed on sda6.
(In reply to Marja van Waes from comment #23) > -u, --update skip files that are newer on the receiver Since the newer files on the receiver have different versions and hence different file names they do not exist on the sender and are thus deleted. I have switched to mirrorservice.org (uk) which is fast and seems to be up-to-date.
Re-tested with new RC iso (29 March). Same issue of trying to use small space for root on a disk which is NOT selected when there is 20GB free on 'selected' disk.
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
Created attachment 6162 [details] report.bug.xz Re-tested with DrakX v16.75 With a clean empty drive 'selected' (sdb), 'use free space' puts / on sda and puts a second swap (3.9GB) on sdb. A 1GB swap was already available on sda.
Attachment 6143 is obsolete: 0 => 1
At least it doesn't create a new ESP anymore...
(In reply to Thierry Vignaud from comment #30) > At least it doesn't create a new ESP anymore... True - well done :)
Let's handle the issue about partitions on several disks in bug #16055 *** This bug has been marked as a duplicate of bug 16055 ***
Status: REOPENED => RESOLVEDResolution: (none) => DUPLICATE