When I plug in a storage with Mageia 7.1 Live iso dumped to it using Isodumper with or without persistence, in diskdrake I can select it and edit partitions. Using a Mageia 8 (beta 2) Live, it is not even listed. The same for a self made custom 7.1 Live.
CC: (none) => mageia
If you are using Mageia 7 diskdrake, I would expect it not to see the 64-bit ISOs or a custom 32-bit ISO, but to see the official 32-bit ISOs. That is true of the two 8-beta2 USB sticks I have to hand (Xfce 32-bit and 64-bit). Mageia 8 diskdrake should see them all (bug 25224).
OK Ah seems I missed tracking that bug. Any chance of updating mga7 diskdrake?
I cannot read the partition table of device sdh, it's too corrupted for me :( I can try to go on, erasing over bad partitions (ALL DATA will be lost!). The other solution is to not allow DrakX to modify the partition table. (the error is partition must NOT start at sector 0. ) Do you agree to lose all the partitions? After selecting No in diskdrake, it displays the partitions ok. That's a Mageia 7.1 iso with a persistent partition. Mageia 8 iso, also with a persistent partition does not display in diskdrake at all. This running diskdrake on a Mageia 7 install. [root@x3 /s3/m7.1]# blkid|grep -e sdg -e sdh|sort -V /dev/sdg1: UUID="2020-12-05-11-07-35-00" LABEL="Mageia-8-b2-Live-Plasma-x86_64" TYPE="iso9660" PTTYPE="dos" /dev/sdg2: SEC_TYPE="msdos" LABEL_FATBOOT="MGALIVE-ESP" LABEL="MGALIVE-ESP" UUID="81BA-4920" TYPE="vfat" /dev/sdg3: LABEL="mgalive-persist" UUID="101b34f6-4b0b-49e4-b0a5-0ca1c3892ed2" TYPE="ext4" /dev/sdh1: UUID="2019-07-12-19-27-04-00" LABEL="Mageia-7.1-Live-Plasma-x86_64" TYPE="iso9660" PTTYPE="dos" /dev/sdh2: SEC_TYPE="msdos" LABEL_FATBOOT="MGALIVE-ESP" LABEL="MGALIVE-ESP" UUID="C45A-10F2" TYPE="vfat" /dev/sdh3: LABEL="mgalive-persist" UUID="367b652f-78fc-486f-8130-d91cc2b4c13a" TYPE="ext4" [root@x3 /s3/m7.1]# sfdisk -luS /dev/sdg Disk /dev/sdg: 114.6 GiB, 123060879360 bytes, 240353280 sectors Disk model: Ultra USB 3.0 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000 Device Boot Start End Sectors Size Id Type /dev/sdg1 * 0 7067663 7067664 3.4G 0 Empty /dev/sdg2 7067664 7075855 8192 4M ef EFI (FAT-12/16/32) /dev/sdg3 7077888 240353279 233275392 111.2G 83 Linux [root@x3 /s3/m7.1]# sfdisk -luS /dev/sdh Disk /dev/sdh: 114.6 GiB, 123060879360 bytes, 240353280 sectors Disk model: Ultra USB 3.0 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000 Device Boot Start End Sectors Size Id Type /dev/sdh1 * 0 5912403 5912404 2.8G 0 Empty /dev/sdh2 5912404 5920595 8192 4M ef EFI (FAT-12/16/32) /dev/sdh3 5920768 240353279 234432512 111.8G 83 Linux See bug 5036 for some history on this type of problem.
CC: (none) => davidwhodgins
So this is a duplicate of 25224 that has been fixed in Cauldron for Mageia 8. (In reply to Morgan Leijström from comment #2) > OK > > Ah seems I missed tracking that bug. > > Any chance of updating mga7 diskdrake? I wonder if this can be done, or too late? Meanwhile assigning to Mageia Tools Team. Recent commiters on this already CC'd. Feel free to set as WONTFIX if this can't be done for M7.
CC: (none) => ouaurelienAssignee: bugsquad => mageiatools
It isn't a bug in diskdrake. It's a bug in the tool used to create the iso images. The partition table in the iso images master boot record includes it's first entry indicating a partition that starts with the sector that contains the master boot record, not the actual start of a partition. The only time a bios should look inside a partition for an extended partition table is if the partition type has one of the values 05h, 06h, or 0Fh. https://en.wikipedia.org/wiki/Partition_type As per bug 5036 some faulty bios firmware will look for a logical partition chain inside of any partition type. That means that during boot those systems will read the partition table from the usb drive, find the first partition table in sector 0, pointing to a partition starting in sector zero, and then try to follow the chain by re-reading sector 0. This causes a hard loop while reading the partition table meaning the computer can not boot while a usb stick with such a partition table is plugged in. While it only causes problems on systems with faulty firmware, the actual error is in the iso creation.
Summary: Diskdrake do not see Mageia 8 Live => Diskdrake do not see 64 bit or custom Mageia Live
It isn't a bug in draklive2, it is a deliberate decision to keep the same partition layout as had been used previously, as that had been proven in practice. The iso9660 filesystem starts at sector 0. The DOS partition table contains a protective partition to cover the iso9660 filesystem. On the official 32-bit ISOs the protective partition starts at sector 1, not sector 0, to avoid the problem with faulty BIOSs. That has the disadvantage that the correct filesystem magic is not seen at the start of the partition, so the iso9660 filesystem is not detected and won't be seen by file managers and other such tools. There have been several complaints about this. Occasionally, depending on the contents of the iso9660 filesystem, you may see false detection of a completely different filesystem (which will almost certainly be reported as being corrupt). On the official 64-bit ISOs the protective partition starts at sector 0, so is susceptible to the problem with faulty BIOSs. However, we have had no bug reports about that, so it would seem that problem is confined to old 32-bit hardware. The advantage is the iso9660 filesystem is now visible, and you can examine its contents in your favourite file manager. I believe the original reason for the 64-bit ISOs being different was that the old live ISO creation tool (draklive) used isohybrid to convert the ISO file to a hybrid ISO. To make the ISO UEFI-bootable, the -u option was passed to isohybrid. If you use the -u option, isohybrid insists on starting the protective partition at sector 0. draklive2 uses xorrisofs to add the hybrid disk structure, which is why I can make the 32-bit ISOs UEFI bootable whilst still having a protective partition that starts at sector 1. I don't know why Dave is getting the "I cannot read the partition table of device sdh, it's too corrupted for me" message from diskdrake. I've never seen that (when examing the Live ISOs, that is). In my experience it never displays the device. That's because in Mageia 7, diskdrake detects the iso9660 filesystem and decides it's a CD/DVD and can't be modified. That's what I've changed for Mageia 8. As I view that as an enhancement, not a bug, and as we are all busy trying to get Mageia 8 released, I don't propose to backport that to Mageia 7. Morgan, you can change the starting sector on your custom ISOs as described in https://wiki.mageia.org/en/Draklive2#iso_part_start_.28optional.29
Resolution: (none) => WONTFIXStatus: NEW => RESOLVED
Thank you for the solid explanation! This is more than I need to use, but will add a link on wifi to this bug :) Maybe this info could also be linked from draklive 2 wiki page?