Re: Writable partition for D-I ISO images
A followup to my post from December
It's possible to access the data partition when booting a real CD
using mount with an offset.
offset=$(fdisk -l /dev/sr0 | awk '/p3/ { print $2 * 512 }')
mount -ooffset=$offset /dev/sr0 /data
But the partition is read-only.
>> On Tue, 19 Dec 2023 13:15:53 +0100, Philip Hands said:
> On Tue, 19 Dec 2023 15:58:39 +0100, Thomas Lange said:
>> BTW if one did that, would it still be possible to read the filesystem
>> if one were to burn it to a physical CD rather than write it to a USB
>> stick?
> Nope. A quick test with qemu showed that booting the ISO as CD does
> not show the additional file system.
>> (just wondering -- don't really see much need to do that these
>> days) -- I guess it should be, even if some loop mount with offset was
>> required to make it work.
> Yes, I also guess some offset would help. But I also think that booting
> a CD not that important.
--
regards Thomas
Re: Writable partition for D-I ISO images
Hi! On 2023-12-20 08:47, Roland Clobus wrote: > A few months ago another approach was presented on the live-build project: > for computers that are able to boot with EFI (secure or not), preparing a > live USB-stick (based on the ISO file) is nearly trivial [1]. It is called > FST (File System Transposition) [2]. > > It requires a FAT32 formatted USB stick on which the whole (including the > hidden .disk folder) content of the ISO file is copied. There is no need for > magic boot sectors, update-grub or similar. (On Windows the tool Rufus can > do all this for you). > Since the files are now on a regular FAT32 partition, they can be modified > as required. Without knowing that the method had such a cool name, a few weeks back I documented it here: https://wiki.debian.org/DebianInstaller/WritableUSBStick ema
Re: Writable partition for D-I ISO images
Hello Thomas, lists, First: I think it is a good idea to provide such mechanism out-of-the-box A few months ago another approach was presented on the live-build project: for computers that are able to boot with EFI (secure or not), preparing a live USB-stick (based on the ISO file) is nearly trivial [1]. It is called FST (File System Transposition) [2]. It requires a FAT32 formatted USB stick on which the whole (including the hidden .disk folder) content of the ISO file is copied. There is no need for magic boot sectors, update-grub or similar. (On Windows the tool Rufus can do all this for you). Since the files are now on a regular FAT32 partition, they can be modified as required. As far as I understood, the installer images already support this, and for the live images this is on the TODO list [3]. And yet another approach which was shown to me on the openSUSE conference 2022: with kiwi it is possible to build live images for Debian as well, and IIRC one of boot steps involves filling the remainder of the USB-stick with a writeable partition. I can look up further details, if you are interested. With kind regards, Roland Clobus [1] https://salsa.debian.org/live-team/live-build/-/merge_requests/323 [2] https://lists.gnu.org/archive/html/grub-devel/2022-06/msg00024.html [3] https://wiki.debian.org/DebianLive/TODO OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Writable partition for D-I ISO images
> On Tue, 19 Dec 2023 13:15:53 +0100, Philip Hands said: > This makes me think that we may be able to publish an image with a > filesystem already appended to it, so that a blend could then create > such a thing including a preseed file that configures their preferred > selection of tasks. > Is that possible with your approach? Hi Phil yes, after calling mk-data-partition an empty filesystem of a certain size (specifiy with -s) is available in the ISO. But the blends should take the original Deian ISO (without this file system) and they should call mk-data-partition and add their content, because they know which size it needs. > BTW if one did that, would it still be possible to read the filesystem > if one were to burn it to a physical CD rather than write it to a USB > stick? Nope. A quick test with qemu showed that booting the ISO as CD does not show the additional file system. > (just wondering -- don't really see much need to do that these > days) -- I guess it should be, even if some loop mount with offset was > required to make it work. Yes, I also guess some offset would help. But I also think that booting a CD not that important. > Another advantage of having a pre-existing FS appended is that we could > have examples in place so that people could apply common tweaks by > simply un-commenting a line in the example preseed.cfg, but it introduces > the complication of resizing things (or deleting & recreating), if the > default size is too small for one's needs. The scenario should not invole editing lines in a config file. This additional file system could help blends or companies to add their software to the Debian installer and maybe to easily add a selection menu. A they will now which size is needed. -- regards Thomas
Re: Writable partition for D-I ISO images
Hi Tomas, [ For those that have not already seen it, this is in reply to: https://blog.fai-project.org/posts/extending-iso-images/ ] I've long thought that it would be great to be able to easily tweak our ISO images, and I think this idea may well provide the means. This could be particularly useful for enabling Debian Blends to present users with a task list that would be tuned for their blend. This makes me think that we may be able to publish an image with a filesystem already appended to it, so that a blend could then create such a thing including a preseed file that configures their preferred selection of tasks. Is that possible with your approach? BTW if one did that, would it still be possible to read the filesystem if one were to burn it to a physical CD rather than write it to a USB stick? (just wondering -- don't really see much need to do that these days) -- I guess it should be, even if some loop mount with offset was required to make it work. Another advantage of having a pre-existing FS appended is that we could have examples in place so that people could apply common tweaks by simply un-commenting a line in the example preseed.cfg, but it introduces the complication of resizing things (or deleting & recreating), if the default size is too small for one's needs. Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
