[solved] I want to install MX-18.3 to partition #19 on my HDD, but...

[dolphin_oracle]

Ok great thanks.

I've got a working theory that I need to test. Thanks for sticking with this. If my local test works out I'll have something for you to try to confirm.

[dolphin_oracle]

I've duplicated your environment in a test situation. the problem is in the filter that removes the boot device from the list of available install devices.

to test.

edit /usr/share/gazelle-installer-data/installer.conf and change the "INSTALL_FROM_ROOT" from false to true. start minstall as usually and see if your partitions show up.

[jbMacAZ]

Changing "INSTALL_FROM_ROOT_DEVICE" to true does give me the other partitions.

[dolphin_oracle]

Ok great!

I've narrowed the problem with drive listing down to a weird issue in lsblk that the installer code doesn't account for. what happens is that for some reason, partitions after 15 are listed after all other drivers are also listed. so you get sda1-15, sdb1-15, sdc-1-15, then sda15-? and so on. the problem comes when we apply the "isBoot" parameter, where partitions after the boot drive get tagged as boot partitions as well. the bug is broken when you insert a second usb disk because that disk is listed between the boot disk and the extra +15 partitions, and since that disk is not a boot disk, the extra partitions aren't tagged as boot partitions.

This shouldn't be too hard to fix, now that we have the problem zeroed in. Thank you!

[jbMacAZ]

You're welcome! I was beginning to suspect that some status was getting stuck after the boot device partitions, reset by an extra device in the list. Very weird that the partitions weren't all together... I guess that's cruft on an old drive that has been re-partitioned a time or two.

[fehlix]

This shouldn't be too hard to fix, now that we have the problem zeroed in.

A quick fix, without changing to much logic within the code would be to sort the output of lsblk by the 2nd field,
so that the isBoot-tag get's not wrongly assigned for partitions above 15:

Code: Select all

lsblk -brno TYPE,NAME,UUID,SIZE,PARTTYPE,FSTYPE,LABEL,MODEL | LANG=C sort -k2 

would produce somethig like:

Code: Select all

loop loop0  1413382144  squashfs   
disk sda  1000204886016    TOSHIBA\x20DT01ACA1
part sda1 08A4-5E19 524288000 c12a7328-f81f-11d2-ba4b-00a0c93ec93b vfat ESP 
part sda10 1031ac34-1399-4498-976f-58fdedb3044b 27262976000 0fc63daf-8483-4772-8e79-3d69d8477de4 ext4  
part sda11 36920ff9-36e1-43ff-94e4-58985e78bd89 163577856000 0fc63daf-8483-4772-8e79-3d69d8477de4 ext4 projects 
part sda12 51c60e72-96d0-4fa3-8b3d-4361022b3587 104857600000 0fc63daf-8483-4772-8e79-3d69d8477de4 ext4 bisect 
part sda13 b676e546-9459-4d8e-9720-c1e7e3fdcc3c 42297458688 0fc63daf-8483-4772-8e79-3d69d8477de4 ext4  
part sda14 b05b83da-d22f-4dec-bf01-c63f2b1e12de 18874368000 44479540-f297-41b2-9af7-d131d5f0458a ext4 rootMX18.3 
part sda15 9f5352a2-bcc3-4a83-858f-5d455fcf7b11 43332403200 0fc63daf-8483-4772-8e79-3d69d8477de4 ext4 Spare 
part sda16 b8e1d2b0-c2dc-4d1f-b1fe-511d4045ce33 209776017408 0fc63daf-8483-4772-8e79-3d69d8477de4 ext4 Backup 
part sda17 d8cd1ae8-8a9e-40ea-8170-ed0f0e029300 33003929600 0fc63daf-8483-4772-8e79-3d69d8477de4 ext4  
part sda18 727b02f4-53f0-42e2-9a58-2ba75f7a7922 29198647296 0fc63daf-8483-4772-8e79-3d69d8477de4 ext4  
part sda19 87c92711-adfa-4a47-8df1-7cf2afdd9a18 29541531648 44479540-f297-41b2-9af7-d131d5f0458a ext4 MXLinux 
part sda2  134217728 e3c9e316-0b5c-4db8-817d-f92df00215ae   
part sda20 a2268d9e-fa4b-49db-b381-1fa7f0d1b1d6 17904435200 44479540-f297-41b2-9af7-d131d5f0458a ext4 homeMX 
part sda21 d7a86f99-16e2-4b6e-8c50-166856186622 18323865600 0657fd6d-a4ab-43c4-84e5-0933c84b4f4f swap  
part sda22 68034b16-7395-4c48-9a28-4db4454ba320 27713863680 0fc63daf-8483-4772-8e79-3d69d8477de4 ext4 MiscLinux 
part sda3 3648FF5E48FF1B77 105793978368 ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 ntfs OS 
part sda4 C67EB4A77EB49223 32505856000 ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 ntfs Shared 
part sda5 90CC6126CC610834 471859200 de94bba4-06d1-4d40-a16a-bfd50179d6ac ntfs WINRETOOLS 
part sda6 2EC662C7C6628EC1 12474908672 de94bba4-06d1-4d40-a16a-bfd50179d6ac ntfs Image 
part sda7 4c60405c-d022-4d95-bf92-e1b151e8992e 47504687104 0fc63daf-8483-4772-8e79-3d69d8477de4 ext4 MINT 
part sda8 5b990e61-9ddb-428c-b4d8-eaf70f9bdbe5 17825792000 0657fd6d-a4ab-43c4-84e5-0933c84b4f4f swap  
part sda9 c1d808de-60cc-44af-9fd2-c47a270e9aa4 17301504000 0fc63daf-8483-4772-8e79-3d69d8477de4 ext2  
disk sdb  30752636928    Ultra\x20Fit\x20\x20\x20\x20\x20\x20\x20
part sdb1 1a5f3c48-5e96-4718-b53e-5bbe7af0eeff 23009951744 0x83 ext4 Live-usb 
part sdb2 9910-BC36 52428800 0xef vfat Live-uefi 
disk sdc  32229130240    Mass\x20Storage\x20\x20\x20\x20
part sdc1 CC36-80A8 31457214464 0xc vfat  
rom sr0  1073741312    DVD+-RW\x20SU-208GB

