Can I create a custom live ISO with all persist options defined? [Solved]

[a_freed_man]

* the tricky part is now to create such images...

Noted. Appreciate your help.

I also saw those image names using strings command on that file. I'll be prepared that multiple attempts may be required to get it right.

Any insight on Q2?

[fehlix]

* the tricky part is now to create such images...

Noted. Appreciate your help.

I also saw those image names using strings command on that file. I'll be prepared that multiple attempts may be required to get it right.

Any insight on Q2?

Not fully clear Q2, do you want to change the list of displayed sizes or change the preset default size only,
I guess both of those are within the live-scripts somewhere, not sure whether those are config-items.
I'm sure there will be some constrains checked, e.g when available RAM is small it may not allow big rootfs to create,
as dynamic-persist would load to RAM and would fail if rootfs is oversized.

[a_freed_man]

Not fully clear Q2, do you want to change the list of displayed sizes or change the preset default size only,
I guess both of those are within the live-scripts somewhere, not sure whether those are config-items.
I'm sure there will be some constrains checked, e.g when available RAM is small it may not allow big rootfs to create,
as dynamic-persist would load to RAM and would fail if rootfs is oversized.

Mainly I would like to avoid 1st time users having to answer questions, so no it's not about changing the list of choices but rather setting the size of the root+home fs.

Since I set the default as p_static_root there is no concern for growing fs beyond RAM, well, minimal concern.

People can override the default currently, at least until I understand the boot code well enough to force p_static_root.

I'm also curious about the file size limit, whether the max value is dynamic and what criteria is a factor in setting it.

Another item I will investigate is if I can reduce the size of the bootable partition to less than 1024 "cylinders" and link to another partition to use the remainder of the space. As it is now the Live-usb-storage has full access to the remainder of the USB drive and I am using that, but according to the mx-live-usb-maker drives > 128GB limit BIOS compatibility for booting.

I know from 1st hand experience in the Windows 7 era that there are many pitfalls in booting op systems from removable media. Those BIOSs are still around, but things have improved since then.

BTW, I got all 3 of the boot menu backgrounds updated thanks to your help. I used krita to write the files and my ancient old single core, 1GB RAM Turion CPU laptop boots it fine. Slow as molasses but it boots.

[fehlix]

Not fully clear Q2, do you want to change the list of displayed sizes or change the preset default size only,
I guess both of those are within the live-scripts somewhere, not sure whether those are config-items.
I'm sure there will be some constrains checked, e.g when available RAM is small it may not allow big rootfs to create,
as dynamic-persist would load to RAM and would fail if rootfs is oversized.

Mainly I would like to avoid 1st time users having to answer questions, so no it's not about changing the list of choices but rather setting the size of the root+home fs.

Since I set the default as p_static_root there is no concern for growing fs beyond RAM, well, minimal concern.

People can override the default currently, at least until I understand the boot code well enough to force p_static_root.

Ah ok, so you want to get it automatically done without asking the user.
So perhaps this:
Combine p_static_root with persist=auto

Code: Select all

p_static_root persist=auto

which is equivalent to

Code: Select all

persist=auto,root!,static

BTW, I got all 3 of the boot menu backgrounds updated thanks to your help. I used krita to write the files ...

Thanks, good to know.

[a_freed_man]

I am booted from a Live USB of dolphin-oracles systemd image, and this image has the customized boot background images I created.

I made some changes to various files in a user's home folder and then took a snapshot. When I use mx-live-usb-maker the image does NOT boot with the customized boot background, so their is apparently more than 1 place those are saved. I'm pretty sure I only put the updated backgrounds in the /lib/iso-template.tar.gz file. I thought that once I created an image that booted with the customized backgrounds they would be propagated to all subsequent images produced from that live image.

Q1 - Since the source live USB has those backgrounds, what must I copy and to where to make them persist for all subsequent images?
----
I am still somewhat uncertain of the correct sequence of tools to use to iterate builds. I'm puzzled by the remaster-cc tool, and why it asks to rebuild the rootfs when the tool starts AND when it's finished.

