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.

[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.

[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=

[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 11821 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]

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

[fredx181]

@wiak @rockedge Yes, for now good to revert back to earlier w_init, indeed weird that it does force unmount the "bootfrom" partition in rc-12, in DebianDog (with XFCE) it has the "bootfrom" drive icon on Desktop and Thunar, but trying to unmount it by right-click "unmount" it refuses (says "busy"), but not very much comparable as it's using pup-volume-monitor instead of gvfs.
To get the proper symlink /mnt/home, the swapper.sh script needs to be changed to earlier version too:

Code: Select all

#!/bin/sh
# utility by fredx181 Jan2022
#
# revison 19Feb2022 by fredx181
#### Load swap ####
 echo "LOAD SWAP"
  for ONESWAP in `fdisk -l | grep ' Linux swap' | cut -f 1 -d ' ' | tr '\n' ' '`
  do
    echo -n "Loading swap partition $ONESWAP..." >/dev/console
    swapon $ONESWAP
  done
#########################

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

[rockedge]

@wiak @fredx181

I put both fixes into KLV-Airedale-rc13 that is repackaged and uploaded, available for testing!

[fredx181]

I put both fixes into KLV-Airedale-rc13 that is repackaged and uploaded, available for testing!

https://rockedge.org/kernels/data/ISO/K ... e-rc13.iso

EDIT: Tested RC13, changes are OK. here's simple script to show the "bootfrom" drive icon on Desktop and in Thunar.

Code: Select all

#!/bin/bash
MNTHOME=$(mount | grep "/mnt/layers/merged/mnt" |  cut -d'/' -f3 | cut -d' ' -f1)
mkdir -p /media/$MNTHOME
mount /dev/$MNTHOME /media/$MNTHOME

When right-click "unmount" the icon disappears again, as how it was before running the script, that's ok IMO.

[wiak]

I think reverting will do. I installed Puppy dpup to compare and as Pupmode13 in terminal I did a umount of the bootfrom partition and that was allowed there too and thereafter save2flash wouldn't work. The gui Pmount doesn't allow the umount though, but of course Thunar with gvfs and so on can't be easily prevented anyway. So best procedure does in fact seem to be to simply make the mount point less accessible - years go by and nobody tried unmounting the underlying boot partition, so making that mount point appear on Desktop via /media/root handling turned out to be a bad idea afterall... better to hide what isn't wanted!

Save2flash doesn't work in KLV (or in Puppy) after the unmount. However, what I found in experiments to be very dangerous (DO NOT DO THIS) is to remount and try save2flash again.... Then save2flash messed up partition I was in... of course umount the bootfrom partition would have messed up overlayfs view of the layer structure and changing anything involved in layers is undefined in overlayfs usage (according to kernel docs) so is more than ill-advised.

LATER today, I'll revisit this, because other changes in very latest initrd I want to stay so I'll publish fixed latest once I get round to that. I have to change my other KL distro releases anyway to include fixed initrd. I'm not so bothered having bootfrom dir appearing in Thunar via /media/root since I'm used to opening it from /mnt location, but I suppose some may prefer that. Every time a new mount is made a little bit extra RAM is used though.

[wiak]

@rockedge, @fredx181

NEW initrd-latest.gz fetch script uploaded

Download get_WDLskelinitrd_latest.sh.tar from https://firstrib.rockedge.org/viewtopic.php?p=355#p355

Remove dummy tar and chmod +x

Running that script will fetch all of: initrd-latest.gz, w_init-latest, and modify_initrd_gz.sh

Latest is version 7.0.1 rc1

I will be using this initrd.gz version in all my own KL releases (once I have time to rebuild their isos...).

Newly made so needs testing and could, as always, be side-effects I didn't think of... but hopefully not... Been using a similar initrd.gz for a while, only a few changes from what I had under previouos dev test under name ver 700rc2.

IMPORTANT:

1. This is skeleton initrd-latest.gz so if not using huge kernel you need to put any needed initrd modules into its usr/lib/modules directory.

2. You need to remove the "/mnt/home" symlink code from previous KLV release /root/my-applications/bin/swapper.sh

Instead, initrd-latest.gz (actually it is the new w_init-latest) itself makes the link reliably (easy in there since bootpartition is known by the initrd/w_init code).

3. No mount tricks are necessary to put that bootfrom directory onto the Desktop; instead simply copy the /mnt/home symlink and paste it onto the Desktop (prior to constructing the iso)- you can rename Desktop copy of the link mnthome or whatever you want. Similarly, for Thunar, simply drag it across into Thunar bookmarks. Done that way, no issue with umount can arise.

[wiak]

Just a note to myself at least.

Though I'm taking a break from further development work at present I note that the likes of run-as-spot is not necessarily most appropriate form of such script.

In line with something I mentioned elsewhere, when you are usually booting between several distros it is normal that the first regular user is known to Linux as UID 1000. So for Puppy Linux distros, user spot is that user who has UID 1000. But on my Zorin lite installation, user wiak is my first added user and so has that UID 1000. On my KL distros user firstrib has UID 1000. The point is that UID is what is used by Linux itself (not the human user name) to know what permissions to any resource have been assigned. In forum distros what we generally therefore want is to run the likes of Chromium as user who has UID 1000, so anything saved from Chromium will be accessible (correct permissions) even when booting up different distro.

i.e. the run-as-spot type of script would best be modified to run as user who has UID 1000 (whoever that turns out to be...). So need to modify that script and rename it to say run-as-1000 (rather than having a run-as-spot, run-as-firstrib, run-as-whoever script and so on).

[rockedge]

We have a run-as-user script from the period early in Kennel Linux development that might be of interest. @fredx181 I think supplied it which I later modified to be run-as-spot and run-as-weedog.

I have not looked at it yet but the thought is it might be a script to quickly modify and try out the idea @wiak has.

[rockedge]

@wiak I had to fix up the FRmake_initrd.sh that I have by replacing the download block in the code.

From this :

Code: Select all

_get_FR_initrd (){
  wget -c --no-check-certificate https://owncloud.rockedge.org/index.php/s/HRZhsnouSm3Gpf3/download -O modify_initrd_gz.sh && chmod +x modify_initrd_gz.sh
  wget -c --no-check-certificate https://owncloud.rockedge.org/index.php/s/CXixDo8Dd2rtxSQ/download -O initrd-latest.gz
  wget -c --no-check-certificate https://owncloud.rockedge.org/index.php/s/8aFjxy5QrjfyI8o/download -O w_init
}

To this :

Code: Select all

_get_FR_initrd (){
wget -c https://owncloud.rockedge.org/index.php/s/HRZhsnouSm3Gpf3/download -O modify_initrd_gz.sh && chmod +x modify_initrd_gz.sh
wget -c https://owncloud.rockedge.org/index.php/s/BQm758UXWSJ2O1k/download -O initrd-latest.gz
wget -c https://owncloud.rockedge.org/index.php/s/bolhoXwFylKi335/download -O w_init-latest
}

Now again producing Void Kernels components for KLV!!!