KLV To-Do List

[wiak]

... Would be nice to have a simple utility for installing grub2 similarly, something like part of frugalpup that is available in Fossapup (and the newer radky FP)...

Would @shinobar's GRUB2utility be what you'd want? or maybe add GRUB2 utils package.

Yes, I wondered about that one. Answer is I don't know. I have a feeling grub2 is quite large - but maybe that is a special slimmed down version. Grub2 certainly has a lot of capability (including inbuilt scripting/encryption support - hence my believing it may be a large install). Then again if frugalpup can do it, I suppose it isn't as large as I fear. Trouble is I know nothing much about it - I'm at the stage where I can't be bothered learning enough about it to implement any particular tool of my own. There are solutions already available it seems, so I guess I don't have to, but still - how to use with KLV conveniently is the issue.

[wiak]

... Would be nice to have a simple utility for installing grub2 similarly, something like part of frugalpup that is available in Fossapup (and the newer radky FP)...

Would @shinobar's GRUB2utility be what you'd want? or maybe add GRUB2 utils package.

Yes, I wondered about that one. Answer is I don't know. I have a feeling grub2 is quite large - but maybe that is a special slimmed down version. Grub2 certainly has a lot of capability (including inbuilt scripting/encryption support - hence my believing it may be a large install). Then again if frugalpup can do it, I suppose it isn't as large as I fear. Trouble is I know nothing much about it - I'm at the stage where I can't be bothered learning enough about it to implement any particular tool of my own. There are solutions already available it seems, so I guess I don't have to, but still - how to use with KLV conveniently is the issue.

Well, in an experimental quick test I have managed to successfully boot into a qemu qcow2 image, via grub2, that I had made a frugal install into to directory KLV on that qcow2 image filesystem. I will post how I did it in detail later, once I work that out - this kind of install is more than kind of new to me (though in the past I have used frugalpup to install grub2 to a usb stick, but without trying to understand any of what that actually entails). In this instance I didn't use any such Puppy or Dog-related utility. Instead, I simply installed package grub (being for grub2) on my KLV distro using xbps-install, which was booted via its iso as a guest VM via Qemu on my Zorin lite OS host. I then basically just used the grub-install command to write grub2 to the qcow2 image (device sda) that I had attached/mounted as sda1 to the temporarily booted KLV, which was formatted as a ext4 partition. Then I copied my grub.cfg stanza from elsewhere and configured it to boot from a frugal install I made of KLV-Airedale into a KLV directory on that qcow2 sda1 frugal install. It booted. No special utility required, though such a utility may be slimmer or more convenient - end result seems to be the same though.

Sorry, I'm a bit incoherent at the moment. Tired. Everything working so I suppose I should just now relax...

[Clarity]

.. Everything working so I suppose I should just now relax...

You've nailed it. GRUB2 package is rather simple.

Goal!, ...Yea... now Relax!

Cheers

[rockedge]

I've tried to add this grub2config to KLV but not been 100% successful. Some tips appreciated for getting this package working in KLV.

I think with both Grub2config and Grub4Dos in KLV this will round out KLV for real world usage. Especially handy to quickly set up drives virtual or real.

@wiak do you have a small step by step description of how to use grub2 to install the bootloader to the qcow2 disk image?

[Clarity]

... both ...

I am NOT objecting, but I think @shinobar's work invalidates the need for old Grub4DOS with the newer more powerful GRUB2 in his design.

thus, only 1 would need support.

Both, of course, work. Just a thought.

[Clarity]

@rockedge, @wiak, @fredx181
I am NOT a developer, merely a tester of forum offerings. I'm sure all know this.

My past configuration in QEMU tests, with saving sessions, is as follows:

• I have 2 disk image files that I use selectively...never concurrently.

  • 1 is a qcow2

  • 1 is a mere raw

• Each image is formatted ext4 and labeled "Persistence" containing a "Sessions" folder

All sessions for EVERY forum distro is saved in Sessions...always.

The reasons for 2 is "the raw" is my host device (aka host partition) when I might need to validate an observation...from time to time.

Every bare-metal PC I own has a Persistence partition where any/all forum distros I test on the PC will have its "saves" in the PC's Sessions folder.

EVERY PC I have has a completely different system with differing internal components et. al. But what QEMU affords all of us is that its VM is the same no mater where the same QEMU command is executed. Thus, the VM is always the same even though the PC hardwares differ. This is a benefit to all developers.

[wiak]

@wiak do you have a small step by step description of how to use grub2 to install the bootloader to the qcow2 disk image?

I'm still experimenting since I'm not quite sure what I did or how useful it really is. The jist of it is as follows though.
EDIT: Tip. Once booted into the VM, you can cut and paste the commands needed for there (step 3 on) if you first start up VM browser and go to this page URL.

1. I already had a qcow2 image, which I made with command:

Code: Select all

