mount_chroot.sh and umount_chroot.sh Working Again!

[rockedge]

@wiak Sometime ago I mentioned that there was an error using umount_chroot-new.sh or umount_chroot.sh to unmount a firstrib_rootfs directory involving AUFS.

Well I found out using the huge kernel 6.9.1 I compiled for Puppy Linux has "fixed" the problem!

No more error unmounting a firstrib_rootfs after using mount_chroot.sh to access and run the system when using this newer kernel in the host system

[geo_c]

@wiak Sometime ago I mentioned that there was an error using umount_chroot-new.sh or umount_chroot.sh to unmount a firstrib_rootfs directory involving AUFS..

Well I found out using the huge kernel 6.9.1 I compiled for Puppy Linux has "fixed" the problem!

No more error unmounting a firstrib_rootfs after using mount_chroot.sh to access and run the system when using this newer kernel in the host system

I downloaded sr13 with the 6.9.1 kernel, and as much as I hate to do it, I think it's time for an Airedale Studio rebuild. I'm still using my sr8 build.

In this time I've gotten a lot better with how to use an 08layer combined with a multi-install. using the 08layer I can easily manage what I'm adding to a PFI by making changes in the 08layer on the other compressed instances and then grabbing those changes from their 08layer and incorporating into the PFI for a resquash.

[wiak]

In this time I've gotten a lot better with how to use an 08layer combined with a multi-install. using the 08layer I can easily manage what I'm adding to a PFI by making changes in the 08layer on the other compressed instances and then grabbing those changes from their 08layer and incorporating into the PFI for a resquash.

I must thank you geo_c. Your active use of these features of KL/FR system and your enthusiastic reports on their important utility is extremely valued and more especially at this time when I am myself limited by situation in terms of what more I can currently say about these facilities. Whilst they are not difficult to use, they are unique and thus unfamiliar in concept to most distro users, so I am happy that you continue to shine a light on their practical usage and potential. Eventually we should aim to make their setup a matter of point and click selection. Ideas for utilities that take advantage of the many KL/FR-related special features are also very welcome. Then we just need more available devs and dev time to implement these. The future for all of this is exciting with much to do, but much to enjoy and benefit from. Thanks again.

[geo_c]

In this time I've gotten a lot better with how to use an 08layer combined with a multi-install. using the 08layer I can easily manage what I'm adding to a PFI by making changes in the 08layer on the other compressed instances and then grabbing those changes from their 08layer and incorporating into the PFI for a resquash.

I must thank you geo_c. Your active use of these features of KL/FR system and your enthusiastic reports on their important utility is extremely valued and more especially at this time when I am myself limited by situation in terms of what more I can currently say about these facilities. Whilst they are not difficult to use, they are unique and thus unfamiliar in concept to most distro users, so I am happy that you continue to shine a light on their practical usage and potential. Eventually we should aim to make their setup a matter of point and click selection. Ideas for utilities that take advantage of the many KL/FR-related special features are also very welcome. Then we just need more available devs and dev time to implement these. The future for all of this is exciting with much to do, but much to enjoy and benefit from. Thanks again.

Your welcome @wiak . I can't tell you how great these KLs with multi-instances have been to use. I've been able to thoroughly customize and build an operating environment tailored to my particular uses very easily. And they have a long shelf life. I'm planning on using SR-13, just because I like how @rockedge keeps fine tuning it and building new kernels and such. But I'm still using SR-2 on some machines and it's basically as up to date as the newer ones in terms of system updates. Doesn't have pipewire though.

I've been mulling over an idea about the KL multi-instance technique, and without going into too many details here, the basic idea is to make the default install a multi-instance where the user has a choice like in a puppy to boot into either w_changes=RAM2, or an immediate write upper_changes (whatever the proper term for that is.)

So in other words, a multi-instance install being the default, with at least two instances, one being w_changes=RAM2 and the other being normal write as changed.

My thought is that once a user realizes they have two or more installs, they can use those instances to do things like delete upper_changes in one of them entirely and boot pristine again. Or a variation of @fredx181's backup/restoresys script could rename the upper_changes in one of the instances so a pristine boot could be done in that instance at any given time.

I haven't thought it through completely, but it seems like a path to making the system more malleable for the average user. If I take say a "Joe User" and he has just one instance, and he experiments and mucks up his upper_changes, well he has to boot another OS to delete those and start over, and that is simply unecessary when he could have at least one more instance to bounce back and forth and manipulate his installs as needed.

Of course communicating that whole structure would be important and take some documentation, but I could probably help with that.

[wiak]

...or an immediate write upper_changes (whatever the proper term for that is.)

Yes, a bit difficult to document that small detail since default (no argument of type w_changes=) is direct writes to the persistent save. However, for consistency in terms of always allowing for argument of the type w_changes= I included the following two as equivalent for indicating direct writes:

w_changes=media
w_changes="" # where empty double quotes are used
Come to think of it, simply w_changes= with nothing after the equals sign probably has same effect, but I haven't tried that...

I've been mulling over an idea about the KL multi-instance technique, and without going into too many details here, the basic idea is to make the default install a multi-instance where the user has a choice like in a puppy to boot into either w_changes=RAM2, or an immediate write upper_changes (whatever the proper term for that is.)

So in other words, a multi-instance install being the default, with at least two instances

Something like that also crossed my mind when first trying out multi-instance scheme. However, I don't want to force user into any unexpected/somewhat-unique arrangement so doubt I'd make multi-instance the default. On the other hand, it is so useful really (once understood and someone has tried it and become familiar with how powerful it is) that there certainly is a strong argument to not go with the flow but to indeed make some variant of it the "default" install type. I'd certainly recommend getting in the habit of not using single distro install with KL, but instead make it a multi because really there is almost no overhead involved; well, a couple of thousand bytes only for such versatility! - what is to lose?!!! and, as your example of use illustrates, a lot to gain. So still thinking about best way to advance usage of multi-lib, which is surely to be recommended since can be then configured in so many (multiple) individual bootable distro ways (including parts that can be held in common between each multi-instance).

[rockedge]

Come to think of it, simply w_changes= with nothing after the equals sign probably has same effect, but I haven't tried that...

It does work the same.