Puppy Linux Discussion Forum

I now have autologin root direct to desktop working via the usual systemd override tricks. It is pretty straight forward and well-explained, with subtle alternatives, on the Internet (for examples, google: autologin root agetty systemd; for example, the Gentoo page on this is instructive and for startx too; the X without Display Manager page in Gentoo wiki also gives a neat trick for starting alternative desktop managers depending on login tty being used).

Despite the opinion of some others, I myself find systemd superb to use in practice despite being no expert in its configuration. Void Linux runit is almost as good, though I'm not quite so familiar with runit having spent a couple of years using WDL_Arch, which also used systemd (autologin/startX is somewhat less complex to arrange with systemd than with runit, albeit very similar). The advantage of systemd is partly the way you can use simple override file under /etc/systemd to modify existing service file; unlike with runit, there is no need to create new special getty service for tty1 and disable the original - just creating the override file does it all.

Whilst I will put that autologin-to-desktop feature (as root by default) into rc2 release I might on my own system remove the autologin part (but keep the auto-startx part). For (admittedly basic) security reasons (even at home!) I rather like manually logging in with password to root, or spot, or firstrib, or whoever I've added as user to my system. However, autologin as root to desktop is the usual for most on this forum, so by default, despite the even more security conscious, that is the form rc2 release will take. It does work well in my tests and avoids the added bloat of a login display manager such as lightdm.

Having said that, without some further configuration trick, the shutdown Logout choice would automatically re-login back as root user to desktop without the option of ever then logging in as spot or firstrib... I will therefore endeavour to provide a userswitch menu choice such that you can re-login as spot or firstrib instead... That might do me as well, rather than actually disable automatic login (except I prefer my own system to need a login password). The way KLV-Airedale does logout to new login prompt is fine actually.

As I said before, I will also fix up some of the minor issues I noticed on publishing rc1. I doubt that I'll actually be adding much to the base system since keeping that one pretty much as it is, with these 'fixes' is really my plan, but with the idea that KLU-jamCE version will thereafter be released to include whatever the Kennel Linux community agree on.

I will also explain on release of rc2 how to remove the autologin facility if you so choose (but can keep the auto-startx part of the mechanism if you wish). Most I expect will probably want to keep full autologin to desktop capability though.

I have it installed on my desktop.

It's fast. Really fast.

It didn't see my ethernet connection and the xfce "Network connections" creating a connection didn't seem to fix it.

edit: corrected line of output below to right one

root@ubuntu:~# lspci
[snipped]
00:19.0 Ethernet controller: Intel Corporation 82578DM Gigabit Network Connection (rev 06)

Missing driver??

Wireless works fine.

Installed synaptic and with it firefox-esr. Got some apt-get time zone mismatch errors, but Firefox installed fin anyway and I'm posting from it now.

It's really fast.

I ran into this on page 2 of this topic.
Run these commands in a terminal:

dhclient eth0
apt update && apt install dhcpcd5

This will fix it and will connect eth0 and on the next system boot

@wiak I have SFS-Load working and successfully loading and unloading SFS modules.

I need to find the the best place to put the 2 scripts that clean up orphaned symlinks. Should be similar to the DebianDog configuration which I am not sure of at this moment @fredx181 might be able to straighten me out on the correct placement so a service runs the clean up scripts.

rockedge wrote: ↑Thu Jan 26, 2023 10:33 pm

@wiak I have SFS-Load working and successfully loading and unloading SFS modules.

I need to find the the best place to put the 2 scripts that clean up orphaned symlinks. Should be similar to the DebianDog configuration which I am not sure of at this moment @fredx181 might be able to straighten me out on the correct placement so a service runs the clean up scripts.

Generally I prefer new scripts (not official upstream ones) to go in /usr/local/bin rather than /usr/bin, though currently I just go with the flow regarding where they are held in KLV-AIredale; makes it too difficult keeping alternative versions to change paths belatedly.

dancytron wrote: ↑Thu Jan 26, 2023 8:08 pm

Installed synaptic and with it firefox-esr. Got some apt-get time zone mismatch errors, but Firefox installed fin anyway and I'm posting from it now.

Re: ethernet. Try installing dhcpcd5 as rockedge suggests and restart network.

I don't know what fin is, but timezone does need manually set up in KLU-jam since I haven't installed ntpd or similar in it.

To set up timezone manually, here in New Zealand, I open a terminal and enter following (as root user):

