KLV-Airedale-beta+ Released, Ready for Download

[rockedge]

KLV-Airedale-beta20
Kennel Linux Void Airedale Beta 20 556 MB download size ->
KLV-Airedale-beta20
SHA1-MD5.txt

save2flash has been expanded to handle persistence on FAT32 and NTFS partitions.
The mksplash GUI utility to create splash notification banners.

has the latest FirstRib skeleton initrd v6.0-rc1 supplying the initrd.gz
and is currently equipped with the kernel 5.16.14-KLV (no AUFS5 support).
00modules-5.16.14-KLV-b19.sfs has the file structure -> /usr/lib/modules

The latest initrd.gz brings vFat and NTFS formatted partition support to KLV, allowing persistence on NTFS/vFat systems as well as the usual /ext2/ext3/ext4 /swap support.

• Beta20 has wiak's FirstRib skeleton initrd v6.0-rc1 and w_init_6.0-rc1

• the kernel's 00Module SFS file structure has been modified by moving /lib/modules to /usr/lib/modules

• included htop

• created a symlink /root/spot with the target /home/spot

• Auto login cleaned up.

• includes also the logout logic provided by fredx181 gives true mulit-user support.

• replaced loop.cfg to the most recent modifications.

• updated (latest 27/3/2022)save2flash to compliment initrd_v504-rc2.gz now initrd_v505-rc1.gz

• kernel 5.16.14-KLV (overlayfs built in and no aufs5) is used.

• added gtkhash

Plus the other important improvements contributed by the KLV team.

Added @fredx181's save2flash utility that can be used when KLV is started in RAM2 mode to perform session saves on demand for persistence.
This is similar to PUPMODE13 in Puppy Linux.

fredx181's swap partition enable script includes the latest revisions and also added are the packages

• mime-add-1.0_0.noarch.xbps

• edit-sfs-1.0_0.noarch.xbps

KLV-Airedale-beta4 is able to load squash SFS packages on the fly or during the boot sequence.
Squash files and ISO images can be opened from the file manager and the read the contents.

• can run with rootfs, 01fimware and 00module SFS files as uncompressed directories.

• Also able to load compressed and/or decompressed directories,
  once a 2 digit prefix is added to the file name.

• It is possible to mix using compressed squash files and uncompressed directories.

Also can be downloaded from https://rockedge.org/kernels in ISO->Kennel_Linux->Airedale

[mikewalsh]

@rockedge :-

You may have a problem with Beta-1, Erik. I downloaded and swapped the main SFS over, and straightaway had to revert back to alpha 13. Why?

No cursor control, mate. Every single one of my mice - all 5 of them! - are completely non-functional. That cursor will not move a millimetre for me.....and that includes removing each of the dongles in turn, waiting 30 seconds, then re-inserting to let them create a new device inode.....

No joy. Nada. Zip. Zilch. Non-functzione, my friend.....

Reverting to alpha 13, everything's behaving itself again.

???????

Mike.

[wiak]

@rockedge :-

You may have a problem with Beta-1, Erik. I downloaded and swapped the main SFS over, and straightaway had to revert back to alpha 13. Why?

No cursor control, mate. Every single one of my mice - all 5 of them! - are completely non-functional. That cursor will not move a millimetre for me.....and that includes removing each of the dongles in turn, waiting 30 seconds, then re-inserting to let them create a new device inode.....

No joy. Nada. Zip. Zilch. Non-functzione, my friend.....

Reverting to alpha 13, everything's behaving itself again.

???????

Mike.

Perhaps you started with old upper_changes folder still in place and something in there causing conflict? Pristine install probably best (i.e. no, or empty upper_changes directory). I haven't had a chance to try Beta1 yet, but will in an hour or two.

[fredx181]

@rockedge :-

You may have a problem with Beta-1, Erik. I downloaded and swapped the main SFS over, and straightaway had to revert back to alpha 13. Why?

No cursor control, mate. Every single one of my mice - all 5 of them! - are completely non-functional. That cursor will not move a millimetre for me.....and that includes removing each of the dongles in turn, waiting 30 seconds, then re-inserting to let them create a new device inode.....

No joy. Nada. Zip. Zilch. Non-functzione, my friend.....

