KLV-Airedale-beta+ Released, Ready for Download

[wiak]

A small improvement that should be made prior to release of next iso, which we've discussed before. As provided, Firefox fonts/appearance looks awful, so gives a wrong bad impression. As you know it is a simple matter of going into Firefox Settings, as follows:

Firefox -> Settings -> Language and Appearance -> Fonts and Colors -> Advanced -> uncheck: "Allow pages to choose their own fonts, instead of your selections above"

I would imaging that could be done prior to releasing the iso? Many users wouldn't have a clue about why FIrefox fonts look ugly and wouldn't then use the distro I feel.

[wiak]

Just a wee tip for those who like a single click in Filemanager to open up the likes of an sfs file to see what is inside it:

First of all, simple bit, Thunar: Edit -> Preferences -> Behavior -> Single click to activate items

Then find any sfs you'd like to open and right click on it and select choice:

Open With Other Application...

check box: "Use as default for this kind of file"

and scroll down till you find: filemnt SFS

From then on, a single click on any sfs will open it for viewing... nice. Might be better ways to arrange this, e.g. via some MIME-related right-click action tricks, but that simple "Open With" method worked for me to set it up easily. (Yes, filemnt is already a right-click action, but nice just to have to left click on the sfs or iso I feel).

You can do the same for one-click open iso files using "filemnt CD"

You can also Set a Run Action so similar works from Rox; you just enter name of command in the window, being,
Enter a shell command: filemnt "@"
But the sfs still opens up in Thunar (which is fine for me anyway).

[rockedge]

@wiak I am using a trick to have kernel 5.16.12-RE be able to boot both in Puppy Linux and KLV. By unsquashing 01fdrv-5.16.12-RE.sfs and changing the internal file structure

Screenshot_2022-03-08_09-22-26.png (18.79 KiB) Viewed 1364 times

to :

Code: Select all

/lib/firmware
/usr/lib/firmware

And then I squashed that again. So in effect supplying the firmware in both /lib and /usr/lib. The size of 01fdrv-5.16.12-RE.sfs isn't significant enough to worry me.
I tried out symlinks in this structure but have not tested that more than very quickly.

This way the kernel 5.16.12-RE can be easily put into both Puppy Linux, KLV and WDL systems.

I am considering adding this fdrv into the base huge kernel package of 5.16.12-RE

[fredx181]

A small improvement that should be made prior to release of next iso, which we've discussed before. As provided, Firefox fonts/appearance looks awful, so gives a wrong bad impression. As you know it is a simple matter of going into Firefox Settings, as follows:

Firefox -> Settings -> Language and Appearance -> Fonts and Colors -> Advanced -> uncheck: "Allow pages to choose their own fonts, instead of your selections above"

I would imaging that could be done prior to releasing the iso? Many users wouldn't have a clue about why FIrefox fonts look ugly and wouldn't then use the distro I feel.