[jbMacAZ]

With the unsanctioned workaround, I was able to install MX18.3 to /dev/sda19 with /home on sda20. Grub install failed (complained about error writing NVRAM). I think the conflict comes from the MX-Linux already on sda14 or perhaps the USB install's grub which is still first in boot order. But Manjaro owns my grub and it found and boots both MX HDD installs. I'll mark this solved when the official fix is verified. Thanks again for the support.

[jbMacAZ]

I tested the new antiX19b3 ISO and its installer "sees" all of my suitable partitions. Thank you.

I still had to adjust the .efi files in the FAT32 ESP partition, to get antiX liveUSB to boot. debian-live-10.0.0-amd64-cinnamon.iso has the same problem and the mmx64.efi workaround also works. I have to assume this has more to do with some peculiarity of my system rather being a widespread issue.

[fehlix]

I tested the new antiX19b3 ISO and its installer "sees" all of my suitable partitions. Thank you.

I still had to adjust the .efi files in the FAT32 ESP partition, to get antiX liveUSB to boot. debian-live-10.0.0-amd64-cinnamon.iso has the same problem and the mmx64.efi workaround also works. I have to assume this has more to do with some peculiarity of my system rather being a widespread issue.

You might check whether you have a not-yet enrolled MOK key pending for enrollment. (That's stored with the UEFI.)
If so even when booting with disabled secure boot, it might be that UEFI tries to trigger the enrollment process during boot.
You can check enrolled and not-yet enrolled (new) MOK-keys, after installing "mokutil"
with this

Code: Select all

sudo mokutil --list-new

and/or

Code: Select all

sudo mokutil --list-enrolled

If anything is showing up you might "clear" the MOK-list with

Code: Select all

mokutil --reset

What I'm unsure about it is the "reset", whether this would work without having mokmanager in place when booting.
Perhaps you boot with ISO which provide a mokmanager (latest Debian / Ubuntu),

[jbMacAZ]

The list-new had two keys for openSUSE, the list-enrolled was empty. Resetting did clear the list-new, without needing mokmanager. The problem still persists, except with the suggested .efi workaround.