Reverting to alpha 13, everything's behaving itself again.

???????

Mike.

Perhaps you started with old upper_changes folder still in place and something in there causing conflict? Pristine install probably best (i.e. no, or empty upper_changes directory). I haven't had a chance to try Beta1 yet, but will in an hour or two.

Just to report that everything works fine for me on a pristine Beta-1 install.
No idea what can be wrong at your end Mike, btw, AFAIK Beta-1 has no dramatic changes compared to alpha 13.

[bigpup]

These are the boot loader menu config files, that are in the boot directory, in the ISO.

Does anyone understand what each of these boot menu entries actually do?

This is from the grub.cfg

menuentry "KLV-Airedale-beta1 - changes RAM0 mode" {
linux /vmlinuz w_bootfrom=${iso_path} w_changes=RAM0 net.ifnames=0
initrd /initrd.gz
}

menuentry "KLV-Airedale-beta1 - changes RAM0 mode w_copy2ram" {
linux /vmlinuz w_bootfrom=${iso_path} w_changes=RAM0 net.ifnames=0 w_copy2ram
initrd /initrd.gz
}

menuentry "KLV-Airedale-beta1 - changes on media/BOOTISOS" {
linux /vmlinuz w_bootfrom=${iso_path} w_changes=LABEL=SG2DISOS=/BOOTISOS net.ifnames=0
initrd /initrd.gz
}

menuentry "KLV-Airedale-beta1 - LABEL bootfrom - changes on media/BOOTISOS" {
linux /vmlinuz w_bootfrom=LABEL=SG2DISOS=/BOOTISOS/KLV-Airedale-beta1.iso net.ifnames=0 w_changes=LABEL=SG2DISOS=/BOOTISOS
initrd /initrd.gz
}

menuentry "KLV-Airedale-beta1 - LABEL bootfrom - changes on media/BOOTISOS w_copy2ram" {
linux /vmlinuz w_bootfrom=LABEL=SG2DISOS=/BOOTISOS/KLV-Airedale-beta1.iso net.ifnames=0 w_changes=LABEL=SG2DISOS=/BOOTISOS w_copy2ram
initrd /initrd.gz
}

menuentry "KLV-Airedale-beta1 - changes via named partition (location unreliable)" {
linux /vmlinuz w_bootfrom=${iso_path} w_changes=/mnt/sdb2/WDL net.ifnames=0
initrd /initrd.gz
}

menuentry "KLV-Airedale-beta1 - changes via named partition (location unreliable) w_copy2ram" {
linux /vmlinuz w_bootfrom=${iso_path} w_changes=/mnt/sda2/WDL net.ifnames=0 w_copy2ram
initrd /initrd.gz
}

menuentry "KLV-Airedale-beta1 - LABEL bootfrom - changes RAM0 mode" {
linux /vmlinuz w_bootfrom=LABEL=SG2DISOS=/BOOTISOS/KLV-Airedale-beta1.iso net.ifnames=0 w_changes=RAM0
initrd /initrd.gz
}

menuentry "KLV-Airedale-beta1 - LABEL bootfrom - changes RAM0 mode w_copy2ram" {
linux /vmlinuz w_bootfrom=LABEL=SG2DISOS=/BOOTISOS/KLV-Airedale-beta1.iso net.ifnames=0 w_changes=RAM0 w_copy2ram
initrd /initrd.gz
}

menuentry "KLV-Airedale-beta1- LABEL bootfrom - changes RAM2 mode" {
linux /vmlinuz w_bootfrom=LABEL=SG2DISOS=/BOOTISOS/KLV-Airedale-beta1.iso net.ifnames=0 w_changes=LABEL=SG2DISOS=/BOOTISOS w_changes1=RAM2
initrd /initrd.gz
}

menuentry "KLV-Airedale-beta1 - LABEL bootfrom - changes RAM2 mode w_copy2ram" {
linux /vmlinuz w_bootfrom=LABEL=SG2DISOS=/BOOTISOS/KLV-Airedale-beta1.iso net.ifnames=0 w_changes=LABEL=SG2DISOS=/BOOTISOS w_changes1=RAM2 w_copy2ram
initrd /initrd.gz
}