Q2 - Isn't lunuxfs the read-only squashfs that remaster-cc rebuilds, and rootfs is where changes accumulate? Why then ask to rebuild rootfs on entry, wouldn't that obviate the need to remaster?

The double ask about rootfs on entry & exit also confuses me, why would one want to keep accumulating changes by NOT rebuilding rootfs after changes in it were added to linuxfs?
---

This last iteration I did all my tweaking then I used the snapshot tool to produce an ISO which I used as input to live-usb-maker.

Q3 - Is it necessary or would it be better to always run remaster-cc after making any changes, then snapshot, then live-usb-maker? Or, after remaster is there any reason to run snapshot (aside from wanting a single ISO to encapsulate those specific changes) and instead just jump to live-usb-maker and select "clone live running system"?

[fehlix]

I am booted from a Live USB of dolphin-oracles systemd image, and this image has the customized boot background images I created.

I made some changes to various files in a user's home folder and then took a snapshot. When I use mx-live-usb-maker the image does NOT boot with the customized boot background, so their is apparently more than 1 place those are saved. I'm pretty sure I only put the updated backgrounds in the /lib/iso-template.tar.gz file. I thought that once I created an image that booted with the customized backgrounds they would be propagated to all subsequent images produced from that live image.

Q1 - Since the source live USB has those backgrounds, what must I copy and to where to make them persist for all subsequent images?

Adjust iso-template before running the snapshot.
e.g keep the iso-template as a copy, even if iso-template will not often be updated,
better have it as a copy, e.g we will have probably made some updates with mx-iso-template recently.
And I'm sure some updates will follow later or sooner.
Or better inject you changes with script into the avialable iso-template.

I am still somewhat uncertain of the correct sequence of tools to use to iterate builds. I'm puzzled by the remaster-cc tool, and why it asks to rebuild the rootfs when the tool starts AND when it's finished.

The "main" idea of remaster is to squeeze the persistente changes from rootfs and old linuxfs into a new linuxfs ,
and by this old rootfs would not be needed after next boot.
Now, remaster works also without any rootfs, and only squeezes currently running changes. In most
cases user might want do boot with the same persistence option they used and probably have saved.
So they don't get asked at boot up to create a new rootfs, needed for persistence.

Q2 - Isn't lunuxfs the read-only squashfs that remaster-cc rebuilds, and rootfs is where changes accumulate? Why then ask to rebuild rootfs on entry, wouldn't that obviate the need to remaster?

Without rootfs it wont be able to boot persistent. But you get asked, b/c if you really don't want next boot
with persistent, you don't need a rootfs.

The double ask about rootfs on entry & exit also confuses me, why would one want to keep accumulating changes by NOT rebuilding rootfs after changes in it were added to linuxfs?

I'm not fully understand. I think at start they ask whether you want have changes from /home stored with linuxfs?
That's in case you really want to boot from a "fully" personalized ISO/linuxfs, with all changes including home.

---

This last iteration I did all my tweaking then I used the snapshot tool to produce an ISO which I used as input to live-usb-maker.

Q3 - Is it necessary or would it be better to always run remaster-cc after making any changes, then snapshot, then live-usb-maker? Or, after remaster is there any reason to run snapshot (aside from wanting a single ISO to encapsulate those specific changes) and instead just jump to live-usb-maker and select "clone live running system"?

Hmme .. ok: The snapshot tool would create a new linuxfs based an the running system. It does not care whether
the system is a live system or an installed one. It takes what is visible within the filesystem. On live that's an overlayed filesystem as combination of rootfs over linuxfs + a mounted /homefs (if exists).
So making a remaster before a snapshot, would not change what snapshot tools is seeing to take the snapshot.
Hope having not confused to much...

[a_freed_man]

e.g keep the iso-template as a copy...

Yes, I did save the version I updated.