qemu-img create -f qcow2 KLV-Airedale.qcow2 5G  # or whatever size wanted

2. I booted and attached that via qemu:

Code: Select all

qemu-system-x86_64 -enable-kvm -m 2G -vga cirrus -smp 2 -device AC97 -cdrom KLV-Airedale-rc7.2.iso -hda KLV-Airedale.qcow2 -boot once=d   # just -boot d would do I think(?)

3.. Inside that VM I used "gparted /dev/sda" to make sda1 partition on that qcow2 image as an ext4 (as it happens) partition on it. EDIT: Via gparted I needed to make partition table on it via: Device > Partition Table; I just used msdos type. EDIT2: I gave the partition LABEL KLV-Airedale. I also marked it with boot flag though whether that required depends on how I would boot it; MBR BIOS or EFI as far as I understand it - which isn't much. I can't remember if I mounted it, but seems at some stage was mounted to /mnt/sda1 (maybe used: wd_mount sda1).

4. I then simply installed actual grub package (being grub2) using

Code: Select all

xbps-install -Sy grub

5. Then, after various google searches, I found this link regarding installing grub2 onto a usb stick: https://ubuntuforums.org/showthread.php?t=1581099

6. I referred to the part about "From the Live CD:" and tried the command:

Code: Select all

grub-install --root-directory=/mnt/sda1 /dev/sda

7. I then checked /mnt/sda1 and noted grub2-related boot files there, though locale folder seems unneeded. At that stage I made a directory KLV and from /mnt/sr0 I was able to copy all the KLV files in /mnt/sda1/KLV, thus making a KLV frugal install into that qcow2. But at that stage I didn't have grub.cfg so I actually just copied that text file from an existing grub2 install I already had on a usb stick (I resorted to emailing them to myself as a daft way of getting them via browser into the Virtual machine! but of course I should have used ftp or that 9p share method I talked about). Oh, actually was two grub.cfg files; typical arrangement: one placed in /mnt/sda1/boot/grub/ which simply gave link to the main one at /mnt/sda1/grub.cfg

8. Adjusted the /mnt/sda1/grub.cfg with menu stanza for that KLV frugal install and rebooted, and it booted fine.

Note: I used LABEL boot method:

Code: Select all

menuentry "KLV" {
  insmod ext2
  search --no-floppy --label KLV-Airedale --set
  linux /KLV/vmlinuz w_bootfrom=LABEL=KLV-Airedale=/KLV w_changes=RAM2
  initrd /KLV/initrd.gz
}

9. Shutdown the RAM0 iso booted KLV VM guest, and then rebooted with command:

Code: Select all

qemu-system-x86_64 -enable-kvm -m 2G -vga cirrus -smp 2 -device AC97 -hda KLV-Airedale.qcow2 -boot c