Yes, I vote for a fix too.
One way could be to include /root/.mozilla with only "prefs.js" included (which contains the changed fonts/appearance choice)
(but perhaps there's another way not so ugly )
To test (not sure if this works in general) here's .mozilla.tar.gz made that way: EDIT: (advantage is also that firefox start is quicker, at least for me)

.mozilla.tar.gz

(3.16 KiB) Downloaded 39 times

Before launching firefox first time (or delete ~/.mozilla first) extract e.g. if downloaded to /root : tar -zxf /root/.mozilla.tar.gz
(or use Uextract and copy .mozilla to /root)
BTW, I wonder what's the reason that on Void the fonts looks so bad, on other distro's there's no such issue with firefox AFAIK.

[rockedge]

I wonder what's the reason that on Void the fonts looks so bad, on other distro's there's no such issue with firefox AFAIK.

I wonder if I have added enough font support in the rootfs? I will have to check if there are packages missing or can be added to improve this.

I am using the kernel 5.16.12-RE with so far good results on KLV-Airedale-beta4. Considering to release a beta5 with the new kernel and firmware + modules.

[wiak]

BTW, I wonder what's the reason that on Void the fonts looks so bad, on other distro's there's no such issue with firefox AFAIK.

But on these other distros do they use?:

Firefox -> Settings -> Language and Appearance -> Fonts and Colors -> Advanced -> uncheck: "Allow pages to choose their own fonts, instead of your selections above"

I haven't checked as yet. I expect webpages often specify Microsoft fonts - I don't think a small distro should try and contain every font likely, though I don't know much about this issue at all. But I think Airedale contains quite a few fonts already, so I am surprised pages not rendering better if installed fonts were the issue.

[rockedge]

Maybe rockedge remembers more about SG2D boot

We'll start looking into this more in depth soon. The entire /boot needs a look to fix up the help pages and some other adjustments. Some full testing of all the different boot stanza code that is possible with WDL - KLV to get systems started, and in different modes of operation.

Also a look at the fonts and Firefox and how to fix it

[Clarity]

@geo_c from all accounts in your SG2D tests, you have got the understanding correct.

I am sure you (and others too) know that when reaching the KLV Menu screen, you can 'edit' any stanza entry to indicate the desire for "changes" as well as to indicate the location of the changes.

The thing that comes to mind is @gyrog init and shutdown ability and if @rockedge's and other developers using "changes" persistence can/would use the SAVESPEC intent that @gyrog builds to support session discovery.

The 'edit' of KLV at Menu boot time is the same no matter if we used ISO booting via SG2D or Ventoy.

And, the need for anything frugal is unnecessary assuming we all understand the our systems are a simple combination of the backbone ISO file (which never changes) and the persistence files which 'changes' based upon individual PC tailoring.

[fredx181]

After booting with w_changes=RAM2, the save at shutdown option is available, but I'm not seeing those changes stick at next boot.

Also I'm having difficulty understanding the directory structure. After booting and removing the w_changes argument, or booting with w_changes=RAM2, I can't see anything higher than /root/ in the file managers.

So I decided to try and use my previous boot method, which was to mount the iso, copy the files onto USB, and run grub4dos on it. That's giving me kernel panic, with messages about too many symlinks. So that method is not working like it did on beta-1. Or I'm forgetting how to do it properly.

Yes, I tested ISO booting with SG2D too and got the same result with w_changes=RAM2, weird that empty looking / , also /mnt/layers/merged is empty (got there by typing it in the Thunar address bar)
Btw, is your save device formatted as FAT32 ? That could explain the kernel panic perhaps (as upper_changes needs to be on a Linux filesystem) but not sure.

So looks like the important detail is:

Code:

w_changes=LABEL=SG2DISOS=/BOOTISOS w_changes1=RAM2

That works for me, but initially not (kernel panic), probably because /BOOTISOS was on FAT32, so formatted partition to ext4 and then it went OK.
So probably, second entry in loopback.cfg should be:

Code: Select all

menuentry "KLV-Airedale-beta4 (RAM2)" {
    linux /vmlinuz findiso=${iso_path} w_bootfrom=${iso_path} w_changes=LABEL=SG2DISOS=/BOOTISOS w_changes1=RAM2 net.ifnames=0
    initrd /initrd.gz
}

Only thing is that save2flash doesn't work then, scripts expect w_changes=RAM2, so I think it should check for w_changes1=RAM2 too. Or perhaps checking for /mnt/layers/uc_ro is the best ?

But on these other distros do they use?:

Firefox -> Settings -> Language and Appearance -> Fonts and Colors -> Advanced -> uncheck: "Allow pages to choose their own fonts, instead of your selections above"

In Debian firefox it's exactly the same (box = checked and same fonts used) and fonts look ok.

EDIT: Looking at boot/grub/grub.cfg in ISO, I think that this stanza for ISO boot cannot work (vmlinuz not found) (but maybe I'm missing something):

Code: Select all

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

[wiak]

So probably, second entry in loopback.cfg should be:

Code: Select all

menuentry "KLV-Airedale-beta4 (RAM2)" {
    linux /vmlinuz findiso=${iso_path} w_bootfrom=${iso_path} w_changes=LABEL=SG2DISOS=/BOOTISOS w_changes1=RAM2 net.ifnames=0
    initrd /initrd.gz
}

Only thing is that save2flash doesn't work then, scripts expect w_changes=RAM2, so I think it should check for w_changes1=RAM2 too. Or perhaps checking for /mnt/layers/uc_ro is the best ?

I haven't looked at any of this since last time months ago so you are hurting my brain.
I come to hate SGD2 - it is a pain for nothing and complicated WDL initrd/init code and thus risked its stability. Amazingly WDL initrd/init (with w_init) still seems to work more generally. As for the SGD2 bits - thankfully they just get bypassed when not specified as iso... I think the code basically works though.

I don't use findiso at all in WDL, so above, for loopback.cfg, should simply be:

Code: Select all

menuentry "KLV-Airedale-beta4 (RAM2)" {
    linux /vmlinuz w_bootfrom=${iso_path} w_changes=LABEL=SG2DISOS=/BOOTISOS w_changes1=RAM2 net.ifnames=0
    initrd /initrd.gz
}

w_changes is basically used to specify main upper_changes folder, but I allow that to be anywhere, so with:

w_changes=LABEL=SG2DISOS=/BOOTISOS

that is specify media upper_changes will be in that /BOOTISOS location, but then if you want to also use a RAM mode well couldn't use w_changes to specify that (since already used) hence for that 'alternative' location (than bootmnt) for upper_changes I needed other variable so called it w_changes1 for that special case. Hence w_changes1=RAM2 is correct above. So for SG2D you would indeed need to modify your rsync script accordingly. One way would be to detect w_changes1 usage; whether you could rely on /mnt/layers/uc_ro I'm not so sure (if it was left behind on shutdown but not using RAM2 mode next time, you would have a problem...).

Regarding that other grub stanza you mention:

Code: Select all

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

That really hurts my brain, but I think that will not work with SG2D. Rather the w_bootfrom=LABEL..., from very hazy memory, seems like might be to do with booting iso direct from grub2 menu (not involving SG2D per se) but I'm kind of guessing because I can't remember how to even do that any more. You gave an example last time, but I'd have to search for it to work out what works for that and what doesn't. I do note I made a comment in the WDL initrd/init script that suggests LABEL could be used for direct grub2 boot:

# but direct grub2 boot from isofile can optionally
# use WDL UUID or LABEL method to ascertain bootmnt
# instead of needing _find_bootmnt search

but really I'm currently brain dead and SG2D just pains me (Ventoy even more so since it is very different again). WDL initrd, as I've said was designed for 'old-style, normal' put the bits in a directory on their own type of frugal install and frankly that's best for me (and my hurt brain). I certainly don't want to complicate the initrd/init further just for the sake of SG2D - but I think it works with that top grub stanza anyway (but yes, your rsync script will need adjusted to deal with that - see... more work and just because of SG2D that some wrongly imagine would just work with some simple savespec file attached - em, no - life is not so easy - depends how your initrd/init works and WDL one is very flexible but simplistic in that it does not do a lot of auto searching and expects user to specify where everything is (which didn't work with SG2D as you know).

Main issue when booting from iso is that the boot occurs then from a loop mount (mounted to /mnt/iso) and that iso could be on any partition and in WDL you can put your external upper_changes anywhere you like! so w_changes is needed to say where it is (and w_changes1 is then needed to say what RAM mode you are wishing to use if any...). So WDL initrd flexibility makes it hard to handle SG2D's stupidity... but it can at least be done. So can Ventoy but different again. I prefer just to forget both of them though!!!

Last time all this was discussed was on this following thread -> this was quick post re: Ventoy without any detail: viewtopic.php?p=40482#p40482
Also re w_changes1: viewtopic.php?p=40257#p40257
and viewtopic.php?p=40258#p40258

In that I mention loopback.cfg (which is on skel initrd download post - see WDL Cheatsheet link in my signature and find it from that). But here is what I put in suggested items for loopback.cfg back then (I knew better what I was doing re SG2D at the time of course - but forget most all of it now...):

Code: Select all

menuentry "WDL-Void-xfce4-rc3 - changes RAM0 mode" {
	linux /vmlinuz-5.4.70-rt40 w_bootfrom=${iso_path} w_changes=RAM0 net.ifnames=0
	initrd /initrd_v501rc1.gz
}

menuentry "WDL-Void-xfce4-rc3 - changes RAM0 mode w_copy2ram" {
	linux /vmlinuz-5.4.70-rt40 w_bootfrom=${iso_path} w_changes=RAM0 net.ifnames=0 w_copy2ram
	initrd /initrd_v501rc1.gz
}

menuentry "WDL-Void-xfce4-rc3 - changes on media/BOOTISOS" {
	linux /vmlinuz-5.4.70-rt40 w_bootfrom=${iso_path} w_changes=LABEL=SG2DISOS=/BOOTISOS net.ifnames=0
	initrd /initrd_v501rc1.gz
}

menuentry "WDL-Void-xfce4-rc3 - LABEL bootfrom - changes on media/BOOTISOS" {
	linux /vmlinuz-5.4.70-rt40 w_bootfrom=LABEL=SG2DISOS=${iso_path} net.ifnames=0 w_changes=LABEL=SG2DISOS=/BOOTISOS
	initrd /initrd_v501rc1.gz
}

menuentry "WDL-Void-xfce4-rc3 - LABEL bootfrom - changes on media/BOOTISOS w_copy2ram" {
	linux /vmlinuz-5.4.70-rt40 w_bootfrom=LABEL=SG2DISOS=${iso_path} net.ifnames=0 w_changes=LABEL=SG2DISOS=/BOOTISOS w_copy2ram
	initrd /initrd_v501rc1.gz
}

menuentry "WDL-Void-xfce4-rc3 - changes via named partition (location unreliable)" {
	linux /vmlinuz-5.4.70-rt40 w_bootfrom=${iso_path} w_changes=/mnt/sdb2/WDL net.ifnames=0
	initrd /initrd_v501rc1.gz
}

menuentry "WDL-Void-xfce4-rc3 - changes via named partition (location unreliable) w_copy2ram" {
	linux /vmlinuz-5.4.70-rt40 w_bootfrom=${iso_path} w_changes=/mnt/sda2/WDL net.ifnames=0 w_copy2ram
	initrd /initrd_v501rc1.gz
}

menuentry "WDL-Void-xfce4-rc3 - LABEL bootfrom - changes RAM0 mode" {
	linux /vmlinuz-5.4.70-rt40 w_bootfrom=LABEL=SG2DISOS=${iso_path} net.ifnames=0 w_changes=RAM0
	initrd /initrd_v501rc1.gz
}

menuentry "WDL-Void-xfce4-rc3 - LABEL bootfrom - changes RAM0 mode w_copy2ram" {
	linux /vmlinuz-5.4.70-rt40 w_bootfrom=LABEL=SG2DISOS=${iso_path} net.ifnames=0 w_changes=RAM0 w_copy2ram
	initrd /initrd_v501rc1.gz
}

menuentry "WDL-Void-xfce4-rc3 - LABEL bootfrom - changes RAM2 mode" {
	linux /vmlinuz-5.4.70-rt40 w_bootfrom=LABEL=SG2DISOS=${iso_path} net.ifnames=0 w_changes=LABEL=SG2DISOS=/BOOTISOS w_changes1=RAM2
	initrd /initrd_v501rc1.gz
}

menuentry "WDL-Void-xfce4-rc3 - LABEL bootfrom - changes RAM2 mode w_copy2ram" {
	linux /vmlinuz-5.4.70-rt40 w_bootfrom=LABEL=SG2DISOS=${iso_path} net.ifnames=0 w_changes=LABEL=SG2DISOS=/BOOTISOS w_changes1=RAM2 w_copy2ram
	initrd /initrd_v501rc1.gz
}

menuentry "WDL-Void-xfce4-rc3 - LABEL bootfrom - changes RAM1 mode" {
	linux /vmlinuz-5.4.70-rt40 w_bootfrom=LABEL=SG2DISOS=${iso_path} net.ifnames=0 w_changes=LABEL=SG2DISOS=/BOOTISOS w_changes1=RAM1
	initrd /initrd_v501rc1.gz
}

menuentry "WDL-Void-xfce4-rc3 - LABEL bootfrom - changes RAM1 mode w_copy2ram" {
	linux /vmlinuz-5.4.70-rt40 w_bootfrom=LABEL=SG2DISOS=${iso_path} net.ifnames=0 w_changes=LABEL=SG2DISOS=/BOOTISOS w_changes1=RAM1 w_copy2ram
	initrd /initrd_v501rc1.gz
}

menuentry "WDL-Void-xfce4-rc3 - changes on media/BOOTISOS" {
	linux /vmlinuz-5.4.70-rt40 w_bootfrom=${iso_path} w_changes==UUID=C836EF5836EF45D2=/BOOTISOS net.ifnames=0
	initrd /initrd_v501rc1.gz
}

menuentry "WDL-Void-xfce4-rc3 - UUID bootfrom - changes on media/BOOTISOS" {
	linux /vmlinuz-5.4.70-rt40 w_bootfrom=UUID=5c332b83-1bc5-409b-bf2c-ea1d5f3c28a2=${iso_path} w_changes=UUID=5c332b83-1bc5-409b-bf2c-ea1d5f3c28a2=/BOOTISOS net.ifnames=0
	initrd /initrd_v501rc1.gz
}

menuentry "WDL-Void-xfce4-rc3 - UUID bootfrom - RAM2 changes with ro media/BOOTISOS changes" {
	linux /vmlinuz-5.4.70-rt40 w_bootfrom=UUID=5c332b83-1bc5-409b-bf2c-ea1d5f3c28a2=${iso_path} net.ifnames=0 w_changes=UUID=5c332b83-1bc5-409b-bf2c-ea1d5f3c28a2=/BOOTISOS w_changes1=RAM2
	initrd /initrd_v501rc1.gz
}

NOTE WELL the: w_bootfrom=LABEL=SG2DISOS=${iso_path}
that ${iso_path} is not filled in manually, SG2D provides it on boot per usual, but I think you can just use w_bootfrom=${iso_path} instead anyway since that forces the _find_bootmnt() search for iso function to be used, whereas the alternative LABEL method indicates bootmnt partition and so on directly via that LABEL... Note there is also a UUID method of doing it (also employs ${iso_path} variable kernel line argument). But truth to tell I no longer remember how that LABEL/UUID alternative works (maybe just a trick that ends up using _find_bootmnt() anyway) - I probably tested it at the time though so have no reason not to believe it doesn't work. EDIT: Mind you, I see what you mean. You put the iso_path in manually, and I would have thought that would have worked right enough (since ${iso_path} should be the same thing...), so I don't know why not if it doesn't.

All nightmare stuff just for SG2D though. I honestly can't be bothered with it aside from what is already done (which I think is enough for it to work okay anyway - assuming you can get your rsync script to work with the arrangement, which I'm sure you can ). Don't talk about Ventoy, I'm too tired.

[wiak]

I have it in my head that I might be able to change the w_changes/w_changes1 logic that might make SG2D (at least) easier. The original code was never written with SG2D in mind so maybe now I know the issues I can rearrange it a bit to work easier. However, for the moment please just work with above loopback.cfg suggests (whatever works for now). I'd suggest @fredx181 that if you do modify your save2flash code to take account of w_changes1=RAM2 that you make sure to keep backup of existing code since if I successfully alter the logic later that original may fit better.

Late at night so my new idea is maybe just me dreaming anyway. I'm always scared to touch some parts of WDL intird/init since it works so well generally and I don't want to break its overall functionality simply for the sake of SG2D... (since there are various alternative modes I need to keep working as designed).

[rockedge]

Just fixed a small problem starting Thunar as user spot.

Open /usr/share/applications/thunar-spot.desktop and change the Exec line switching from run-as-spot to sudo -u spot ->

Code: Select all

[Desktop Entry]
Name=Thunar spot
Comment=Browse the filesystem with the file manager
GenericName=File Manager spot
Keywords=file manager;explorer;finder;browser;folders;directory;directories;partitions;drives;network;devices;rename;move;copy;delete;permissions;home;trash;
[b]Exec=sudo -u spot thunar %F[/b]
Icon=org.xfce.thunar
Terminal=false
StartupNotify=true
Type=Application
Categories=System;Utility;Core;GTK;FileTools;FileManager;
MimeType=inode/directory;
Actions=open-home;open-computer;open-trash;

This fixes the conflicts with the Xserver when using user spot or weedog and Thunar runs smoothly.

[mikewalsh]

@wiak :-

Honestly, why go to all that trouble for one specific boot method.....particularly given that it isn't widely used? I know one member specifically thinks it's the best thing since sliced bread, and has all but flooded the forum with mentions of it (hence my own past annoyance with them), but then this member seems to think it's their job to steer the community in the direction they think best.

It'll be a cold day in hell when I do something because somebody else thinks I should.

When I belonged to the Ubuntu forums, many years ago, they too briefly flirted with this booting from ISOs malarkey. The fascination lasted all of about 3 months.....then the community just lost interest in it, have reached the same conclusion; that it's more trouble than it's worth. It's yet another of those 'special' things; it's great that the ability to do so DOES exist, but it ain't the be-all & the end-all.

Mike.

[fredx181]

@wiak Yes, I agree with Mike, no need to change anything for ISO boot in the init script IMO, booting from ISO is okay already IMO.
Perhaps you misunderstood what I posted earlier, no intention to hurt your brain (however, nothing wrong with exercise of the grey cells at your age, it will keep you young ).
What I suggested was in fact addressed to @rockedge to change the second stanza in loopback.cfg

And no problem for me to add e.g. w_changes1=RAM2 to check by the save2flash scripts.

One suggestion I have for to change perhaps in the init script is to try avoiding a kernel panic, e.g. when w_changes is pointing to a FAT32 partition that it simply continues with a message that the device should be a Linux filesystem for changes folder support, don't know if it's easy to modify.
(well just assuming that FAT32 (or any other not supported for changes folder) is the reason for the kernel panic, not really sure though).

Also, I'd like to repeat, and that's also a question for rockedge or anyone, the entries in boot/grub/grub.cfg for ISO booting, e.g.:

Code: Select all

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

Can it work that way, or similar ? I think it needs a somewhat more complex code with "loopback" (just GRUB2, nothing to do really with SG2D).

[Clarity]

I agree that KLV (or INITs in PUPs) should not be changed for SG2D or any other boot-assist power-on helpers; ie Ventoy or future.

I do recognize the 'demand' by SG2D to insure it is dealing with a GRUB2 aware distro by purusing for a lookback.cfg...as it intends to support GRUB2 from years ago.

SG2D does not do anything other than to list the ISO file along with the bootable system(s) it finds for user selection.

When the ISO file is found and the user launches it SG2D is no longer involved in what the distro does to boot the PC.

In our case, GRUB2-EFI is involved to list the Menu and follow directions to Initialize the PC and allow the distro to manage setup to desktop. The booting distro only sees what was given to it by the environmental discoveries it finds. SG2D, for all practical purposes, is gone when distro's Menu launches. At this point, the distro boot should behave as any other frugal/LIVE boot we have seen for ages.

One of the problems that affect many PUPs and distros, in general, is that on some platforms they boot to desktop and on other the distro will exit to the GRUB2 command prompt as it cannot find its needs to continue the boot operations. This is NOT a new problem as it has affected MANY distros I have seen over the years including some in Puppyland. My last occurance of this problem on specific platforms was with @mistfire's distro last year where he has init tools to capture the problem. He used the output to diagnose and resolve the problem such that his distro boots, now, on ALL of my current PCs without dropping out (or erroring out) to a GRUB2 command prompt.

I have observed the many different PUPs and DOGs in this forum community and there is no standard. per se: WoofCE/WOOFQ/T2/the one used by Vanilla/etc to name just a few. The INIT processing is seemingly different for each of these distros that is generated. So, one consistent answer is not easy when a distro in the forum dies/stops at boot-time. And, I dont see this as a problem related to the 'boot-assist programs' we have been using in Puppyland for 3 years. It is a general problem, independent of any boot-assistant.

In a nutshell, I think development should continue to build as they do AND consider that the boot-assist exist to make it easy for 3 elements

• GRUB2-EFI ISO file booting (<=== this because the Hardware-firmware manufacturers demand this understanding)

• Easy maintenance that users will do by keeping all of their ISO files in a common folder on the boot drive; namely sda/sdb/sdc or...

• Easy placement of the session to be saved (hopefully in some common folder as we do for the ISO files) and found at a subsequent boot time

This has always been done, but until recently, no one has encouraged use of common folders for maintaining ISO files or Session filenames. My idea for this was inspired by the init/shutdown work for Puppy Linux of @gyrog and his adding the creation of a SAVESPEC file to assist save-session discovery.

Simply, the 'boot-assistants' merely intends to do an environmental setup for the selected ISO file to operate as if it is "what we call frugal".

THIS POST is from a USER POINT OF VIEW...not a developer who sees things differently.

[rockedge]

@fredx181 Thanks for the loop.cfg boot stanza! I'm putting it in for beta5

Turns out that for Thunar to launch correctly as user spot I needed to use xhost + and then sudo -u root thunar to start up correctly. Thunar will work with run-as-spot but it is slightly off because it can not connect with the dbus instance due to permissions

UPDATE: added the small script ->

/root/Startup/set_xhost

Code: Select all

#!/bin/sh
xhost +

To allow all users to access the Xserver so the command sudo -u spot thunar %F to work
Disable in a terminal with xhost - or change the execution permissions of /root/Startup/set_xhost so it will not run at system start up.

[wiak]

@wiak Yes, I agree with Mike, no need to change anything for ISO boot in the init script IMO, booting from ISO is okay already IMO.
Perhaps you misunderstood what I posted earlier, no intention to hurt your brain (however,

Well, it is too complicated for my small brain to make any major change to the initrd; TBH I am happy that the existing one works without too much risking breaking it...

The internal initrd complication is nothing itself to do with SG2D (tho allowing that to work is what requires the major effort) - a special simple WDL initrd/init could easily have been made if everyone in the world just using SG2D so from the 'user perspective' it may indeed seem odd that it is difficult to arrange for SG2D to use RAM mode upper_changes. The complication is that there are lots of options that all inter-related in WDL initrd/init (the very complications that give it so much versatile functionality), which allow expert users to put external upper_changes in any directory and any partition on the system and to have that auto-mounted, as well as the ability to put the sfs addons in any directory in any partition on the system, which also needs auto-mounted if being used. Then for all of these you can use the various RAM modes that alters everything in terms of what layers end up in the overlayfs!!! Believe me, trying to also add new option where all the bits and pieces are not in a partition/directory at all, but instead in a loop mounted iso threatens to wreck all the other facilities (that still need to be available for full functionality). Hence me saying my brain hurts.

Nevertheless, last night I decided I could maybe simplify one aspect to do with SG2D iso use; per the original WDL initrd/init code the only way I could accommodate it was to also specify the partition/pathdir where the iso is stored via w_changes and that meant having to also use w_changes1 for specifying the RAM modes. It struck me I could maybe avoid that with some careful re-arrangement.
I have now slightly modified a small section of the extra code I originally added to allow SG2D to work along with some associated change in w_init to do with w_changes handling. I believe the new initrd I am about to try will therefore now work with simplified loopback.cfg stanza as follows (and w_changes can be left as w_changes=RAM2 when that mode is required - i.e. no need to use w_changes1 argument to specify where the iso is located since initrd auto-knows that anyway):

Note, this will NOT work with existing WDL initrd, but I'm hoping will work in this new/amended initrd/init+w_init, which I have written/completed but not at all tested yet. One other improvement is that an extenal w_init couldn't work with SG2D before but I am hopeful will work with this one. The loopback.cfg stanza I'm hoping will later work is like this:

menuentry "KLV-Airedale for SG2D RAM2 mode" {
linux /vmlinuz w_bootfrom=${iso_path} w_changes=RAM2
initrd /initrd.gz
}

and maybe... also the likes of:

menuentry "KLV-Airedale for SG2D RAM2 mode" {
linux /vmlinuz w_bootfrom=LABEL=SG2DISOS=${iso_path} w_changes=RAM2
initrd /initrd.gz
}

Issue will still remain that the partition format needs to be Linux format for upper_changes to be stored in same directory as the isos. Alas, that is not the case by default with SG2D which seems to use VFAT normally. I would indeed be good to think about that issue later, Fred. First I just want to see if my new idea/amendment work since it would certainly make the loopback.cfg simpler and probably make your rsync script easier then too since w_changes1 not involved. Obviously it is possible for someone to put changes in alternative partition/dir anyway (in normal frugal install use) so for that special case your rsync script would indeed need to take into account w_changes1 anyway though (though could always just not bother since very rare anyone would use that w_changes1 facility I feel.

Will be a day or two till I know if my new idea works or not... complicated testing iso booting - I hate it...!

[wiak]

One suggestion I have for to change perhaps in the init script is to try avoiding a kernel panic, e.g. when w_changes is pointing to a FAT32 partition that it simply continues with a message that the device should be a Linux filesystem for changes folder support, don't know if it's easy to modify.
(well just assuming that FAT32 (or any other not supported for changes folder) is the reason for the kernel panic, not really sure though)

Hmmm... lots of things can cause a kernel panic. Using upper_changes outside of RAM always requires Linux filesystem (since not a save file). That's already pointed out in the general written documentation (well, would be wherever that is...). A user 'should' be able to boot with say w_changes=RAM2 mode but only applicable where the media upper_changes is being brought in from alternative changes position (not the from the bootdir if that is VFAT) and that would definitely require use of w_changes1 since w_changes is used to specify the alternative changes position.

I'm afraid my view is that it is up to the user not to try using upper_changes RAM2 mode if underlying partition is not compatible Linux format rather than to try and get initrd to detect their error and the initrd/init having to then provide that level of error report documentation. But if you can think of a simple line or two for the script I could always add them if don't mess up anything else - I can't think of anything - developers have to provide the loopback.cfg file - perhaps you could have comment in there rather than the init having to worry about it? Main problem is anyway that SG2D usually stores isos on VFAT directory so no way you can store upper_changes save persistence in that arrangement.

[wiak]

@fredx181What happens with the DebianDogs when SG2D is used to boot the iso and they want changes=EXIT mode with a save folder - that won't work either so what gets reported if anything or what happens on attempted boot in that case? I suspect you simply don't provide that option in your loopback.cfg (I haven't checked) but just one for changes.dat savefile, which I don't yet support in WDL initrd and not really planning to as yet (since I prefer save folder) - so no savefile method is one WDL intird limitation. But if you do allow use of savefolder with SG2D in DebianDogs, how do you avoid vfat issue?

Similarly with Puppy distros since most use folder for save persistence nowadays I think (well I always do anyway).

In my view people should use Linux format for their SG2D isos. If upstream SG2D doesn't supply mechanism to create partitions in that way then someone on the forum could provide a utility that makes that the arrangement (and/or maybe someone should badger upstream SG2D to provide installer that makes iso partition Linux format for those that want that).

[wiak]

One issue I have with bothering about SG2D is that according to its github site it has had no maintenance for apparently 2 years, and uses older version of grub2 that contains security issues. To all extent and purposes if that situation doesn't change then SG2D is dead and we need to forget about it.

Ventoy... well it's a different methodology altogether - does it even use a loopback.cfg file? I have no idea actually how Ventoy does its tricks (at least I basically understood SG2D) though I did manage a rough boot from iso for some WDL distro months back (but purely by trial and error and no way using the likes of w_changes=RAM2 mode). Perhaps the new initrd will let it work with RAM2 but if it does then that would be pure luck and not part of my conscious design effort since not knowing how Ventoy works I cannot accommodate it at all in my design thinking.

I will leave the SG2D helper code in the WDL initrd, since some of that also allow direct boot from iso via grub2 standard loopback mechanism without using the SG2D 'extras'. Also maybe someday someone will come back and resurrect SG2D itself, so if you are lucky that will keep working.

But otherwise, use normal in own subdir frugal installs and if you want convenience/automation for doing so, use weedogit for WeeDogged distros, or use pupit for normal Puppy distros (not weedogged) and easy enough to produce a ddogit for standard Porteus-boot-based debiandog distros by modifying pupit.sh since all that does is goes through the usual manual steps for making a psubdir-type frugal install (weedogit is a bit different since it automates the handling of modules and various other bits and pieces that otherwise take a lot of thought and time to do by hand): viewtopic.php?p=50074#p50074

Really, pupit.sh and related are so much easier to set up and use than the likes of SG2D. All you need is any working grub4dos or grub2 and pupit.sh can install all the Puppy distros it caters for (and can be added to to your hearts content) side-by-side for you without you having to even think!

Nevertheless, despite my feeling I'm wasting my time, I have now created a new SG2D usb stick (including resizing the BOOTISOS partitions and making it Linux format (but HOW is doing any of that EASIER for newcomers to Puppy!!!!!!). So I'll soon know if new WDL initrd/init works better with it than existing one does.

[wiak]

My goodness, using SG2D is even more painful than I remembered. Maybe cos I wanted to try save persistence... (hard enough to know how to boot the iso even without that, like alone set up the SG2D usb stick - I'd hate to be a newbie).

So I used FossaDog to see what Fred included in his loopback.cfg.

Did it work easily to achieve persistence with SG2D. No it was a nightmare - and I basically know how SG2D works technically and so know what I am doing.

What was the problem? Well, at least I had the iso stored in Linux format /BOOTISOS, so no issue there. Here is the simple loopback.cfg FossaDog provides:

Code: Select all

menuentry "FossaDog64 changes in fossa_dog folder" {
linux /casper/vmlinuz findiso=${iso_path} from=${iso_path} noauto changes=/fossa_dog  
initrd /casper/initrd1.xz
}

So (prior to examining that loopback.cfg; a newbie wouldn't would they?) the system booted but compained about missing changes file or folder. So I thought, okay, I'll reboot and will no doubt sort itself out... Not exactly...FossaDog popped up a GUI that asked me to select folder to save the changes in (and if I wanted savefile or savefolder) - all well and good I thought. So I chose save folder and had no idea at that stage (I'm a newbie...) where it would be saved so I assumed default and pressed okay. and rebooted... (behind the scenes it turns out it created a SG2D-useless changes folder on the root of my selected usb stick).

On next boot same issues - no saved changes at all. So then I used my non-newbie knowledge and opened up the iso and found the loopback.cfg entry above and noted it wants changes to be in a directory called /fossa_dog. So how exactly does that help a newbie, when you think about it. Okay, so on shutdown this time, I browsed for the usb stick and created a folder on its root directory name fossa_dog, and yes, it worked on next boot. This is NOT user-friendly, and no doubt I would have had no success if I had left the partition as FAT32 and chosen my usual favourite changes save folder (as a newbie I would have given up of course - better to do a simple 'normal' psubdir-type frugal install in practice, sorry, and the loopback.cfg certainly doesn't provide all the usual frugal install facilities we are normally used to - I don't blame Fred for that at all; I'm just pointing out what a newbie NON-FRIENDLY mechanism SG2D proves to be in practice. Unless I am a totally dumb user that is. As for Ventoy... I can hardly work out how to use save persistence with that at all. Forget it.

But sure, I'll try my 'improved for SG2D-use WDL initrd later tonight. Not worth the effort, but may work a wee bit better than it did, but then again, may not.

EDIT: To be 'fair', I next tried VoidPup64 and since I already now have SG2D usb created and working it is true that the Pups have made quite polished loopback.cfg files so work reasonably smoothly with SG2D, so yes, it can be done. But... the fact remains that no 'newbie' could produce a SG2D usb stick without lots of hand-holding anyway - easier just to install grub2 on a stick and use normal frugal installs (not hard to use grub2 loopback either, if you want it - without needing special SG2D installation - though achieving same functionality as normal frugal install in terms of save persistence is always tricky... so much for newbies...). And also the fact that SG2D is not being maintained so the Puppy devs may have simply wasted their efforts on a dead mechanism IMO - I don't really want to do that because there are many more important things to work on that are very much under active development. So, hopefully next WDL intird will do and the matter will rest for some other day... Certainly everyone on this forum has heard all about SG2D and Ventoy now so now further promotion is required at all. I don't want to write it off - maybe such systems will get better one day - but that will come, if at all, from official grub2 developments I feel, or similar.

[wiak]

@rockedge, @fredx181 and @geo_c

Despite all my moaning about hating the effort involved in catering for the apparently no longer maintained SG2D system, I have now produced a new initrd.gz (version 503-rc1) along with a suitable loopback.cfg file that in my test worked really quite smoothly for both default (no w_changes line, which results in upper_changes appearing on the Linux formatted external SG2D boot media at BOOTISOS/upper_changes, that directory being auto-created in that mode) and the w_changes=RAM2 mode (note no w_changes1 required for this now) where the previous used on first boot BOOTISOS/upper_changes gets read-only mounted to /mnt/layers/uc_ro and save2flash utility seemed to work perfectly in my quick tests (I was using beta4, but re-made the iso to use this new initrd.gz and loopback.cfg file). For your interest and information, the new loopback.cfg file that works well in my test is very simply now with main stanzas being:

Code: Select all

menuentry "KLV-Airedale-beta4 (RAM0) - run in RAM only without save" {
    linux /vmlinuz w_bootfrom=${iso_path} w_changes=RAM0 net.ifnames=0
    initrd /initrd.gz
}

menuentry "KLV-Airedale-beta4 (RAM2) - save to BOOTISOS/upper_changes" {
    linux /vmlinuz w_bootfrom=${iso_path} net.ifnames=0
    initrd /initrd.gz
}

menuentry "KLV-Airedale-beta4 (RAM2) - save on demand mode" {
    linux /vmlinuz w_bootfrom=${iso_path} w_changes=RAM2 net.ifnames=0
    initrd /initrd.gz
}

NOTE that this loopback.cfg only works with this new 503-rc1 under-test initrd.gz though. Hopefully nothing was broken in the process of making the related alterations... I am surprised myself at how quickly I have produced this new initrd, so really NEEDS overall testing to be sure its all okay.

You can download the new initrd_v503rc1.gz and the associated new loopback.cfg file from the usual skeleton initrd fetch location (via the get script for the initrd) here: https://weedoglinux.rockedge.org/viewto ... p=355#p355

I posted it in that usual location to avoid tons of initrd's lying around in main KLV thread.

Please try it and let me know if all goes well for you. By the way, if you can't remember how to make a new SG2D usbstick for testing this, I used the instructions by fredx181 as given here: viewtopic.php?p=3959#p3959
Per usual, I had forgotten how to do it and didn't have any record of these details in my cherrytree notebook memory.

All going well, if you also put a copy of w_init into BOOTISOS/ directory, even that should work... Admittedly if same mechanism used with other WDL initrd-driven distros were being used I'd have to change things to differentiate the different BOOTISOS/upper_changes and BOOTISOS/w_init files between them... Maybe some other time in the future...

[fredx181]

@wiak Just to report quickly for now:
The new initrd.gz has a side effect that you probably not intended:
With my regular (grub4dos) setup I tested:

Code: Select all

title KLV_airedale RAM2
uuid 12e1e33f-47a6-4979-b13a-404e60f746b9
kernel /airedale/vmlinuz w_bootfrom=/mnt/sda7/airedale net.ifnames=0 w_changes=RAM2
initrd /airedale/initrd.gz

And the upper_changes folder is in "w_bootfrom" folder (/mnt/sda7/airedale/w_bootfrom/upper_changes)

EDIT: BTW, I wouldn't put too much effort in SG2D ISO boot + persistence, it will never be even close to perfect.
How I look at it, SG2D ISO boot can be nice if you want to try some distro easy by dropping the ISO in BOOTISOS and no intention to save changes, but that's just my opinion.

[wiak]

@wiak Just to report quickly for now (later more):
The new initrd.gz has a side effect that you probably not intended:
With my regular (grub4dos) setup I tested:

Code: Select all

title KLV_airedale RAM2
uuid 12e1e33f-47a6-4979-b13a-404e60f746b9
kernel /airedale/vmlinuz w_bootfrom=/mnt/sda7/airedale net.ifnames=0 w_changes=RAM2
initrd /airedale/initrd.gz

And the upper_changes folder is in "w_bootfrom" folder (/mnt/sda7/airedale/w_bootfrom/upper_changes)

Thanks Fred, I'm not surprised. The new initrd was a first attempt and 'worked' on first attempt and so I expected some issues would not have been thought of my me in the alterations. Now that I know that side effect I'll look into it tomorrow. It was quite a small modification, but slightly major in fundamentals so I understood some odd-effects might occur until I check all the other options and what effect the alteration might have on them (though I hoped for the luckiest best - but that would havve been ridiculously lucky). Late here just now. Interesting side-effect. The wonders of science!

Will likely be other side-effects. Hope they get discovered/reported soon or keep using old initrd in KLV releases for now of course.

[wiak]

Oops I see the probable error cause straight away as I glance at the initrd/init. No time to repackage right now Fred, but it is line 179 in init. Should of course be:

bootfromdir="$w_bootfrom"

instead of:

bootfromdir="w_bootfrom"

Perhaps you can repackage and try again and see what else crops up? Might be lucky yet... I'm off to bed now.

[wiak]

@fredx181 Was such a small error I just fixed it, repackaged and re-uploaded the with same filename: initrd_v503-rc1.
Re-running the get_WDLskelinitrd503rc1.sh will fetch the 'fixed' one. No idea if that fixes all side-effects that may still occur of course, but maybe...

[rockedge]

I wouldn't put too much effort in SG2D ISO boot + persistence, it will never be even close to perfect.
How I look at it, SG2D ISO boot can be nice if you want to try some distro easy by dropping the ISO in BOOTISOS and no intention to save changes, but that's just my opinion.

I totally agree. I'm barely putting effort in SG2D. I am looking for solid reliable booting on many platforms from HDD, USB or CD/DVD in a frugal design

Really easy to make a change and re-build the rootfs SFS when using a "pseudo full install" setup. I decompress the SFS, rename the uncompressed directory to /upper_changes then create the directory /07dummy_rootfs and remove the 07KLV-airedale_rootfs.sfs or rename it with out the 2 digit prefix -> KLV-airedale_rootfs.sfs

Then boot into the system and all changes and upgrades or additions are saved directly to the entire file system structure. I boot into another OS and go back and remove the cache's and the contents of /mnt and remove anymore unwanted files or terminal history from /upper_changes and then squash the directory into a new 07KLV-airedale_rootfs.sfs

Which I then copy into a directory containing for example all of the files for beta5 and then go a level higher and make that directory into a beta5 ISO.

I think that the logs in /var/log should be emptied before squashing. I'll have to look at this. I have not done it up to beta4. Setting up a run of the WDL build scripts to see another run of the PLUG file that builds the raw KLV.

[fredx181]

I wouldn't put too much effort in SG2D ISO boot + persistence, it will never be even close to perfect.
How I look at it, SG2D ISO boot can be nice if you want to try some distro easy by dropping the ISO in BOOTISOS and no intention to save changes, but that's just my opinion.

I totally agree. I'm barely putting effort in SG2D. I am looking for solid reliable booting on many platforms from HDD, USB or CD/DVD in a frugal design

Really easy to make a change and re-build the rootfs SFS when....
...

Very good. Yes, you gotta set priorities for what you see as the most important or useful, otherwise you go crazy, in the worst case it can cause brain damage or depression, well I'm overreacting but still.... ).

@wiak The fix you recently made works ok now for the regular grub4dos install I previously mentioned.
To hurt your grey cells just a little more : About the kernel panic (starts with switch_root message), it's happening for me when booting from FAT32 and with w_changes=RAM2
Probably has to do with save to folder not supported on FAT, would be nice if there's a message e.g. "not supported" and it can continue in RAM0, perhaps not easy as it needs some checking if FAT32 or if savefolder is supported or not.

[Clarity]

General note: It is my understanding that SG2D is continually supported on Adrian (the authors name) SG2D github. He, both, entertains requests and answers changes, if requested.

Anyone of us can post a request there and should expect a response. It is my understanding that he is aware of the continued efforts of several mainline linux distros which incorporate loopback.cfg and another to affort LIVE booting of there distro via its ISO file(s).

Post SG2D on Git, if you feel you would like any answers. (He has 2 products that he maintains)

Hope this is helpful awareness

[Clarity]

BTW: My above post is NOT in support of SG2D. But if our discussion leads to an improved manner to make it all-too-easy for any user to step into this KLV, that is a bonus for KLV expansion and increased use.

We're not addressing this for SG2D, rather we addressing this for direct ISO booting (which it does) and maintaining session files after desktop emerges. ... I think.