Possible solution for isodevice absent for installations based on iso-files on disk

[Martin-Laclaustra]

Please kindly have a look here https://github.com/linuxmint/ubiquity/issues/51#issuecomment-1344978596 at the possible solution of the issue that I raised during the previous LM 21 beta.

[NintendoManiac64]

I don't suppose simply using Ventoy, rather than a traditional ISO writer, would also work?

[Martin-Laclaustra]

I don't suppose simply using Ventoy, rather than a traditional ISO writer, would also work?

Sorry, despite related, this is not what the issue is about. The point is to use an ISO file, saved on a disk filesystem and boot it from the computer grub bootloader, without creating any installation media. It is possible to install LM if the file is in a different partition that the destination one. It WAS possible to install (in LM 20.3) even if the file was in the very same partition as the destination one. If this possibility depends on just 3 lines of code (see my link above, it is all explained there), I think it is worth getting it back.

[NintendoManiac64]

Oh, OH! That, not the "out of memory" ISO booting issue.

Interestingly, while I used to do the very "boot an ISO saved to the disk filesystem", I instead found having Ventoy installed onto my internal secondary disk (the same disk that houses TimeShift snapshots) to be a more elegant solution that also works between platforms and/or when using USB adapters (in particular, I find that the booting of a saved ISO tends to break if you try to clone the disk elsewhere and/or boot it onto a different PC despite the main installed OS being able to boot without issue).

[clefebvre]

I applied the will-fix-later to make sure we look at this during the next cycle. Sorry @Martin-Laclaustra this was overlooked. I can't promise a solution but I can help with the troubleshooting.

You asked where our commits were, they are here:

https://github.com/linuxmint/ubiquity/tree/20.04.15

[Martin-Laclaustra]

Thank you, Clem! I think the key solution will be https://github.com/linuxmint/ubiquity/issues/51#issuecomment-1344978596 I tried to test it. I succeeded with: 1) unpacking the ISO; 2) unpacking the casper/initramfs.lz; 3) locating the file 05mountpoints; and 4) patching it with the 4 lines close to the end. Unfortunately I had trouble when: 5) I recreated initramfs.lz (probably with a wrong method); and 6) repacked the ISO; and 7) the ISO would not start. If you hint me on how to do step 5, I can test it and, if successful, I will provide a recipe for the patch.

[clefebvre]

I can make an ISO which contains this script in /usr/share/initramfs-tools/scripts/casper-bottom/05mountpoints for the live session if you want, so you can test it. Let me know.

[clefebvre]

I don't think this would help though:

if grep -q '^[^ ]* /isodevice ' /proc/mounts; then
    mkdir -p /root/isodevice
    mount -n -o move /isodevice /root/isodevice
fi

There is no isodevice to start with.

The other thing I'm not clear about is why a fix is actually needed. The steps you're going through to perform this in-place upgrade/installation are already quite advanced, manual and require typing a set of commands. Why not just adapt this set to Ubuntu 22.04/Mint 21 with a few additional commands to get isodevice mounted?

[Martin-Laclaustra]

Sorry. I have been busy at my job.

I can make an ISO which contains this script in /usr/share/initramfs-tools/scripts/casper-bottom/05mountpoints for the live session if you want, so you can test it. Let me know.

That will not work. Those lines should be added at the end of 05mountpoints, just before log_end_msg. But then, once 05mountpoints is patched, it has to be inserted in the initramfs.lz. Therefore it is from your environment, once you have patched /usr/share/initramfs-tools/scripts/casper-bottom/05mountpoints, that a new initramfs.lz for the ISO should be created, with the parameters you use to create the ISO. (unless the original ubuntu initramfs.lz for the ISO is reused for the linux mint ISO without modification, then... it is a whole new task to perform). If you can create an ISO with the modified initramfs, the test is easy... the directory /isodevice will reappear in the running live ISO, and the mount will be listed with the command mount. (I could also test the later procedure that I mention in the other issue, of course).

There is no isodevice to start with.

True. There is no /isodevice directory in the running live ISO, but I really think that there is one in the previous boot step, when the initramfs environment is running: There, there is not only a /isodevice directory, but it serves as active mount point (see bellow - 1) for the block device that hosts the actual ISO file. When that step (initramfs) ends and the system chroots to the live ISO root (squashfs), the original root directory with the mount is lost, and the mount is left "dangling", locking the partition. That is the essence of those four lines, that have to run before the chroot... to pass on the mount to a directory that actually is in the final running environment of the squashfs.

(1 - The mount occurs on line if find_path "${iso_path}" /isodevice rw; then of casper/scripts/casper-premount/20iso_scan. There, the function find_path in casper/scripts/casper-helpers creates the directory and mounts the device)

The reason for all this: If this is solved, with just a very few additional lines here and there (that I will be able to provide), linux mint could offer a full (clean) reinstall without having to burn the ISO in a DVD or an USB. But that would be for the next release, if you like the system when I show it to you.

[Martin-Laclaustra]

I forgot to thank you for your kindness and attention. Your generosity has been great, in creating and providing Linux Mint, which is a project in which I believe.