timedatectl list-timezones | grep 'Auckland'

which tells me Pacific/Auckland

Then, I run command:

timedatectl set-timezone Pacific/Auckland

and time should be correct then (assuming you haven't entered any clock-related commands that would have changed your BIOS clock). Save that to persistence of course if using save on demand RAM2 mode.

I'm not sure how to include GUI time/date program that can be used via xfce4 StartMenu -> Settings -> Date and Time (or whatever it is called).

@Clarity:
To get internet in Qemu virtual machines with KLU-jam, enter terminal command:

dhclient eth0

Then you can install somehow required dhcpcd5 using terminal command:

sudo apt update
sudo apt upgrade
sudo apt install dhcpcd5

After saving that to persistence savefolder internet should also thereafter be working in Qemu after reboot. I'll include dhcpcd5 in rc2 version.
For some unknown reason the simple dhcp client that is built into NetworkManager isn't proving sufficient in this ubuntu released version.

I won't be adding samba server to purposively slim KLU-jam base system; users wanting samba would have to install and configure that themselves (and obviously use save persistence once they have done that and configured it). Whether samba is seen as worthwhile to include in a later KLU-jamCE (add-to-base Community Edition) will be up to community to vote for or against. Personally I don't use samba, but recommend Plan 9 (9p) sharing between host and guest as simple local machine alternative (which was discussed in KLV threads several times now, and tested by others as pretty simple to use).

No doubt samba server component once installed works very well for those that like that and work also with Windows system. It isn't a trivial or small install though - 110MB additional disk space if upstream repo samba installed to KLU-jam. Size does matter for virtual machines. Yes, can use samba to share printers, but even pretty old printers can often be used remotely via wifi nowadays. Indeed I use wifi connection to my old HP 2540P deskjet so samba-type sharing then not needed in practice. All in all I'm not therefore saying full samba support in a Linux distro isn't a useful facility for some people, but I don't consider it a necessity at all, and certainly not in relatively slim/small forum distros. But as I say that is just one point of view. You simply need to ask for a vote when it comes to main forum CE-type mainstream release. Nice if some Puppy's managed to install some minimised-version of it, but I wouldn't myself have time to work on similar (and wouldn't off top of my head know how) and as far as official package management reliability is concerned I would hesitate to install a version that wasn't from official distro repos. However, if you can convince someone to create a working very small samba server package that can be made into a deb that won't interfere with upstream version then that could be 'considered', if apparently doesn't break anything else, and if no one else thus objects to it, but that's up to you to find that or convince someone to extract from whatever Puppy has such and make it work elsewhere. As I said, I may not even include a Network Time Protocol server daemon in KLU-jam, like alone a big server package like samba, sorry - there is nothing to stop you installing it yourself and/or for the benefit of any student(s) though.

Regarding 'students'. I used to be a lecturer teaching Data Comms, and Linux, and more. Puppy Linux was no use in such classes because it wasn't multi-user capable and most Linux training is really concerned with multi-user admin (resource permissions and so on). Linux is a good alternative to MS windows, but it is a different system and if MS windows users think Linux is not for them just because it doesn't by default use windows sharing protocols then what use would such individuals be to this forum anyway? I don't see it as our job to bloat our small Linux systems simply to try and attract MS windows users over to this 'dark side'; fine if no effort or bloat involved, but that is not the case here. Good technical-computing type individuals will always find Linux; typical MS windows general users, probably not, but that is maybe just as well... The 'some' non-technical MS windows users who do end up using Linux adopt Linux for their own differing reasons (and probably nothing to do with samba, which generally needs set up anyway), and some of them do go on to learn enough about Linux to be useful contributors to this forum - those who don't usually end up causing trouble and getting banned from here anyway! I got your point about trying to make our distros work with Ventoy (at least for now whilst Ventoy has some traction) - less so SG2D - but samba argument is not very convincing at all IMO so my advice would be to vote on it and then accept the vote...

My answer would be different if samba was tiny and essential. Alas, it is neither of these. Evan upstream samba-client package required over 63 MB to install......... that is not an attractive default install candidate to be frank.

@wiak I already put all of those scripts and utilities in /usr/local/bin in KLV-Airedale.
KLV started out with putting all of the extra Kennel components in /usr/local/bin

The scripts run and finish are run as a service by runit and will have equivalent systemd service files/configurations.
At system start the run script cleans up the orphaned symlinks if the system had shutdown previously without unloading any of the installed SFS files beforehand and the finish script was never run by systemd as part of a routine shutdown/reboot.

Then a system stop/restart occurs under normal conditions the finish script does the same thing and cleans up any dangling symlinks from the SFS load.

rockedge wrote: ↑Fri Jan 27, 2023 12:09 am

@wiak I already put all of those scripts and utilities in /usr/local/bin in KLV-Airedale.
KLV started out with putting all of the extra Kennel components in /usr/local/bin

The scripts run and finish are run as a service by runit and will have equivalent systemd service files/configurations.
At system start the run script cleans up the orphaned symlinks if the system had shutdown previously without unloading any of the installed SFS files beforehand and the finish script was never run by systemd as part of a routine shutdown/reboot.

Then a system stop/restart occurs under normal conditions the finish script does the same thing and cleans up any dangling symlinks from the SFS load.

Not all such scripts are in /usr/local/bin rockedge. I was thinking in particular of save2flash related scripts. Only snap-ex is in /usr/local/bin, the actual save2flash and snapmergepuppy components are in /usr/bin. I modified these for use in FR_AOT2 (and thus KLA) to use /usr/local/bin instead, but I since realized that modification of paths is problematic in terms of maintenance between /usr/bin and /usr/local/bin versions (i.e. I don't want to maintain two versions). I'm saying that it would be better if all such scripts were kept out of /usr/bin

Yes, I understand systemd service files and so on will be required for some of the KLV-type utilities to work under KLU-jam.

To help me incorporate other KLV FR-related scripts in KLU, please send me the scripts, ready for appropriate installation, and configs that were used for runit and I'd try and make systemd variants. Please include any shutdown script components that I can see how best to include in KLU shutdown mechanisms and so on, or suggest where and how exactly if you already have these details worked out. I'm not likely to analyse KLV offerings in detail very quickly so unlikely to include many of the possibilities in KLU otherwise; they are generally tiny inclusions so would be nice to include them if not a lot of work involved finding them all and knowing how to include them in easiest quickest way possible... Fact is, though it is nice to have them, I don't myself use many of the facilities on offer (sfs-load on the fly, for example - I'm never used it, but realise it is useful to have and often used by others, but just not me; I tend to prefer package manager installations or if really wanting to use a new sfs layer, I tend to prefer numbering one and then reboot. Also, in theory save2flash process is fine, and seems to work in practice, though I don't know if it ever gets anything wrong somehow, so for business use I avoid it because any such system is open to corruption if say power fails or simple rsync coding algorithm error/missed special case possibility. I have come to trust FR initrd init code logic though, which is maybe encouraging?!!! ).

Sofiya wrote: ↑Thu Jan 26, 2023 1:47 am

First of all, let's update the list of packages: sudo apt-get update && sudo apt-get upgrade

Let's add additional "plugins" components with the command: sudo apt-get install xfce4-goodies
sudo apt-get install xfce4-whiskermenu-plugin

Dropdown terminal in XFCE :xfce4-terminal --drop-down to start, write on the hot key.It is very convenient

Yes, xfce4-whiskermenu-plugin can be installed separately (or it is included in the somewhat large xfce4-goodies package). You just add it to panel items and can move it to applications startmenu position and then can remove Applications panel item altogether if you wish. I'll probably do that in my home installations. I don't want all of goodies package at all though so would install individual ones as and when I want/need them:

 xfce4-battery-plugin xfce4-clipman xfce4-clipman-plugin xfce4-cpufreq-plugin
  xfce4-cpugraph-plugin xfce4-datetime-plugin xfce4-dict xfce4-diskperf-plugin
  xfce4-fsguard-plugin xfce4-genmon-plugin xfce4-goodies
  xfce4-mailwatch-plugin xfce4-netload-plugin xfce4-places-plugin
  xfce4-screenshooter xfce4-sensors-plugin xfce4-smartbookmark-plugin
  xfce4-systemload-plugin xfce4-taskmanager xfce4-timer-plugin
  xfce4-verve-plugin xfce4-wavelan-plugin xfce4-weather-plugin
  xfce4-xkb-plugin

Interesting the very similar xfce4-screenshooter screenshot program (1050 kB) consumes much more disk space than gnome-sceenshot tool (262kB). I will include the latter in rc2.

@wiak I have SFS-Load working in KLU!!

I think I have the run and finish script set up to run as systemd services correctly as well. a test here will tell.

Some of the script locations I used straight as they were packaged by fredx181 and I didn't bother to switch it all to /usr/local/bin.

I used the full goodies package but it would be even slicker to do them individually. The list of the names of the packges helps a lot.

sfs-load-run.service

[Unit]
Description=clean up orphaned symlinks

[Service]
ExecStart=//usr/lib/systemd/scripts/run-symlink-clean.sh

[Install]
WantedBy=multi-user.target

sfs-load-finish.service

[Unit]
Description=clean up orphaned symlinks
DefaultDependencies=no
After=final.target

[Service]
Type=oneshot
ExecStart=/usr/lib/systemd/scripts/finish-symlink-clean.sh

[Install]
WantedBy=final.target

rockedge wrote: ↑Fri Jan 27, 2023 2:03 am

@wiak I have SFS-Load working in KLU!!

I think I have the run and finish script set up to run as systemd services correctly as well. a test here will tell.

Some of the script locations I used straight as they were packaged by fredx181 and I didn't bother to switch it all to /usr/local/bin.

I used the full goodies package but it would be even slicker to do them individually. The list helps a lot.

In a moment I will post the scripts here...need to call up the post in KLU in the QEMU VM

Very good. I'll definitely put that into rc2 once you upload the parts ready for quick inclusion. I'll wait a few days maybe for anything else! Depending the form they take, I might well install these into KLU (before making new iso) as deb files so easier to upgrade should changes to them ever occur. But just post them in whatever form you have them once ready.

here are the SFS-Load binaries which go into /usr/local/bin.

The service files go into /usr/lib/systemd/system

The scripts go into /usr/lib/systemd/scripts/

Theoritically it all works....

Thanks rockedge. I'll put that in rc2 release. No hurry - giving time for various fixes and additions to be determined.

Note that users need to set default terminal and browser for xfce - that can be done with GUI via

StartMenu -> Settings -> Default Applications

I'm using chromium-browser via apt install chromium-browser. Of course that needs run-as-spot or --no-sandbox. Currently I have small startup script I call "chromium-root.sh" in my /usr/local/bin that I use as default browser when logged in as root. All I have inside that is:

#!/bin/sh
exec run-as-spot chromium-browser "$@"

As far as autologin as root to desktop is concerned, I do:

mkdir -p /etc/systemd/system/getty@tty1.service.d

and in there have attached override file (remove dummy tar), saving to persistence of course.

Note I also have a folder /etc/systemd/system/getty.target.wants that contains a symlink, which can be made from terminal from that directory via:

ln -s /usr/lib/systemd/system/getty@.service getty@.tty1.service

In practice, I actually used systemctl to do above, but manual creating it, as decribed, should also work. A reboot will be necessary to get it going of course.
All of above systemd-related pieces are for achieving the autologon as root user.

The autostartx bit I currently do by simply adding to end of ~/.profile the following:

if systemctl -q is-active graphical.target && [[ ! $DISPLAY && $XDG_VTNR -eq 1 ]]; then
  exec startx
fi

If you have any trouble with any of above, wait for rc2 release where I'll have polished up some aspects of it probably anyway.

rockedge wrote: ↑Fri Jan 27, 2023 2:03 am

The list of the names of the packges helps a lot.

I just noted the list as reported when doing apt install xfce4-goodies! but I am sure there are better apt-related methods...

Note: for base KLU-jam I feel apt is perfectly fine enough. Actually I never use GUI software installer such as Synaptic Package Manager (install name "synaptic") but you can install that yourself, adds a wee bit bloat for sure though: apt install synaptic
Having said that it is convenient and informative (saves a lot of google ubuntu packages, which I tend to do often... Then again, when I see something in Synaptic I generally need to google about it anyway...).

@wiak I also used systemctl to enable the SFS-Load symlink cleaner's.

After putting the files in place:

systemctl enable sfs-load-run
systemctl enable sfs-load-finish

I also tend to use APT on the command line but can understand the draw to the GUI

Although I did bring on the SFS-load method for 'overlay' by using symlinks, I need to say that I don't really like it (and cannot guarantee that it works in all cases), it's tested briefly by me and some others (and was OK), BUT cannot be 100% sure that it works OK with all distro's (e.g. Ubuntu ) specially in case if an SFS loaded and running apt install ... containing files / packages that are also in the loaded SFS, much more testing needed for such special cases IMHO.

So, see this as just a little disclaimer from me (EDIT: Or as discouragement )

Looking back, I see it as a nice experiment, but frankly I never liked the 'idea' that the filesystem contains a bunch of symlinks from sfs-load and need to be 100% sure these are all removed at shutdown.
I know TinyCore works similar, using "packages" that create symlinks in the system, but that's well thought about, and it's the only way to install packages, so no possible interference with any other method to install software.

@fredx181 I will scrap the idea. What you say makes sense and the convenience of SFS can probably be gotten elsewhere.

I'm done adding anything to this anyway. Going back to seeing about finishing F96 to at least give it a short run and maybe mess around with KLV and some other desktops

KLU-jam is fine as is really. Oh and the SFS-Load seems to work really well on KLU indicated by the testing I am doing

@rockedge Ha, looks like I was able to discourage you about something for once !
But not going to make a habit of that
But now we speak about it, perhaps better also for KLV to offer the sfs-load as a choice to install instead of default including it, your choice, personally I'm fine with both btw.
I don't have the impression that SFS load on the fly is regularly used by people nowadays (edit: I mean on KLV, KLU ...).

fredx181 wrote: ↑Fri Jan 27, 2023 7:44 pm

@rockedge Ha, looks like I was able to discourage you about something for once !
But not going to make a habit of that
But now we speak about it, perhaps better also for KLV to offer the sfs-load as a choice to install instead of default including it, your choice, personally I'm fine with both btw.
I don't have the impression that SFS load on the fly is regularly used by people nowadays (edit: I mean on KLV, KLU ...).

I've been thinking about your sfs load discussion. I've actually never myself used the facility (even though I've noticed it is available on KLV) though I could see why some people find if useful (rather than simply add new numbered sfs and have to reboot).

I did wonder about all the symlinks that are involved and possible issues if cleaning up didn't quite work 100% ever.

My feeling therefore is that sfs-load won't be put into my published KLU-jam base release when I publish rc2. Rather, if it can be an addon option for those who want it and are aware of any potential risk (demonstrated or imagined as possible) that will be fine and better I think. Overall, KLU-jam is almost fine in the form it is other than the few small fixes and finishing off jobs already discussed in top post of this thread and since.

A Community Edition of that base is however another matter. Anyone can take on management and organisation of that and is entirely up to the community what kennel or external components they want to put into that. Clearly any build of any distro on this forum comes with disclaimer "use at your own risk"!

Later I might look myself at sfs-load mechanisms. I'm very familiar with tinycorelinux itself and I've always meant to study how they do it in order to determine how well it could be made to work over here. And then I would also look at fred's variant and decide if I think it could become dangerous in any way (such as collisions with dpkg/apt somehow). However, I might never get round to looking at it since it is such low priority for me personally! I do notice that dimkr seems to have worked on something similar for Puppy (for overlayfs-based newer Pup creations), but I haven't read the code - just noticed github woof-CE related comments.

EDIT: If KLV decided to take sfs-load out as a permanent option, I suppose the option to add it as a choice would become available immediately to KLU as well since would have to be packaged somehow, so there is an advantage there at least. It sounds like it is not known if the option currently poses any risk to the system overall, in which case would definitely be better only provided, with disclaimer, for user choice.

NOTE: I mentioned that KLU-jam was a build type, not yet completed in scripted form (I'm working on that too). As I indicated previously, that build lay part way between a sort of build_firstrib_rootfs plugin-type build and that of the weedogit method (which utilises any root filesystem almost via FR initrd bolt-on). In other words final script to make it, does involve an as yet uncompleted f_plugin type build plugin. However, the build does not use upstream debootstrap at all but instead starts from small root filesystem from Ubuntu repos, which I add the packages and simple configurations to, Fortunately, the main part of that is already done by Ubuntu XFCE release - or would be too much work for me to bother! Of course any small utilities added to it thereafter are from work of myself and others on this forum, which is why the KL designation. For example, whilst the underlying RAM2 save persistence mechanism is provided by FR initrd, the rsync utility to save back to the savefolder is a user script and the one being used nowadays is that by Fred (fredx181). The final build script will contain all the details of how it is built of course (aside from any bits I found too tricky to put in the script but had to do manually prior to making the iso such as configuring thunar and cherrytree for the user-available preferences I like by default). At the end of the day, it will be a really simple script thanks to Ubuntu repo XFCE already configured mainly, and so will be more like weedogit distro code in terms of script details. Yes, I could have started with a default debootstrap system build, as others have done, but I didn't have time to think about the details of what I'd want to add to that (or remove from it) so avoided doing it that way.

I will start finalising rc2 release tonight with autologin to root desktop and so on and the dhcpcd5 addition. Let me know quickly therefore if anything else for now - otherwise I am fine with it as a base as is.
Larger inclusions, if requested, will be released per community agreement in a KLU-jamCE release (assuming larger version requested).

The base is no doubt the correct place for tiny extra like utility scripts but I will only include other ones if they are my own or if requested by others. It is easy enough in any case for users to install what they want themselves - the only caveat on that is for those who may run the distro via an iso boot mechanism. I have had a request for samba, which could be put in a KLU-jamCE, but if I do that it will come unconfigured since I don't use samba and don't know how to configure it.

We could just copy the default Puppy Linux samba configuration from /etc/samba to supply a config to be able to start the samba daemon

rockedge wrote: ↑Sat Jan 28, 2023 8:15 am

We could just copy the default Puppy Linux samba configuration from /etc/samba to supply a config to be able to start the samba daemon

What I'll do is complete rc2 of base KLU-jam, which is probably enough for my own needs. Then someone willing to collate and agree on what to add for a CE version would be a good thing. Reason I say that is that best to have separate announcement thread for KLU-jamCE with whoever takes on the production of that leading the thread from the start. Clearly we can explain (in time) how to make the iso starting from an available KLU-jam iso. As you at least know @rockedge it is matter of making a frugal install from the base KLU-jam iso and then adding to the root filesystem via one of two main mechanisms:

1. Either make a 'pseudo-full-install', which simply means unsquash the 07KLU...sfs and rename it "upper_changes" and make a dummy empty directory for that previous 07 layer position (e.g. mkdir 07dummy). Then when you boot that frugal installation in usual way, any changes made then get saved back into that main root filesystem. Once everything added that is wanted, that upper_changes directory just needs squashed back up into 07KLU....sfs and an iso made out of the result. Obviously the original 07KLU...sfs gets moved out of the folder since it isn't to be included...

Alternative method to add to the iso that is often used is:

2. Unsquash the original 07KLU....sfs as above, and then use utility mount_chroot.sh utility to 'chroot' into it in a terminal. That is:

./mount_chroot.sh upper_changes

In that terminal you can then use apt and terminal commands to add/modify anything you like. At end we exit the choot and use umount_chroot script to clean up the special mounts that were used. Sounds more complicated and I suppose it is a little - but it is easy method in practice too. Easier to do than in fact to explain!

Yes, if no one makes any kind of KLU-jamCE version, and if anyone actually wants one, I could myself eventually use method 1 or 2 myself to add a few requested items and upload the resulting iso, but testing samba is not on the cards - maybe samba would just work if I was supplied with that Puppy /etc/samba file? Samba is a big addition in terms of bloat I should mention, and I'm surprised if a larger KLU-jam is in fact better for any Qemu use (and for normal frugal install a user could add samba on their own anyway if they wanted it!). I do nevertheless feel it would be better if someone new took on the job of making KLU-jamCE out of KLU-jam base (or no-one at all if not enough interest in doing so anyway) since I wouldn't have time to maintain the KLU-jamCE result. I already maintain core FirstRib build system, its main utilities, and the FR initrd, all of which already use up more computing time than I really like to further add to for the benefit of others.

only focussing on rc2 release for KLU-jam right now. Will upload soon as I find time to complete one or two details I have in mind - a few days maybe - it is summer and the weekend here.

wiak wrote: ↑Sat Jan 28, 2023 8:46 am

<snip/

1. Either make a 'pseudo-full-install', which simply means unsquash the 07KLU...sfs and rename it "upper_changes" and make a dummy empty directory for that previous 07 layer position (e.g. mkdir 07dummy). Then when you boot that frugal installation in usual way, any changes made then get saved back into that main root filesystem. Once everything added that is wanted, that upper_changes directory just needs squashed back up into 07KLU....sfs and an iso made out of the result. Obviously the original 07KLU...sfs gets moved out of the folder since it isn't to be included...

How would you merge 07KLU*.sfs and a pre-existing "upper_changes" folder into a new 07KLU*.sfs file including deleting all of the files with whiteouts in the "upper_changes" folder? (This being imho what I think is the best way to remaster KL(x)) Linuxes.)

@dancytron I think the method Puppy Linux uses to remaster is sort of okay. I get inconsistent results when remastering with some more intensive packages installed.

The methods wiak describes is the recommended way.

There is no script that merges the root_fs with upper_changes yet. I use the both methods of pseudo full install or chroot the root_fs. These methods have gotten us this far.

rockedge wrote: ↑Sat Jan 28, 2023 8:33 pm

@dancytron I think the method Puppy Linux uses to remaster is sort of okay. I get inconsistent results when remastering with some more intensive packages installed.

The methods wiak describes is the recommended way.

There is no script that merges the root_fs with upper_changes yet.

Having said that, especially when using 07KLU....sfs and only one upper_changes savefolder involved, it should be possible to make a new overlay on the fly composed of 07KLUxxx.sfs on lower layer and upper_changes on upper_layer (though could also be simply used as a top read-only layer. The merged result of that would not have whiteouts in it (since involved in the overlay merge result determination) so could then be squashed up as the remastered 07KLUxxx.sfs. I believe old user1111's merge script probably could be amended for that simple most usual case, though it is easy enough just to write another simple script to set up that new overlay. You can re-use overlay layers as much as you want to set up new overlays so no limitation there. Actually, I use a small new overlay creation in old weedogit script simply to add new users and assign them passwords and groups, something similar easy done on the fly to make a remastered 07KLUxxx.sfs for use on next boot I'd say. I'll look into it sometime - busy fine-tuning rc2 autologin routines at the moment.

Grey wrote: ↑Tue Jan 24, 2023 9:06 pm

Well, I don't know. This throws me into some... despondency, perhaps. I'm talking about the lack of a clear development plan for one, the main distro. We have some kind of European Union in the Linux world: Germany is a locomotive, France is coming on its heels, Poland wants to get through without a queue at all, and so on. And we also have a bunch of everything, but everything is fuzzy.

Here the people are already making separate distros for their personal use. And I, too, to be honest, made a homemade version of Jammypup for myself. In addition, I look in the direction of MagOS, a little-known Russian system even in Russia. Based on Rosa Linux (based on the French former Mandriva). There are UIRD, KDE (& LXQT), configuration files picked up on the fly, and so on. The password for user and root are set in the conf file not as text, but as a hash. Not convenient, but kind of like security.
rpm and dnfdragora are used to install packages. But most importantly, it is a close relative of Puppy at its core.

Well, okay, I'm Russian - I'm easily distracted, not collected and I hope that everything will be solved by itself But someone present should write a plan and follow it in developing a common system. Otherwise, people will start to "run away" from our Association... Union... club of interests.

Have to agree with this. All these different developments must be a total nightmare for a new user who has come to a Puppy Linux site just to download the latest Puppy. I am getting lost with all the goings on myself. I find it strange that we do not have a main, traditional, polished, well-tested and recommended 64-bit Jammy Puppy for example at this point in time. Don't get me wrong, I'm all for development but....

amethyst wrote: ↑Sun Jan 29, 2023 6:49 am

Grey wrote: ↑Tue Jan 24, 2023 9:06 pm

Well, I don't know. This throws me into some... despondency, perhaps. I'm talking about the lack of a clear development plan for one, the main distro. We have some kind of European Union in the Linux world: Germany is a locomotive, France is coming on its heels, Poland wants to get through without a queue at all, and so on. And we also have a bunch of everything, but everything is fuzzy.

Here the people are already making separate distros for their personal use. And I, too, to be honest, made a homemade version of Jammypup for myself. In addition, I look in the direction of MagOS, a little-known Russian system even in Russia. Based on Rosa Linux (based on the French former Mandriva). There are UIRD, KDE (& LXQT), configuration files picked up on the fly, and so on. The password for user and root are set in the conf file not as text, but as a hash. Not convenient, but kind of like security.
rpm and dnfdragora are used to install packages. But most importantly, it is a close relative of Puppy at its core.

Well, okay, I'm Russian - I'm easily distracted, not collected and I hope that everything will be solved by itself But someone present should write a plan and follow it in developing a common system. Otherwise, people will start to "run away" from our Association... Union... club of interests.

Have to agree with this. All these different developments must be a total nightmare for a new user who has come to a Puppy Linux site just to download the latest Puppy. I am getting lost with all the goings on myself. I find it strange that we do not have a main, traditional, polished, well-tested and recommended 64-bit Jammy Puppy for example at this point in time. Don't get me wrong, I'm all for development but....

Okay, so let's get this straight... This is the KLU-jam thread. It is nothing to do with Puppy Linux. If you want a more polished Jammy Puppy then you should be on Puppy Linux thread commenting about that. I suppose it is true that all these unpolished Puppy Linux distros could be a nightmare for new users who would really prefer, but simply don't know about, a true multi-user totally Ubuntu (or Void Linux) compatible distros such as those provided as KL variants, but I would kindly suggest you keep comments about your favourite distro, whatever it may be, to the sections and threads concerned with that. Do not pollute this thread with your Puppy Linux comments that KLU-jam has nothing to do with.

I think I understand your despondency, however, but that is not my fault that you cannot get the polished Puppy Jammy you personally want. Go on EasyOS thread and attack BarryK, or maybe FatDog, if that's what you want to do, but not here thank you. You are simply disturbing busy development work, which isn't development work you are interested in anyway.

wiak wrote: ↑Sun Jan 29, 2023 7:21 am

amethyst wrote: ↑Sun Jan 29, 2023 6:49 am

Grey wrote: ↑Tue Jan 24, 2023 9:06 pm

Well, I don't know. This throws me into some... despondency, perhaps. I'm talking about the lack of a clear development plan for one, the main distro. We have some kind of European Union in the Linux world: Germany is a locomotive, France is coming on its heels, Poland wants to get through without a queue at all, and so on. And we also have a bunch of everything, but everything is fuzzy.

Here the people are already making separate distros for their personal use. And I, too, to be honest, made a homemade version of Jammypup for myself. In addition, I look in the direction of MagOS, a little-known Russian system even in Russia. Based on Rosa Linux (based on the French former Mandriva). There are UIRD, KDE (& LXQT), configuration files picked up on the fly, and so on. The password for user and root are set in the conf file not as text, but as a hash. Not convenient, but kind of like security.
rpm and dnfdragora are used to install packages. But most importantly, it is a close relative of Puppy at its core.

Well, okay, I'm Russian - I'm easily distracted, not collected and I hope that everything will be solved by itself But someone present should write a plan and follow it in developing a common system. Otherwise, people will start to "run away" from our Association... Union... club of interests.

Have to agree with this. All these different developments must be a total nightmare for a new user who has come to a Puppy Linux site just to download the latest Puppy. I am getting lost with all the goings on myself. I find it strange that we do not have a main, traditional, polished, well-tested and recommended 64-bit Jammy Puppy for example at this point in time. Don't get me wrong, I'm all for development but....

Okay, so let's get this straight... This is the KLU-jam thread. It is nothing to do with Puppy Linux. If you want a more polished Jammy Puppy then you should be on Puppy Linux thread commenting about that. I suppose it is true that all these unpolished Puppy Linux distros could be a nightmare for new users who would really prefer, but simply don't know about, a true multi-user totally Ubuntu (or Void Linux) compatible distros such as those provided as KL variants, but I would kindly suggest you keep comments about your favourite distro, whatever it may be, to the sections and threads concerned with that. Do not pollute this thread with your Puppy Linux comments that KLU-jam has nothing to do with.

I think I understand your despondency, however, but that is not my fault that you cannot get the polished Puppy Jammy you personally want.

This is not about any favourites, it's a genuine outcry with ragards to all the confusion that is going on. This is in no way criticism of your or any others' work on the forum....besides this post of mine was a reply to one of the comments ON THIS THREAD (confirming this issue which is also worrying to some others it seems). This post can be moved to another section (don't know which). Off topic maybe...

wiak wrote: ↑Tue Jan 24, 2023 9:55 pm

However, thanks for the interest you have shown despite your post being more than a little off-topic.

I presume my response to 'Grey' was also read. As I commented in my reply to him then, his post was "more than a little off-topic". If anyone wants to yet again discuss their Puppy-oriented unhappiness about the multiple distros this forum is concerned with more generally this is clearly not the forum thread for that discussion. However, I think more than ten years of such complaints (ever since DebianDog really, which was introduced on murga forum in 2013...) has already reached the conclusion that this forum is not a forum for any one distro alone. During these past ten years many have preferred the DebianDogs, for example, or FatDog, to Puppy Linux; that is user choice in action. Perhaps DebianDog should have been banned ten years ago, but it was not - the river flows - development happens, though some distro dev work slows down or dries up. Whatever - that is not my concern in this thread.

Main point is that this is a development/announcement thread for KLU-jam. Don't discuss your Puppy Linux concerns here on this KLU-jam specific thread please. Take it elsewhere if you so wish.