Now, remaster works also without any rootfs, and only squeezes currently running changes. In most
cases user might want do boot with the same persistence option they used and probably have saved.
So they don't get asked at boot up to create a new rootfs, needed for persistence.

Eliminating questions for less technically saavy users is a great benefit!

Without rootfs it wont be able to boot persistent. But you get asked, b/c if you really don't want next boot
with persistent, you don't need a rootfs.

Ok, now I see the logic in that, however I'm not sure I understand it given your reply in previous question about "remaster doesn't need rootfs anymore". That implies only the changes from the current session are remastered, whereas with the rootfs persistence they can accumulate.

i.e. - The double ask about rootfs on entry & exit...
I'm not fully understand. I think at start they ask whether you want have changes from /home stored with linuxfs?
That's in case you really want to boot from a "fully" personalized ISO/linuxfs, with all changes including home.

No, the reference to storage in home was separate from rootfs. I was puzzled, store what in /home? I think
that question is only asked under a specific condition or option chosen, I don't recall now.
But the "create a new rootfs" is always asked on startup. I thought it may mean, "discard the changes in current rootfs?" !

Hmme .. ok: The snapshot tool would create a new linuxfs based an the running system. It does not care whether
the system is a live system or an installed one. It takes what is visible within the filesystem. On live that's an overlayed filesystem as combination of rootfs over linuxfs + a mounted /homefs (if exists).
So making a remaster before a snapshot, would not change what snapshot tools is seeing to take the snapshot.
Hope having not confused to much...

I discovered the reason the boot background didn't change was b/c the iso-template used was the one in /boot-dev/linux, not /lib.
Remastering fixed that (I made sure /lib/iso-template/iso-template.tar.gz was the one with my backgrounds). And yes, I did save
the version. I updated.

[a_freed_man]

I was hoping to release my respin today, but ran into a recurring problem I thought was solved.
I appears to be an insidious network problem and is intermittent. I thought it only affects WiFi, but the same testing on ethernet today showed it is also affected but far less noticeably. For ethernet what should take ~ 300ms occasionally takes 2 -3 seconds, but occurs less frequently & never freezes totally. I just now discovered it only occurs in a Live system when booted from a USB-3 SSD drive. I've used different SSDs & enclosures, which may affect the severity of the issue and how noticeable may be.

This problem has popped up in the last month as I tested. The last time I dismissed it as related to the servers that hammer the net when it is first activated. I actually created a 5 minute video showing the symptom which seems to kill arp and disrupt networking. I suspect it is rather a high priority process related to Live persistence. There is no such issue after that same code is installed from the Live USB SSD onto the system's internal SSD drive.

[fehlix]

But the "create a new rootfs" is always asked on startup. I thought it may mean, "discard the changes in current rootfs?" !

IF you mean with "startup", after booting the just remastered LiveUSB, than I guess this question about creating a new rootfs relates to the live boot option used. Any root-persistence related boot option would trigger to find rootfs and if not found would ask to create a new "empty" rootfs. After remasterering the old rootfs cannot be used any more for persistence, b/c the content of the old rootfs was already squashed into linuxfs.

[a_freed_man]

But the "create a new rootfs" is always asked on startup. I thought it may mean, "discard the changes in current rootfs?" !

IF you mean with "startup", after booting the just remastered LiveUSB, than I guess this question about creating a new rootfs relates to the live boot option used. Any root-persistence related boot option would trigger to find rootfs and if not found would ask to create a new "empty" rootfs. After remasterering the old rootfs cannot be used any more for persistence, b/c the content of the old rootfs was already squashed into linuxfs.

Poor choice of words on my part. I meant when I start the remaster program. I don't recall precisely when, definitely after authenticating root password, and probably right when I click the remaster button (lower left of group of 4 buttons) and definitely before it starts the remaster process.

As I mentioned in my last post, I am very puzzled by the problems that disrupt WiFi networking. Very odd that doesn't impact wired networking as much, and no such disruptions occur on an installed system. Care to hazard a guess about that?