As I say, above is just roughly from memory - may or may not be complete, and I have no idea what kind of grub2 install that grub-install command made (I assume it wrote to MBR and so on, since doesn't include EFI files). Probably better not having to install grub via xbps-install, but instead just have smaller utility like grub2config and so on if anyone gets that, or part of frugalpup, working in KLV. Actually, for EFI type booting I imagine just the files from frugal install boot related to grub2 would be enough, but I haven't tried booting via EFI using qemu so have no idea if that involves special options though I guess it will.

The above was a bit of a learning experience. I believe it was a good thing to use actual grub install for this experience rather than just rely on some scripted simple grub2 install utility that isn't mainstream, but of course such a utility is nice and simple and no doubt lighter weight in practical usage.

Note that we are needing a Kennel Linux related HowTo/Including-useful-commands-posts section to help us not lose any howto-related posts.

[wiak]

Booting using UEFI bios apparently requires Open Virtual Machine Firmware (ovmf). It was already installed on my Zorin lite host OS, but I still need to work on using it to boot.
https://www.ubuntubuzz.com/2021/04/how- ... -qemu.html

[wiak]

Following my research on Plan 9 file sharing in qemu a week or so ago, I will now briefly provide you with a little bit qemu file sharing between host and guest 'magic'. I was so excited when I first found this and it proved to work (took me a while to piece it altogether and make it work the first time though).
DISCLAIMER: Obviously the following very powerful file sharing technology can be very dangerous depending what folders you share, but then again running as root user is dangerous in that sense anyway. Handle with care and at your own risk.

Once again, for convenience cutting and pasting below commands, it is handy to start a browser in your VM once it is booted so you can read this post and cut and post from it into your guest VM.

1. Prior to starting your virtual machine load the module 9p and dependencies on your host machine using terminal command:

Code: Select all

modprobe 9p

2. Let's say for argument you are about to boot a cdrom in qemu by going to the directory the cdrom is in. At the end of the qemu command you use, put a space followed by a \ and that lets you add another line of options. Add the following:

Code: Select all

-fsdev local,security_model=mapped,id=fsdev-fs0,multidevs=remap,path=. -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=fs0

Note the path=. above. That 'dot' after the equals sign means you are going to share the 'current directory' between the host and the guest VM. But understand that you can use any path=<PATH> in practice I think.

3. Once VM is booted. In that guest open a terminal and create a mount point for the shared directory as follows:

Code: Select all

mkdir /mnt/inst  # you could really call the mount point directory anything

4. Finally, you should be able to mount the shared directory in your guest VM using guest command:

Code: Select all

mount -t 9p -o trans=virtio fs0 /mnt/inst -oversion=9p2000.L,posixacl,msize=5000000,cache=mmap

In your guest VM you should now be able to view the host files inside (from where you started) inside that directory /mnt/inst
Furthermore you can use the files from there and also put new files in there if you want which will immediately also be on the host computer. i.e. You can share in both directions. So put away your ftp server clumsy techniques, and so on, this method may (at times) prove better for you.

NOTE: I don't know how 'secure' this Plan 9 file sharing method is when running qemu as root user. The method does however also work if you start your virtual machine as a normal user (though you'd have to be root user in the virtual machine guest to do the command needed there (one way being to first run the command "sudo bash" inside the virtual machine guest, assuming you weren't already root user and sudo is available for whoever you are there...). Apparently the methodology is pretty secure in that situation, but who cares if it works anyway eh? NOTE2: I haven't actually tried it yet with KLV as the host; I've only tried it with Zorin lite OS host and KLV VM guest, but I hope it will work fine with KLV host too.

EDIT: Okay, just confirmed that above also worked using KLV host with KLV guest.

[wiak]

I discovered another way of getting raw access to a drive on my laptop, but I really don't know the details of what its bits and pieces mean, or if it is dangerous to use in any way, but I'll post the extra segment I used in my qemu line to give me that access. It appears to end up using /dev/vda; found I can even mount that again with wd_mount vda, though no real reason to do that and it isn't required here). Note, this has nothing to do with Plan 9 (9p) method:

Just added this extra bit:

Code: Select all

-drive file=/dev/nvme0n1p6,format=raw,if=virtio

EDIT2: NOTE - I am finding this method quite flaky - not reliable for 2-way file sharing in my tests. Kind of works but some odd results sending files back to host and not appearing to get there - more testing required. Maybe it is okay, but USE WITH CARE... The above Plan9 (9p) method seems reliable thus far though.

/dev/nvme0n1p6 is one of the partitions on my SSD nvme drive that stores my Zorin lit OS full installation. Obviously you would need to change that to /dev/whatever to match your system (e.g. /dev/sda3 or whatever)...

On my system, using KLV-AIredale as a host and booting a guest KLV-Airedale in Qemu, that extra part above added to my qemu boot line had the effect that when I opened the guest VM thunar I could see and access read/write my Zorin full install /dev/nvme0n1p6 partition (it was in the thunar side panel list of partitions that could be mounted/unmounted).

The reason I stumbled on this method is that I'm trying to frugal mount my full installed Zorin lite OS, via qemu, with KLV-Airedale host system using the magic FirstRib generic initrd.gz (specially modified to contain boot modules for Zorin lite OS); I already know I can do this on my physical machine by simply making a new directory, say FR_zorin, on the / of my partition /dev/nvme0n1p6 and then 'moving' the whole of / (except that FR_zorin empty directory) into FR_zorin. That is a super quick operation since no actual physical move of bytes takes place since just a 'move' on same physical partition). I can then boot that FR_zorin, via the zorin vmlinuz and FR initrd...

Since I'm in KLV-Airedale host, it suits me to also be able to run my Zorin lite full install distro as a guest virtual machine - hence my quickly scripting it using FR initrd into a FR-pseudo-full install type of setup... Wonderful really.

EDIT:
As for the 'magic'. It was in fact forum member @Duprate that called FR initrd a 'magic' initrd (he seems to use an old version of it a lot to boot all sorts of Puppy and Dog systems as a way of avoiding aufs); previous weedogit, now firstribit, script uses it to boot many a distrowatch-described mainline distro as a frugal install; I just borrowing his term 'magic', since the results of using it do sometimes seem like magic (even for me - especially this booting of full installed Zorin directory - albeit via that one move operation (later I just move it back out of FR_zorin subdir when wanting to reboot Zorin OS as normal full install - takes milliseconds only).
The truth is, it isn't difficult to boot a Linux system if you understand how it all fits together. As long as all the exact needed parts are in their exact correct places, a boot will be successful. A failed boot is simply something out of place (e.g. even a missing symlink to correct switch_root init script). Computers are perfectly fussy - one smallest slip and boot generally will fail. It is like a jigsaw where every piece has to be exactly correct and fit perfectly, then everything works no matter how you achieve the exact jigsaw pattern.

I was taught, when I once worked in a research group, that I should try and find a generic theory rather than just a one-off special case proof/example. Hence, when FR initrd was designed I purposively tried to make it generic, so could be used with various/most-any root filesystem, of any distro, and that it could use a mix of either or both sfs or normal directories for its addon layers and not have a limited number of fixed order layers (in practice it is limited to 99 layers, but other factors limit what is reasonable there and a one or two line simple init change can make it 999 layers!)..

So the the above 'make full install of Zorin" into a FR initrd frugal install, simply uses that generic flexibility: the overlayfs simply arranges all the layers (the uncompressed Zorin directory being one of them) in such a way that the final jigsaw is complete and correct, and in that state it is thus not magic at all that the overlay can be booted successfully - that was an intentional part of the philosophy behind FR initrd design; it wasn't just thrown together to allow one specific root filesystem assembly to work (which is the case with most all other distro initrd designs), it was designed as a, reasonably small and flexible/easy-to-modify, assemble-jigsaw generic tool to boot most anything - so the results sometimes seem like 'magic'.

[wiak]

hahaha... so I'm sure Plan 9 (9p) qemu file sharing between host and guest is probably safe. Not so sure about that other more direct -drive method, though maybe fine if careful... I'm not...!
So using -drive method in experiments to Qemu my underlying host main Zorin full install, using KLV-Airedale as host machine, I corrupted my Zorin full install and failed to get it to boot normally again... sigh (that's supposed to be used by me for family business use only, but I couldn't resist the 'experiment').

However, I don't know why people imagine it is difficult to re-install a full installed Linux. I just did it... didn't take long. Have a list of apps I wanted to then re-install in my cherrytree notebook. Did that, didn't take long. I even unsquashed 10gtkdialog sfs from KLV-Airedale and simply transplanted the utilities there to my new installed Zorin /usr/local/bin and so on. Hence my Zorin full install system is fully back to normal and probably benefited from the re-install (lots of rubbish I'd installed now gone).

Only issue I have with Zorin is that it is FocalFossa based, so apps a bit old in the tooth. I tend to seek out PPA's with up-to-date versions, but main issue is that I don't like using Firefox (Zorin supplies) but instead want Chromium. Alas, Ubuntu official only now supports Chromium as snaps, and I object to snapd and so on, hence another PPA search. Last time I went for Ungoogled-Chromium as an AppImage, but that had a problem for me: Google gmail worked fine, but Google Drive wouldn't let me download - that facility is essential here, so Ungoogled had to go. Instead I'm using PPA Chromium from here:

https://launchpad.net/~savoury1/+archiv ... u/chromium

Current version: 109.0.5414.74

Seems fine. I also always install Chromium in KLV-Airedale, but that's easier since Void Linux xbps provides a good Chromium package.

[rockedge]

I just added a collection of template files for creating scripts, documents, ect... with right-click actions. I downloaded a collection to see some examples and they work nicely.

Placed the files in /root/Templates

[Sofiya]

I just added a collection of template files for creating scripts, documents, ect... with right-click actions. I downloaded a collection to see some examples and they work nicely.

Placed the files in /root/Templates

still to be added

New desktop.desktop

Code: Select all

[Desktop Entry]
Encoding=UTF-8
Type=Application
Name=
Exec=
Icon=
Comment=
Categories=

[wiak]

Finally, seem to have sorted out the grub config errors I made for KLV-Airedale rc8. It was very difficult to get this right, and so many modes to test, so no absolute guarantee, but these are for rc9 release when it comes. Please do not modify their contents, but if you see something wrong let me know for checking. Like I say this is not easy to get correct since some of the entries rely on rarely used flexibility of FirstRib initrd (so rarely used thus far that even I get it wrong...).

@rockedge:
Please therefore find attached all the boot/grub/ configs needed for when you release rc9.

In summary, all of Ventoy, SG2D, and Qemu can use save persistence to a partition labelled Persistence and puts it in directory Sessions.

Ventoy can also put save persistence onto its own bootfrom media as long as the Ventoy main data disk is Linux formatted and given label 'Ventoy' (again savefolders get stored in a Sessions directory there too).
Similarly for SG2D, but the SG2D data disk needs to be Linux formatted and given label 'SG2D'
and similarly for QEMU, qcow2 hard disk image, which needs to be Linux formatted and given label 'QEMU'
Note that there are other provided modes that do not need the Ventoy, SG2D, or QEMU disks labelled in that way (for example, if you choose instead to store savefolder on any partition elsewhere, anywhere attached to your system, named 'Persistence').

My brain is near evaporated now - very frazzled, so only lots of mode testing by others will reveal any errors I may have made still. However, before reporting 'failed boot' do please study what is required in terms of partition labels and so on for many of these offered modes to work in the first case. False negatives and positives in reports can waste a lot of time tracking down user config mistakes. Having said that, I certainly do make grub config mistakes in the isos (several such made by me in rc8 release grub configs as it turned out...).

[rockedge]

@wiak we have rc9 ready for download. So far tests are successful

[rockedge]

@wiak I tried out what would happen if I labelled the QEMU qcow2 HDD something like klvsys instead of QEMU and found out that the stanza's I tried will work when booting from ISO. Also created the directory /mnt/sda1/Sessions/KLV-Airedale-rc9 automatically.

With the qcow2 HDD frugal installed KLV's and booting from the HDD the stanza's I am using incorporate LABEL in the w_bootfrom= kernel parameter string.

[wiak]

@wiak I tried out what would happen if I labelled the QEMU qcow2 HDD something like klvsys instead of QEMU and found out that the stanza's I tried will work when booting from ISO. Also created the directory /mnt/sda1/Sessions/KLV-Airedale-rc9 automatically.

With the qcow2 HDD frugal installed KLV's and booting from the HDD the stanza's I am using incorporate LABEL in the w_bootfrom= kernel parameter string.

Yes, I just used LABEL of QEMU as something generic since for iso boot you can't change the iso boot/grub/menu.lst without remaking the iso...
But normal frugal install on Qemu HDD image is a different matter of course, since you have read/write access to that image so can use any label you prefer for the partition (and associate the grub config via LABEL accordingly).

[wiak]

I'll try and get round to scripting the KLU-jam build soonish. I could do so tomorrow in less than an hour(!), but some other stuff to do that I want for rc2 release, as I've outlined in KLU-jam thread. The KLU-jam build method lies somewhere between a build_firstrib_rootfs method and a firstribit (weedogit) method. That's one of the easy aspects of building a FR-based distro, it is conceptually pretty simply so can use alternative methodologies to achieve the same end result.

As you know, @rockedge, the FirstRib 'pseudo-full-install' boot trick provides developers with a very reliable mechanism for instantly/reliably remastering the system. And as an alternative a user can use the provided mount_chroot and umount_chroot scripts to modify the root filesystem from a terminal on some other booted host system. And of course, the majority of features provided by the FR initrd can be altered simply by editing the external w_init text file, and if modules needed to be added inside the skeleton initrd.gz, that can be auto-uncompressed using the provided utility modify_initrd_gz.sh. It all becomes second nature once you've practiced a bit with it all. Weedogit was simply a scripted version of manually using such utility 'tricks'.

Some people get confused if there is more than one way of doing something I suppose, but in practice, once the FirstRib build basics are understood, it becomes pretty natural to do things in whatever way suits a given purpose best. I'm biased of course, but I'd say it was a very easy to use build system - makes a nice hobby and Linux distro learning pursuit - and with very easy/shallow learning curve.

Using firstrib to build a distro really is a bit like using LEGO. That's how I was able to build rc1 of KLU-jam in just one day... and it is almost complete for the purpose I intended it (rc2 will pretty much finish it off) and a separate KLU-jamCE can be made to include whatever singing-all-dancing variant the user wants built on top of base KLU-jam. Making an alternative Wayland/Pipewire variant is pretty much trivial to do also; a day job, though polishing any distro to exactly how you want it can take as long as you need to achieve your personal dream configuration!

So if anyone who wanted to build a distro of their own found other mechanisms too restrictive or difficult, then try FirstRib build system. It is really easy to craft your own distro with it in whatever shape and form you wish - you don't even need to be good at shell scripting - that's not what it is about! Rather, FirstRib is about learning how distros basically hang together, but without needing to become a guru at that or programming - upstream does most of the work for you in the end, be that Ubuntu, or Arch Linux, or Void Linux, or whoever provides the repository of downloadable packages, which generally already include their own necessary configuration anyway. For example, when you first build a system based on XFCE, you don't need to configure XFCE - the package has that already done for you. Later on, through familiarity, of course, you can tweak that to your heart's content, but adding only facilities you want, and hence produce customised efficient distros with full frugal install flexibility. Simple.

Yes, the internals of FR initrd are pretty complex in terms of code logic (but not large in code length). However, there is no need to understand its internal coding at all (just learn how to use its facilities...). The FR initrd/init code is already written (and well tested/maintained), so just like a generic LEGO block that is used as the heart of all FR-based distro creations; that's the key to the build system simplicity, efficiency, and flexibility. Result is very little pain, yet lots of gain, and fast production of reliable, solid, multi-distro-type customised variants. KLU-jam could have been built at any time since Jammy was released, just as quickly as it now has been.

Furthermore, being true Ubuntu root filesystem under the hood, every aspect of it can be kept updated simply via apt (since whole system gets updated via apt, not just the installed applications) so it has several solid years of useful lifetime ahead of it whether or not FR initrd itself receives any further development/improvement. However, FR initrd pretty much does all that is required of it anyway - existing version should work for many years without 'needing' any alteration really (actually older versions still work per their design features too - no reason why they wouldn't). Point is that these distro creations are very solid and stable - users don't need to worry about them going out of date or being difficult or near-impossible to upgrade or maintain or needing a new kernel swapped in (which can be a Puppy huge kernel, but doesn't need to be). Same also applies to KLV-Airedale of course, which uses a different, but also reliable package manager that doesn't just allow update of installed applications, but also keeps whole system up to date. That's the overriding reason that these distros can be relied on as stable by design; because the end result is a full-on upsteam-repo-based root filesystem - nothing pseudo about it, but customised (sometimes Puppy-sized) variants of these upstream distros that allows all the frugal install flexibility and facilities we have come to love (but full multi-user capable too). My view in producing it was: why struggle?

Oh... and because I designed the build system to have a build plugin capability, the end result is that I don't even usually need to do most of the work! Rockedge does most all of that (well - and major contibutions by fredx181 of the DebianDogs) for KLV-Airedale via the plugin he continually adds to!... and I benefit from the result and can take the code added and put it into my own FR designs later!!! I do try to help though, particularly with FR initrd related matters.

[rockedge]

@wiak To mention longevity, I booted into a very early version which the PLUG file had developed into around November 2019 and early 2020.

I called it firstrib-s207-A and it is built with a Void Linux kernel instead of using a Puppy Linux huge kernel which I had leaned on with the starting versions of FirstRib and moving from chroot'ing the firstrib_rootfs in a shell only environment to adding JWM and Rox and Xorg and then moving to producing ISO's that can boot a FirstRib. I installed Zoneminder on it and shortly thereafter it grew into WeeDog's and the build script produced distro's were getting more and more complex quickly because of the ease of editing the PLUG file recipes to build an OS very quickly. Since sometime in 2020, was the last time I started firstrib-s207-A.

So I decided to boot it and see what would happen if I ran xbps-install -Suy right away. It worked and is running. Even was able to git pull the Zoneminder source code from GitHub and compile the latest greatest ZM from the development master branch. Took a few more minutes than a "usual" system upgrade.

Pretty amazing how well it all still works. firstrib-s207-A is outfitted with a JWM-Rox desktop. Really minimal configuration and mostly at default settings. This is the system that showed and convinced me how powerful the build system is. And what a FR Void Linux based distro can do in efficiency and speed plus runs almost every application I've had the time to try on it.

So made in 2020 and finally updated it in 2023. Worked right away so I am convinvced these distro's can be used for extended period of time and stay in fast lane.

[wiak]

I've been on a KL distro production blast for some while now, but probably really is time to stop burning so much midnight oil. Good contributions available for users from Sofiya, and the usual good support from fredx181 and rockedge, and Clarity amongst others, but also the usual not much in the way of wider audience feedback. Maybe just not much of a wide audience, which is fine since less pressure on maintenance or further improvement on my part. I kind of feel I have what I want for now. Any extra work I do on any of these likely to be minor maintenance only rather than support for others trying them.

My only regret is that no one took up the dev lead for KLV-OT2 since it already had a complete working build plugin and thus pretty easy to develop and maintain from there, but that's fine - what is out there works for me and some others okay for now, including for 'some' with Ventoy and/or Qemu as well as for flexible frugal save on demand type installations. Anyway, with its available build plugin published it remains always there to develop further for anyone who can be bothered - doesn't need 'guru' skills, just some famiarity (basic) of shell script commandlines - expertise grows with time making or enhancing such plugins as I'm sure rockedge could confirm.

Nevertheless, I do have one more release to finalise and also, over time and in the background, will be consolidating my KLU-jam builds since I'm already forgetting some of the steps I used to produce them (i.e. I'll be completing build script for that eventually, I hope...). My birthday draws close - makes me wonder why I'm still doing this, or at least why so much still.

[rockedge]

@wiak talking about birthdays......mine is in 19 days. I feel like KLV-Airedale is in a good stable place and F96-CE is very close to officially ready and once that's all in the right places maybe I will have time to fix/update several websites that I've just let run for several years with just the minimum technical updates/upgrades. There are still some pages in the oldforum that will not display because of junk characters and garbage html tags that did not make it through the database conversion from phpBB2+ to phpBB3+ that I could manually track down and fix.

I need to spend time on finishing the KLV-Airedale PLUG and some variants of that. I have to fix some plumbing in the house. Fallen trees need to be dealt with and the driveway needs to be torn out regraded and repaved.

Yet here I am considering what direction to take KLU-jam because it's so cool.

Have not even really begun to explore all of the potential of the FirstRib system and I don't want to lose momentum.......

I am a Pisces the 12th and final sign of the zodiac calendar.

feature_pisces.png (108.88 KiB) Viewed 8059 times

[tosim]

@rockedge Let me offer up an early HAPPY BIRTHDAY to you!

[wiak]

I have to fix some plumbing in the house. Fallen trees need to be dealt with and the driveway needs to be torn out regraded and repaved.

Such matters are really what I'm constantly putting off till 'tomorrow' what I should be doing today. I'm on the cusp between Pisces and Aquarius, so depends on the horoscope read which I'm classed in: 19 Feb for me.

[wiak]

Progress report on attempt to improve FR initrd slightly:

First attempt worked for normal frugal install RAM0 boot only. Alas, was a disastrous fail with all other modes! Flipping two solid days work had to be thrown in the bucket!

Took a few good bits out of that code attempt though, and thus far this second attempt is working in some early tests. Problem is the amount of modes/mechanisms that need tested - worst is testing anything to do with any kind of iso-booting since I have to keep rebuilding the 07 sfs, initrd, and the iso itself pretty much everytime something fails with that. I think I build the iso twenty times at least yesterday...

However, just before bed last night Ventoy with Persistence worked with new FR initrd, so this morning I was ambitious and tried a mode I haven't used for probably at least a year, so didn't expect it to work. I refer to kernel line w_altNN=..., which allows numbered addon sfs or uncompressed filesystems to be placed on different partition to the bootfrom partition and indeed anywhere on the filesystem. In fact is 'supposed' to work even if just a few of the NNaddons are placed in some other partition. Hopefully, the grub config stanza below also helps to illustrate how to use w_altNN argument. I had taken 10gtkdialogXXX.sfs and 01firmwareXXX.sfs and placed them on a different partition in a directory KLU-jamBITS:

menuentry "KLU-jam" {
insmod ext2
search --no-floppy --fs-uuid --set 7d34b88e-bc8e-4bb6-86cf-d619c3b545a9
linux /KLU-jam/vmlinuz w_bootfrom=UUID=7d34b88e-bc8e-4bb6-86cf-d619c3b545a9=/KLU-jam w_changes=LABEL=Persistence=/Sessions/KLU-jam-rc4 w_changes1=RAM2 w_altNN=UUID=424d8f42-e835-4111-9053-dd086b3d38e8=/KLU-jamBITS
initrd /KLU-jam/initrd.gz
}

And it booted fine; found the 10gtkdialog and the 01firmware. More luck than anything that initrd/init code still works after all the time that has passed without me finding time to retest that functionality until today.

So I 'think' I am getting near to publishing FR initrd ver 7.0.0 rc2 though soon as I have now said that I'll probably find some new serious error...

Obviously, last thing I want to do is recommend or publish any new FR initrd for general KL use since if faulty would break everything else for everyone else.

[wiak]

Not sure why I need to post this again, but just a reminder to anyone who doesn't yet understand what I've already said:

KLA is a fork of revamped FirstRib Arch-based Openbox/Tint2 distro, including KLV-like tiling hot-keys (as alternative to KLV, Void-Linux-based, Xfce desktop) that I'll shortly be donating for community development/modification/refinement to hopefully benefit from the existing work pioneered by KLV-Airedale. Space just being made for it - coming soon.

Starting as a near identical fork to the FirstRib version, the KLA release to this forum community opens up its development to benefit from the many utility resources KLV-Airedale has brought to the table (I have only myself had time to ensure RAM2 save2flash mode works with it). The FirstRib original is unlikely to get all of these KLV-utilities since it is for a particular business-related purpose of my own so it is also likely to diverge over time - hence my going to release this KLA fork for more general community development.

The above applies to everything I publish on this forum. As I have well-indicated before I only have one priority, in terms of anything I open-source: I maintain the FirstRib intird and the main FirstRib build system. Much though I am happy to see all community development efforts relating to these KL distros I have contributioned for forum member use, please don't be offended that I don't always or even often include any of the KL-related contributions of others in my own base release offerings. Not only can I unfortunately not myself publish work that includes trademark icons or variations of these, no matter how good I think some of that work is, I am simply not willing/able-timewise to take on such review or additional work.

I do comment sometimes when I can and specially when no tests are needed by myself, which I don't find time to do anyway. Indeed, I purposively asked for someone to take over main KLA-OT2 dev thread and related iso-production, for example, since longer term I can only take responsibility for maintaining and developing the FR initrd and the related FR build system. However no-one took that on.

Please do not personally insult me on the basis of my not testing or commenting about any submitted work. If the submitted work is a request for inclusion in FR initrd that would usually be a different matter - doesn't mean I don't appreciate anyone else's work and I am certainly not insulting anyone who does not comment about or use mine. This is a public forum and public criticism of my response to the contributions of others is sickening to me when all I am personally doing is producing contributions for others to freely use as and when they see fit.

[wiak]

I'm forgetting what needs done so I better do it quick as I can, best I can.

Been browsing through KL threads trying to remind myself of previously noted omissions.

Problem is so many distros to rebuild isos for, but I want to add the latest FR initrd.gz despite it being impossible for me to know if I have broken it in any way. Has too many options for me to test them all thoroughly (or even at all sometimes). Might be lucky. Was going to just release one distro using it, but I want to get this finished since tired of doing this now.

So tomorrow I'll try to add new FR initrd.gz to each of the following and make temporary pseudo full installs of them for fixing up, and hopefully remember one or two of the items I forgot to install last time round, but expect omissions since my brain has been saturated and frazzled for probably a week or two now:

KLA-OT2base
KLA-XFCEbase
KLU-jam
KLU-jamFE

So hopefully new version release isos will appear for each of these in next few days (disasters generally happen on route despite my desperation for no such issues). I really hope I don't make any mistakes because I can't be bothered doing more just now and just want to switch off actually. If it wasn't for the new initrd I'd probably just leave well alone - but I will leave well alone once all seem to be working thereafter.

[wiak]

I'm running out of available time, sorry, Sofiya, so have to leave newer KLA-OT2 releases till later. The little time I can spare in the next few weeks for computing probably need to go in updating KLU-jam to include similar to latest KLA-XFCEbase - particularly all or most of the new little utility apps and latest initrd. I will revisit KLA-OT2 later though, as I said I would, but may take an extended while. I 'think', but can't really remember, that that last KLA-OT2 release already contained the latest initrd, despite it not actually being tested much (or perhaps enough), though it seems fine thus far.

I'm confident, by the way, @rockedge that forum interest and number of daily posts is going to increase over time because of all the KL distros, which I believe will attract participation by a wider audience.

If it doesn't, well at least we tried! Mind you, we should probably publish their existence more widely since only the current forum members/visitors know they exist - wider potential audience no doubt think this forum is only about one distro so if they are not interested in that any more then of course they have no reason to visit.

I have a bit of checking to do to see if the initrd-latest on owncloud really is the latest and similarly to make sure build_firstrib_rootfs.sh and so on build scripts have all the correct versions available so works correctly still. That much I'll try and check quickly - the new version iso releases not so quick unfortunately. I'm looking forward to getting all that out of the way so I can also get round to publishing new version of firstribit (old weedogit) system, which will this time include save2flash w_changes=RAM2 capability for these big upstream distros.

Latest KLV-Airedale looking very solid and useful - should be named 1.0 final or similar soon I'd think.

[wiak]

Code: Select all

# Prior to switch_root need to --move main mounts to new rootfs merged:
mkdir -p merged/mnt/${bootpartition} merged${layers_base}  merged/usr/lib/modules # merged${layers_base}/RAM merged${layers_base}/uc_ro
mountpoint -q /mnt/${bootpartition} && mount --move /mnt/${bootpartition} merged/mnt/${bootpartition}

Above is basically the code we need to revert to for now in the initrd. It may not be enough and may cause other issues, but probably safer than current IMO without further thought. As I said, too late here now for me to look into this further tonight. Truth is I really don't have time to do computing these days. but I'll try and fix up 'latest' initrd but with that reverted code - will have to do for now till I can experiment further with it or someone else does.

I'm actually somewhat surprised the umount proves possible - I imagined the filesystem would be busy and not allow that, but it does...
Certainly, with w_changes=RAM2 mode, the session work is being done in RAM only, but the external save folder is mounted so thought that would prevent its underlying partition being umounted. Anyway, I was wrong for some reason or other about that.

As I said back at the time I changed the above...

@wiak I just put this in w_init in KLV-Airedale-rc10 which is equipped with the Void Linux kernel 6.1.8. So far works as expected!

That's fine. Hopefully it is fine. Any changes to initrd boot could have side-effects I haven't thought of, but I have a feeling it will be fine and used in next initrd-latest.gz release (after some further testing). Using 'fine' three times shows optimism!!!
Since KLU-jam is new and under test anyway, I will include the same in rc3 version of that too.

So turns out it isn't fine... Various isos need re-made unfortunately and maybe need to find a more robust solution.

[rockedge]

@wiak For now I am going to replace the current w_init with the one from rc9 that is from prior to the changes to the initrd.gz and w_init from rc11 upwards.

By using the older w_init the mechanism should revert to the original one with the w_init overriding the initrd.gz

[rockedge]

@wiak, @fredx181 I made an rc13 which is identical to rc12 but with the w_init from rc8.

I checked the w_init across several different rcXX versions using Beediff and I feel confident it's returned to the right version.

So far tests on QEMU and bare metal have been quick and smooth booting. I actually work better with this arrangement. Perhaps I am more used to going to the system root partition the way it was in all earlier KLV's.

I'll insert a modified initrd.gz eventually to reverse the mechanism. So the w_init and initrd.gz are identical again and new modifications can be tested by making changes to the w_init again.

KLV-Airedale-rc13 is uploaded an can tested! I will repackge it once I've changed the initrd.gz