menuentry "KLV-Airedale-beta1 - LABEL bootfrom - changes RAM1 mode" {
linux /vmlinuz w_bootfrom=LABEL=SG2DISOS=/BOOTISOS/KLV-Airedale-beta1.iso net.ifnames=0 w_changes=LABEL=SG2DISOS=/BOOTISOS w_changes1=RAM1
initrd /initrd.gz
}

menuentry "KLV-Airedale-beta1 - LABEL bootfrom - changes RAM1 mode w_copy2ram" {
linux /vmlinuz w_bootfrom=LABEL=SG2DISOS=/BOOTISOS/KLV-Airedale-beta1.iso net.ifnames=0 w_changes=LABEL=SG2DISOS=/BOOTISOS w_changes1=RAM1 w_copy2ram
initrd /initrd.gz

menu.lst

title KLV-Airedale-beta1 (RAM0)
kernel /vmlinuz w_bootfrom=/mnt/sr0 w_changes=RAM0 net.ifnames=0
initrd /initrd.gz

title KLV-Airedale-beta1 (LABEL, RAM0)
kernel /vmlinuz w_bootfrom=LABEL=KLV-Airedale=/ w_changes=RAM0 net.ifnames=0
initrd /initrd.gz

title KLV-Airedale-beta1 (LABEL, RAM2)
kernel /vmlinuz w_bootfrom=LABEL=KLV-Airedale=/ w_changes=RAM2 net.ifnames=0
initrd /initrd.gz

title KLV-Airedale-beta1
kernel /vmlinuz w_bootfrom=/mnt/sr0 w_changes=/mnt/sda1/WDL-live w_copy2ram net.ifnames=0
initrd /initrd.gz

title KLV-Airedale-beta1 (LABEL)
kernel /vmlinuz w_bootfrom=LABEL=KLV-Airedale=/ w_changes=/mnt/sda1/WDL-live net.ifnames=0
initrd /initrd.gz

title KLV-Airedale-beta1 (LABEL no copy2ram)
kernel /vmlinuz w_bootfrom=LABEL=KLV-Airedale=/ w_changes=/mnt/sda1/WDL-live net.ifnames=0
initrd /initrd.gz

The menu_phelp.lst is not much help.
Seems to have info about stuff not even used in any of these entries.
About stuff that is not even about KLV-Airedale and what is in it's ISO.

[wiak]

Posting from beta1 right now.

I tell you, you may have only made KLV-Airedale to push developments of Puppy, but I wouldn't knock this KLV, it is working great!

I may say, I'm just trying out that KDE Connect for connecting KLV-Airedale to my Android phone per member Barbara's recommendation (see: viewtopic.php?p=50176#p50176)

Code: Select all

xbps-install -Sy kdeconnect

Then once installed I started app from terminal with:

Code: Select all

kdeconnect-app

or from Applications->Internet menu

It's really brilliant app! File transfers from phone end up in /root/Downloads.

A wee bit big I suppose, but not ridiculous and it is pretty impressive - I've also tried it using the phone as a drawing tablet for the computer, and also as a remote control whilst playing youtube video in Firefox. Beware "Find my phone" if you have phone volume high!!! It found it okay...
-----------------

As for initial impressions of beta1, my only minor quibble thus far is that it annoys me to have to go into Firefox

about:preferences

Fonts and Colors -> Advanced

Allow pages to choose their own fonts, instead of your selections above

to untick that box and then get nice fonts (otherwise the Firefox fonts look rubbish)

Would be nice if you configured that in the build prior to making the iso.

Funnily enough I am glad you have that wee wd_mount utility available - I like to sometimes use that for quick manual mounts.

I note clicking on an sfs (or iso for that matter) doesn't auto open it up for reading. However, easy enough to associate sfs with Open with Other Application and select filemnt SFS (I notice you also have right click for it). I know how to configure such open as mime actions for pcmanfm, but not for Thunar, though I guess it is similar. But what you have is fine really so maybe not worth the bother.

Overall it is pretty nippy on my old 2008 core2duo 4GB RAM machine - flashy enough but not too flashy (I've been trying some very fancy big distros of late, but when too glossy and featurefull desktop frankly I get lost - I like simple but nice and KLV XFCE is pretty good). Give that KDE Connect a try for fun - it is really a bit too posh for me, but really nice once you work and quick to transfer files back and forth and more.

[geo_c]

@rockedge I just booted this beta version from an SG2D usb. This is really nice! XFCE looks great. So I'll be exploring it for awhile before I try it make it look like a PCXT!

[wiak]

These are the boot loader menu config files, that are in the boot directory, in the ISO.

Does anyone understand what each of these boot menu entries actually do?

This is from the grub.cfg

menuentry "KLV-Airedale-beta1 - changes RAM0 mode" {
linux /vmlinuz w_bootfrom=${iso_path} w_changes=RAM0 net.ifnames=0
initrd /initrd.gz
}

rockedge has his work cut out explaining all these entries. Even I can't remember now off the top of my head, but I blame Clarity - a lot of it is to do with booting from SG2D I think (maybe Ventoy too - I don't recall the details now but hope rockedge can). I think the w_bootfrom=${iso_path} is the trick needed to help SG2D find the iso (I should know... but... I don't have my cherrytree notepad open).

w_changes=RAM0 is a mode that simply uses pristine OS and an upper_changes held only in RAM (so generally not saved at end of any session).

w_copy2ram copies pretty much all the stuff in the bootfrom dir to RAM before usage. Truth is I hardly use that so would have to check details about the parameter again... my brain is going...

[mikewalsh]

Now then:-

Beta1 would not have my old 'upper_changes' in any way, shape or form. Oh, it fired up just fine, but that cursor stubbornly refused to move. So; didn't really want to, but I did as advised and re-built from scratch with a new 'upper_changes'.

So far, so good. And using largely 'portables', which link into the system a treat, certainly helps to speed things up!

I have reverted back to Fossapup's kernel, though. The default as supplied was creating annoying flickering across the entire screen every time the cursor so much as twitched. Swapped back to k5.4.53, which I've been using for long enough on this, and all is serene again. Funny, that.

Never mind. Onwards and upwards.....

Mike.

[fredx181]

Noticed that "pipe-viewer-gtk" (from author trizen: https://github.com/trizen/pipe-viewer) is in the Void repo, it's the follow-up of gtk-youtube-viewer.
I always liked gtk-youtube-viewer, but it's a real challenge to set it up on Puppy (as it has many Perl dependencies).

On KLV pipe-viewer-gtk installed ok, all perl dependencies included, but missing a suitable mediaplayer (best is mpv IMO), symbola font (required see: viewtopic.php?t=4488 ) and it doesn't show in the Menu.

For who is interested, here's xbps package "gtk-pipe-viewer-setup-0.1_8.noarch.xbps" ;
https://drive.google.com/uc?export=down ... WQHuKzdXYM
It has included the symbola font, a .desktop launcher and will install dependencies pipe-viewer-gtk and mpv, so this will set it all up.

[rockedge]

@mikewalsh I think the original /upper_changes might work with the beta1 rootfs.
Boot the system and try to get a terminal and use the command:

Code: Select all

xbps-install -Suy

If you need to drop to console use the keys CTRL-ALT-F2 and login as root (tty2). Then use xbps-install -Suy. After xbps is finished use exit and then CTRL-ALT-F1 to return to the desktop (tty1)

If this does not fix it let me know. It would be a good test.

I think the original /upper_changes had gone enough out of sync with the updated rootfs in beta1 that something broke. Or the kernel's firmware/modules didn't load correctly.

[geo_c]

I booted an iso using SG2D, and I've been testing the xbps package loader which installed a couple of my go to apps very nicely, but I have no clue how to create a persistent save folder, or install the system to any other drives. None of that seems to be in the menus anyway.

This system really does have my interest!

I was having some difficulty launching @mikewalsh 's portables though. I seemed to be able to run LibreWolf as a straight app image no problem.

[rockedge]

@geo_c As long as you do not boot using w_changes=RAM0 or w_changes=RAM2 on the kernel command line, the folder /upper_changes and /work will appear in the directory with the rootfs SFS file. This is done automatically and contains all of the session changes and serves as persistence.

Screenshot_2022-02-18_17-58-54.png (38.95 KiB) Viewed 2360 times

To move the frugal installed KLV to another location, create a target directory and copy all of the files and the /upper_changes and /work directories into the target folder. To start fresh remove the /upper_changes or just rename it to something like /no_upper_changes.

If you rename /upper_changes with a 2 digit number to start the name like this:/50upper_changes, a new /upper_changes will be created. If something breaks it would be possible to "roll back" by removing the current /upper_changes and rename /50upper_changes back to /upper_changes.

One can use upper_changes like this as they are made: /50upper_changes, /51upper_changes, /52upper_changes and a new current /upper_changes will be created. Those numbered /50upper_changes can be squashed and named like 50changes.sfs this file will be layered onto the system at startup.

[wiak]

So I get automatic save persistence (into folder upper_changes on my hard disk) when booting with grub menu.lst:

Code: Select all

title KLV-airedale64
  find --set-root uuid () f69e84fc-6a11-4025-a93b-516b1a12c87f
  kernel /klv/vmlinuz w_bootfrom=UUID=f69e84fc-6a11-4025-a93b-516b1a12c87f=/klv
  initrd /klv/initrd.gz

or if grub.cfg I use (albeit with your own system uuid of course):

Code: Select all

menuentry "KLV-airedale64" {
  insmod ext2
  search --no-floppy --fs-uuid --set  f69e84fc-6a11-4025-a93b-516b1a12c87f
  linux /klv/vmlinuz w_bootfrom=UUID=f69e84fc-6a11-4025-a93b-516b1a12c87f=/klv
  initrd /klv/initrd.gz
}

1. If I want to run in RAM without using that external upper_changes at all on next boot, I simply add the following w_changes 'mode' argument to the grub linux kernel line: w_changes=RAM0. All session saves then go only to RAM (into directory /mnt/layers/RAM/upper_changes) and are lost on shutdown.

2. If, on the other hand I want to use the contents of my saved hard disk upper_changes on a new boot, but not save anything new I do thereafter, I simply add this w_changes mode instead to grub kernel line;

w_changes=RAM2

What RAM2 mode does is to simply mount the external upper_changes (e.g. in my case at /mnt/sda2/klv/upper_changes) read-only as one of the filesystem overlay layers, but uses temporary save folder in RAM (at directory /mnt/layers/RAM/upper_changes) - that RAM upper_changes then gets lost at shutdown (unless you use a special rsync script to merge it back into the external upper_changes at shutdown (which would make it be like a PUPMODE13).

3. But, by default (as rockedge's immediately above post indicates), if no w_changes argument is used on the grub kernel line then save persistence to external upper_changes folder always happens so persistence should just work by default...

[mikewalsh]

@rockedge :-

@mikewalsh I think the original /upper_changes might work with the beta1 rootfs.
Boot the system and try to get a terminal and use the command:

Code: Select all

xbps-install -Suy

If you need to drop to console use the keys CTRL-ALT-F2 and login as root (tty2). Then use xbps-install -Suy. After xbps is finished use exit and then CTRL-ALT-F1 to return to the desktop (tty1)

If this does not fix it let me know. It would be a good test.

I think the original /upper_changes had gone enough out of sync with the updated rootfs in beta1 that something broke. Or the kernel's firmware/modules didn't load correctly.

Mm. Yah, might be worth a try, at that.

I took a backup copy of alpha13 in full working order immediately prior to upgrading to Beta1, so I've got that to one side. I can temporarily copy that back in beside beta1 on the old Dell's SSD - which I'm using for KLV on a SATA-USB3 adapter - throw a boot entry together for it, and have a play around with what you've suggested.

Leave it with me; I'll see if I can find time for this over the weekend. I've all but 'restored' the new KLV Beta to how alpha13 was (just a few tweaks left to do), so it'll be more a case of experimenting with the old copy......and seeing what does happen.

Mike.

[mikewalsh]

I booted an iso using SG2D, and I've been testing the xbps package loader which installed a couple of my go to apps very nicely, but I have no clue how to create a persistent save folder, or install the system to any other drives. None of that seems to be in the menus anyway.

This system really does have my interest!

I was having some difficulty launching @mikewalsh 's portables though. I seemed to be able to run LibreWolf as a straight app image no problem.

@geo_c :-

When you say 'having difficulties launching' my portables, are you referring to the fact that the LAUNCH script doesn't seem to do anything except open in Geany?

I had to refresh my own memory about this one earlier on today. See here:-

viewtopic.php?p=44439#p44439

Fred explains the 'permanent' workaround for this.....unless you want to go the long route of manually making each & every portable's 'LAUNCH' script executable as you set them up. I believe some folks use this as a means of being carefully selective as to what they actually allow to run.

Mike.

[mikeslr]

In response to the question about the significance of various boot-arguments, wiak's post above will likely provide the most commonly sought after information. Thanks, again, wiak.

There was a post with the following information:
To Blacklist realtek:
may need to append
kernel/linux line in syslinux/grub config thus:
modprobe.blacklist=snd_hda_codec_realtek

I think it was by ozsouth. Thought I copied the url, but apparently didn't. At any rate, that suggests --CAUTION I'M GUESSING-- that boot arguments with which we are already familiar can be employed on the kernel line [except, of course, those 'peculiarly puppy' arguments relating to SaveFile/Folders and Pupmodes for which wiaks instructions provide suitable substitutes].

After scouring the Forums, googling 'grub boot arguments' and similar, I stumbled on two other sources of information. One --except for the "WDL initrd "Cheat Sheet" thread-- I haven't yet completely read, How To viewforum.php?f=168

And the other --which, of course, was last place I looked: isn't that always the case -- was a file named "w_init" which was written to my "poppup64" folder by wiak's weedogit.sh script deploying Pop!_OS to that folder.

Since anyone using weedogit.sh will get that file; and those not using it to create 'frugal' operating system would have no interest in its contents, I won't waste forum space duplicating it except to note that it provides such information as:
...
# w_changes1 : =""|media or RAM0|RAM1|RAM2 or no_uc0 or no_uc1 (only for use when w_changes=path2dir
# w_altNN : alternative/additional location for NNfiles for mounting to the NN overlay layers
...
# w_copy2ram : is boolean 0(true) or 1(false) to copy all NNsfs, NNdirs, w_rdshN.plug to RAM
...
together with wiak's usualy thorough discussion of the matter.

In short, a crib-sheet and reference guide of usable boot-arguments.
Thanks, again wiak.

[geo_c]

@geo_c :-

When you say 'having difficulties launching' my portables, are you referring to the fact that the LAUNCH script doesn't seem to do anything except open in Geany?

I had to refresh my own memory about this one earlier on today. See here:-

viewtopic.php?p=44439#p44439
Mike.

Yes Mike, that's it exactly. I'll take a look at the permanent workaround. And btw I've been taking a look at your scripts and thinking I should try to make one of those myself. In particular for LibreWolf.

[rockedge]

@mikeslr we also have a w_init file in KLV-Airedale that can be referenced.
And yes we can use all of the familiar kernel command line options besides those special Puppy Linux specific options you've mentioned in your post above.

@bigpup I am getting around to straightening out the grub.cfg and menu.lst and soon will add to the help some of the WDL cheat sheet and the explanations from the w_init file comments.

The boot menu is a mess and is one of the last steps to be stabilized.

[mikeslr]

With Puppys, the 'OOTB' system does not include a SaveFile/Folder. Changes are preserved by creating, then writing to such SaveFile/Folder. If things get really screwed up, you can revert to the original/pristine OS by simply deleting the SaveFile/Folder. You can also backup a functional SaveFile/Folder by booting into a different OS or pfix=ram, then copying the SaveFile/Folder to where the copy wouldn't be available (to initrd?) on boot-up.

I noticed that within my KLV-Airedale-like's Folder [I'm actually running POP!OS] is a folder named "upper_changes". Am I correct in assuming that you've often referred to it by the acronym "uc"? I didn't notice whether it was present before I booted up. Was this created on first shut-down (or during first operation)?

But most importantly, if things get really screwed up, could the original pristine condition be recovered by (a) deleting that folder; or (b) leaving the folder, but deleting its contents? [The difference being that weedogit.sh created an empty folder required by the system which (1) won't itself create one and (2) enable saving changes without one].

Less significant: If my guess above as to the upper_changes folder is correct, can it be backed-up? Should booting w_changes=RAM0 be employed to do so?
And least significant: If someone actually know what (s)he was doing, can the contents of the upper_changes be manually edited?

[bigpup]

Yes "upper_changes" folder is the same as a Puppy Linux save folder.

If you do a normal first boot. It is automatically produced and used.
It is read/write at all times.
So, you do anything that is a change, addition, etc..., it is directly written to "upper_changes".

You can make a copy of it to use as a backup.

Should booting w_changes=RAM0 be employed to do so?

Maybe, the best way.
I seem to remember making a copy and it working, without having to do that.
But I was sure, that nothing was running, that needed to write to it, while the copy was being done.

Have not tried to directly do anything to the stuff in the "upper_changes" folder, but should be able to do it.
Remember this OS is still being developed.
So not everything possible has been tried, yet.

For the present state of development in KLV-Airedale.
When a new version is released.
It seems to be best to start over fresh, with a new "upper_changes" folder, produced under this newer KLV-Airedale version.

if things get really screwed up, could the original pristine condition be recovered by (a) deleting that folder; or (b) leaving the folder, but deleting its contents?

Yes, you could do one or the other.
I usually just delete it.
Reboot and a new fresh one is produced.

[geo_c]

I've been booting this from an iso copied onto my existing SG2D, which has several iso's loaded, and it boots just fine...

But I get two options from the boot menu, Both are w_changes, so I tried to use the edit function to take out the w_changes=RAM parameter, but I got kernel panic.

So I'm wondering,

Can I mount the iso and copy the system files to another drive and then run Grub4Dos on it? And boot that way?

[bigpup]

Try it and see.

We are developing and testing.
Not everything has been tried, yet.

[geo_c]

see below

[geo_c]

see below

[geo_c]

Try it and see.
We are developing and testing.
Not everything has been tried, yet.

@bigpup and @rockedge

Okay I got it to work! I mounted the iso, copied all the files to a usb drive, ran grub4dos, and edited the first entry to look like this:

Code: Select all

title KLV-Airedale-beta1 (RAM0)
           kernel /vmlinuz w_bootfrom=/mnt/sdb1 w_changes=media net.ifnames=0
           initrd /initrd.gz
            initrd /initrd.gz

The only thing I changed was adding [w_changes=media] in place of [w_changes=RAM0] and also bootfrom [sdb1] as opposed to [sr0]

And that gave me a boot off USB with the upper changes folder available on the boot partition.

[geo_c]

I installed a couple Gtk themes and they work great, I've got this looking like an old SWTP-6800 already!

[fredx181]

Hi @rockedge

Re: swapper.sh script: The auto-swap code works ok but the code for symlinking the boot partition directly to /mnt/home is not.
I think it's because 07KLV-airedale_rootfs.sfs contains already symlink /mnt/home .

2022-02-19-203234_576x136_scrot.png (13.14 KiB) Viewed 2037 times

/mnt/home is pointing to /mnt/sdb1 and somehow it doesn't get replaced with current mount partition correctly by the script (in my case it's sda7, which became a symlink inside /mnt/home, so became /mnt/home/sda7 which is wrong, /mnt/home should lead directly to contents of sda7 in my case)
This change in '/root/my-applications/bin/swapper.sh' should fix it:

Code: Select all

#### Create symlink /mnt/home ####
MNTHOME=$(mount | grep "/mnt/layers/merged/mnt" |  cut -d'/' -f3 | cut -d' ' -f1)
cd /mnt/
ln -sfn $MNTHOME home
#########################

Btw, maybe /mnt should be empty at initial boot (i.e. changes not containing anything in /mnt e.g. no leftover previous mounted folders), not sure though, @wiak what do you think ? (think of also the issue lately with filemnt, the previously mounted folder inside upper_changes/mnt).

[wiak]

Less significant: If my guess above as to the upper_changes folder is correct, can it be backed-up? Should booting w_changes=RAM0 be employed to do so?
And least significant: If someone actually know what (s)he was doing, can the contents of the upper_changes be manually edited?

If no w_changes parameter is specified on grub kernel line then on pristine boot the directory called upper_changes is automatically created in the KLV directory you are booting from. In that mode it is indeed read/write and used whilst the distro is running (so anything you do is immediately written into that upper_changes so will be there on next boot).

As bigpup says, I also have made backups of upper_changes even when system is running and have not noticed any problems - yet... However, I consider that risky since that upper_changes save persistence folder can be written to at any time (or that may be in process at any time since Linux often caches what it is doing temporarily in RAM). Your are quite correct therefore, that re-booting with grub kernel line option w_changes=RAM0 does not use the external upper_changes at all so completely safe to backup in that mode (that's what I would do). You can of course alternatively make any such backup whilst booted into any other distro. Having said that, I do indeed, sometimes just make a backup whilst actually using it and seemed to work ... (dubious though) and I always run command sync;sync just prior to making the copy to make sure any cache work is first flushed.

And yes, if someone knows what they are doing they can indeed manually edit the contents of that bootfrom directory upper_changes manually. I often do that, for example when booted into a different distro, to quickly edit a script or something I have in there so the change will be reflected on next boot of KLV (or to simply copy out some file I want that I know is in there - for example, a screenshot I know I made earlier). I also sometimes delete something I don't want to be there on next boot in same manual fashion. Of course you have to be careful, and especially if you want to delete (or artificially make) a 'whiteout' file. A whiteout file is just a special mknod char 0,0 file, whose presence in upper_changes causes that filename to appear deleted even if it is actually present in a lower layer. Most of the manual edits I do don't involve whiteouts though (but somtimes I manually experiment with these too...).

One other thing is that whilst that upper_changes directory is read/write when no w_changes grub line is being used (so save persistence immediately by default in that case) you can use the other w_changes=RAM2 mode which causes that external upper_changes folder to simply be mounted as top read-only layer on next boot (so not being written to at all in that mode). That's, as I've said, like PUPMODE13 (but a script - or one-line rsync command would need to be used to save back any changes that are saved in RAM). In that w_changes=RAM2 mode, a new temporary upper_changes folder is created in tmpfs RAM area at directory /mnt/layers/RAM/upper_changes - in that mode all writes go into there and are lost on shutdown (unless that rsync sort of script is used to merge back into the on media upper_changes folder).

Yes, I write the words upper_changes so often I often use acronym uc (and in variables related to that), but worth remembering that there can be more than one upper_changes (e.g. the on hard disk or whatever one, and the in-RAM-only one if using any w_changes RAM mode).

Worth additionally mentioning what rockedge has said: prior to reboot if you rename the existing upper_changes with a 2-digit number in front of the name (e.g. 50upper_changes, on next boot that will be loaded at layer 50 as a read-only layer and a brand new read/write top layer upper_changes folder will be auto-created in that bootfrom directory. That allows you to 'rollback' to previous upper_changes any time you wish simply be deleting current upper_changes and renaming 50upper_changes back to simply upper_changes. You can have a whole series of such previous upper_changes (e.g. 50upper_changes, 51upper_changes and so on) and fredx181 and rockedge and rufwoof have provided some utilities to merge such folders when and if required too. And, yes, if you want back to pristine state just delete upper_changes (and any such rollback variants you might have made).

All of the above also applies to any distro installed using weedogit.sh by the way.

Whilst it is not necessary to use w_changes=RAM2 mode (the PUPMODE13 equivalent), it would be nice to have that needed rsync script incorporated and polished. Personally, as posted elsewhere (somewhere buried in this thread) I've just used a one line command for that, but that's not polished. There may be issues regarding whiteout effects that 'may' or may not be problematic and in merging we don't want to merge any unneeded temporary cache folders and files (so polished integrated script should include an 'exclude list'). I've never myself bothered developing that script, but I see that as main development/experimental work needed to move KLV-Airedale from Beta to final status (despite w_changes=RAM2 mode being optional in practice).

[wiak]

Btw, maybe /mnt should be empty at initial boot (i.e. changes not containing anything in /mnt e.g. no leftover previous mounted folders), not sure though, @wiak what do you think ? (think of also the issue lately with filemnt, the previously mounted folder inside upper_changes/mnt).

Yes, I've occasionally pondered about that too. Shutdown script should maybe be tweaked to empty it?