KLV-Airedale-rc6.1 with Void Linux Kernel is Available!

[rockedge]

KLV-Airedale-rc6.1
Kennel Linux Void Airedale Release Candidate 6.1 755 MiB download size ↓
KLV-Airedale-rc6.1
SHA1-MD5.txt

Improved initrd.qz including support for SD cards.

Routine system update/upgrade. And wallpapers from @Sofiya are included, replacing some of the stock xfce4 backgrounds.

@wiak has done work improving the boot system menus and further improvement to the initrd.gz boot mechanisms :

The iso config file boot/grub/menu.lst is used to boot from cdrom using that internal to iso provided menu.lst (i.e. he currently uses grub4dos for that purpose).
The iso config file boot/grub/loopback.cfg is used (per usual) to provide the boot menu for SG2D
The iso config file boot/grub/grub.cfg is used by Ventoy (but included no Ventoy-compatible entries until my alterations below)

I have made some modifications to all of the above (though have left previous entries in place for later experimentation and possible modification or deletion).
In particular I have provided the ability when booting via SG2D or Ventoy of using the FR modes:

a. RAM0 for session changes in RAM only (i.e. no save persistence)
b. RAM2 save on demand mode back to upper_changes folder (or ucimg savefile) in same directory iso is stored (or in subdirectory if symlink manually made to iso).
c. RAM2 save on demand mode back to upper_changes folder in, Clarity suggested, partition with LABEL 'Persistence' and directory 'Sessions'
d. Direct save (not in RAM) back to upper_changes folder (or ucimg savefile) in same directory iso is stored (or in subdirectory if symlink manually made to iso).
e. Direct save (not in RAM) back to upper_changes folder in, Clarity suggested, partition with LABEL 'Persistence' and directory 'Sessions'

No editing of the presented SG2D or Ventoy boot menus will be required to achieve these most useful FR initrd modes. User just needs to put the KLV iso in BOOTISOS (or wherever it is put usually) and boot...

starting of the pulseaudio system for any user that is logged in has been fixed and improved. Thanks wiak, Sofiya and fredx181 for the exact steps.

Upgraded to a new version of @fredx181 's save2flash, and set LANG=en_US.UTF-8 in /etc/environment as default localization.

Thanks to @Sofiya for the poorercputemp and Display Control packages that also have been added to desktop.

• Grub4Dos is now included in the System menu. Making KLV-Airedale capable of setting up a boot-able device using GParted and Grub4Dos.

• CUPS starting as a service has been added and is working thanks to @rcrsn51 spotting missing components!

This is constructed from KLV-Airedale-beta27->rc1->rc2->rc3->rc4->rc4.1 and is equipped with a Void Linux kernel version 6.0.12_1 SMP PREEMPT_DYNAMIC constructed with @wiak 's scripts that will extract the Void Linux kernel for KLV. Also has had a system wide upgrade. Uses an initrd.gz based on the FirstRib skeleton initrd.gz constructed by the kernel/module creation script. Firmware SFS is from a woof-CE kernel-kit built huge 6.0.0-1 kernel.

KLV-Airedale-rc5 is just as at home on FAT32, NTFS prtitions as it is running from ext2/3/4 formatted partitions.

Also included is wiak's generate a set of boot stanzas script. fredx181's mksplash has a menu entry and the remaster script is installed.

With the addition of a xfce4 desktop tiling configuration. A tip from wiak for configuring Tiling windows done with the Super (Windows) key and an up, down, left, right, home, pgup, pgdown or end key.

gxmessage in the default rootfs.

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

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

• included htop, Grub4Dos, CUPS

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

• Auto login cleaned up.

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

• replaced loop.cfg to the most recent modifications.

• Debian kernel 6.0.0-3-KLV SMP PREEMPT DYNAMIC is used.

• added gtkhash

Plus the other important improvements contributed by the KLV team.

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

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

• mime-add-1.0_0.noarch.xbps

• edit-sfs-1.0_0.noarch.xbps

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

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

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

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

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

[wiak]

@rockedge Did you remember to rename KLV-Airedale-rc6 to KLV-Airedale-rc6.1 in the grub.cfg or booting from Ventoy won't work. Alternatively, the iso needs renamed back to KLV-Airedale-rc6.iso so that Ventoy will find it via previous grub.cfg.
EDIT: Well, when I say Ventoy won't find it, Ventoy itself will find the iso named KLV-Airedale-rc6.1.iso and put it in boot menu, but thereafter the iso boot/grub/grub.cfg takes over and will fail to boot (or boot wrong iso: any in same location named rc6 rather than rc6.1)
EDIT2: By the way, I think grub2 allows use of variables, so could probably have variable near top of grub2 to hold iso name. Then you would just need to change that rather than search/replace throughout the grub.cfg file. I haven't tried using a grub2 variable myself so I may be wrong about the possibility, but seems likely it would allow that.

[rockedge]

@wiak I just adjusted the names and tested in QEMU both before I changed them and after. In both cases KLV booted fine in a QEMU virtual machine.

The adjusted ISO is ready for download.

[Clarity]

downloading now......QEMU booted without issue to desktop.

@rockedge or other members, could you share your QEMU stanza. Want to compare. On this PC, I am using this

Code: Select all

qemu-system-x86_64 -enable-kvm -m 2G -vga cirrus -smp 2 -device AC97 -boot d -cdrom KLV-Airedale-rc6.1.iso

Do you have audio?

KLV Pristine with Cirrus VGA.jpg (21.98 KiB) Viewed 5480 times

[Clarity]

I will test the Ventoy "boots" when I return...

[rockedge]

@Clarity Yes I have audio. But I will test on some other machines.

Code: Select all

qemu-system-x86_64  -smp 4 -soundhw ac97 -machine accel=kvm -m 4096 -full-screen -cdrom "/mnt/home/KLV-Airedale-rc6.1.iso" -hda "/root/.aqemu/KLV_Airedale_rc6.1_HDA.img" -boot once=d,menu=off -net nic -net user -rtc base=localtime -name "KLV-Airedale-rc6.1" -cpu host -vnc 192.168.254.13:0 $*

[wiak]

@wiak I just adjusted the names and tested in QEMU both before I changed them and after. In both cases KLV booted fine in a QEMU virtual machine.

The adjusted ISO is ready for download.

Ventoy needs that boot/grub/grub.conf to name the iso to be booted.

qemu is different since you name the iso exactly at time you start qemu, but Ventory is started by file inside the iso (being that grub.cfg).

But if user changes name locally to whatever grub.cfg expects Ventoy should find it and work then, but not of course if the file name is not what grub.cfg says it is. Just going out so can't test just now.

[Clarity]

I am back and have tested the following via QEMU
Booting the iso file directly from

• system's HDD drive

• SG2D USB's BootISOS folder

• Ventoy USB's BootISOS folder using its SG2D ISO file

The above tests Boot successfully to desktop operations without any issues. Repeating: KVM works fine for booting the ISO files using the above boot scenarios. BUT ...

YET, Attempts to boot the KLV vRC6.1 ISO DIRECTLY from the Ventoy USB'S Menu without using the SG2D ISO file results in boot-failure.

Next I will be testing and reporting on booting KLV ISO file via

• bare-metal SG2D USB

• and bare-metal Ventoy USB

[rockedge]

@Clarity which distro's ISO does Ventoy boot? I need to see the differences in the overall boot mechanism.

I don't know anyone who uses Ventoy. I still don't see any advantages at all for using it over QEMU. My setup of Ventoy uses an exFAT partition for the ISO storage. I still have not manged to get many things running on Ventoy usb drives, nothing that would make me stop and say this is the bee's knees.

[dancytron]

I have this version installed on my laptop. I upgraded from 4.1 in the worst, laziest way possible, just swapping out the files from the new ISO, booting it with the old, unupgraded changes folder, and then upgrading it. No ill effects so far and it seems to have saved all my settings.

I'm going to experiment with the remastering process when I get a chance. I had a question about the 4 .sfs files. Which ones are included in the equivalent of the dpkg database and which aren't? Is the idea that any 01Firmware*.sfs can be dropped in without regard to the package database? Anything else to know about why it is set up the way it is?

[wiak]

YET, Attempts to boot the KLV vRC6.1 ISO DIRECTLY from the Ventoy USB'S Menu without using the SG2D ISO file results in boot-failure.

Next I will be testing and reporting on booting KLV ISO file via

• bare-metal SG2D USB

• and bare-metal Ventoy USB

Clarity, as I said in my previous post you need to rename the iso back to KLV-Airedale-rc6.iso (not KLV-Airedale-rc6.1.iso) since, currently, KLV-Airedale-rc6.iso is what the internal to iso grub.cfg looks for - otherwise it is impossible for it to be booted via Ventoy. But if you simply rename it as I suggest it should boot nicely without needing SG2D at all. Qemu is a different way to boot an iso of course and useful in other ways.

[rockedge]

@wiak this is what the current grub.cfg in rc6.1 looks like ->

Code: Select all

set timeout=10

loadfont /boot/grub/font.pf2


color_normal=cyan/black
#menu_color_highlight=black/light-gray
menu_color_highlight=yellow/red
menu_color_normal=light-gray/black

# First five entries usefully work with Ventoy

menuentry "KLV-Airedale-rc6.1 (Ventoy RAM0 no persistence)" {
 linux /vmlinuz w_bootfrom=/KLV-Airedale-rc6.1.iso w_changes=RAM0 net.ifnames=0
 initrd /initrd.gz
}
  
menuentry "KLV-Airedale-rc6.1 (Ventoy RAM2 save on demand to iso folder)" {
 linux /vmlinuz w_bootfrom=/KLV-Airedale-rc6.1.iso w_changes=RAM2 net.ifnames=0
 initrd /initrd.gz
}

menuentry "KLV-Airedale-rc6.1 (Ventoy direct saves to iso folder)" {
 linux /vmlinuz w_bootfrom=/KLV-Airedale-rc6.1.iso net.ifnames=0
 initrd /initrd.gz
}

menuentry "KLV-Airedale-rc6.1 (Ventoy RAM2 save on demand to Persistence/Sessions)" {
 linux /vmlinuz w_bootfrom=/KLV-Airedale-rc6.1.iso w_changes=LABEL=Persistence=/Sessions w_changes1=RAM2 net.ifnames=0
 initrd /initrd.gz
}

menuentry "KLV-Airedale-rc6.1 (Ventoy direct saves to Persistence/Sessions)" {
 linux /vmlinuz w_bootfrom=/KLV-Airedale-rc6.1.iso w_changes=LABEL=Persistence=/Sessions net.ifnames=0
 initrd /initrd.gz
}

I am wondering now if the method used to make the ISO is at fault......

[wiak]

I had a question about the 4 .sfs files. Which ones are included in the equivalent of the dpkg database and which aren't? Is the idea that any 01Firmware*.sfs can be dropped in without regard to the package database? Anything else to know about why it is set up the way it is?

07KLVxxx.sfs is the main rootfs, which has been placed at layer 07 of the overlay. sfs files with numeric values higher than that overwrite anything in lower layers. The 00modules is bottom of all the layers and 01firmware right above it. No doubt it would have worked at higher layer than 07KLV, but better lower: one reason is that a user can unsquash 07KLV and rename it to upper_changes (with no numeric). Then when new firmware (or modules) gets added to that upper_changes it will take precedence, and if wished, the user can re-squash the whole lot back to 07KLV sfs form. You can add anything into the system anytime you feel like it - just create a new directory, give it a 2digit numeric first part of name, and anything you put in there will be layered in at the position of the 2-digit numeric you chose. For example, it might include directory structure /usr/local/bin. But of course you can manually modify upper_changes and that will appear as top layer on reboot. No rules - in that sense - up to what you want. Of course the package database changes will be stored in upper_changes. You can make rollback upper_changes directories by putting 2digit numeric in front of name and new rw upper_changes will be auto-generated on subsequent boots. But, yes, you have to be careful to keep rollbacks in sequence and none missing if you have been installing packages via package manager (xbps) since package database would end up wrote otheriwise.

Note that none of the NNsfs or NNdirname components care about any part of the file name except for the 2digits at the front. So 07KLVxxx.sfs could be renamed to 07.sfs and would still work the same. Easy to organise mix of sfs files or uncompressed directories as addon layers therefore - up to the user - 99 layers possible, or use 07KLV as uncompressed upper_changes for a kind of pseudo (almost) full install mode since whole main root filesystem then held in uncompressed read-write form so updates actually do then correctly overwrite previous files and not add bloat - remastering in that case just really becomes a matter of squashing up upper_changes back to sfs form again.

[rockedge]

@wiak What do we call a "pseudo full install" when all of the SFS files are converted to uncompressed directories as well?
So the entire system is uncompressed and in the "pseudo full install" mode.

I am going to test this on a virtual HDD on a QEMU machine

I am wondering if the mkisofs options are correct for making a boot CD-ROM that'll boot with Ventoy.

Code: Select all

mkisofs -b boot/isolinux/isolinux.bin -c boot/isolinux/boot.cat -D -l -R -v -V "KLV-Airedale" -no-emul-boot -boot-load-size 4 -boot-info-table -o "KLV-Airedale-rc6.1.iso" KLV-Airedale-rc6.1

-o filename
is the name of the file to which the iso9660 filesystem image should be written. This can be a disk file, a tape drive, or it can correspond directly to the device name of the optical disc writer. If not specified, stdout is used. Note that the output can also be a block special device for a regular disk drive, in which case the disk partition can be mounted and examined to ensure that the premastering was done correctly.

[dancytron]

I had a question about the 4 .sfs files. Which ones are included in the equivalent of the dpkg database and which aren't? Is the idea that any 01Firmware*.sfs can be dropped in without regard to the package database? Anything else to know about why it is set up the way it is?

07KLVxxx.sfs is the main rootfs, which has been placed at layer 07 of the overlay. sfs files with numeric values higher than that overwrite anything in lower layers. The 00modules is bottom of all the layers and 01firmware right above it. No doubt it would have worked at higher layer than 07KLV, but better lower: one reason is that a user can unsquash 07KLV and rename it to upper_changes (with no numeric). Then when new firmware (or modules) gets added to that upper_changes it will take precedence, and if wished, the user can re-squash the whole lot back to 07KLV sfs form. You can add anything into the system anytime you feel like it - just create a new directory, give it a 2digit numeric first part of name, and anything you put in there will be layered in at the position of the 2-digit numeric you chose. For example, it might include directory structure /usr/local/bin. But of course you can manually modify upper_changes and that will appear as top layer on reboot. No rules - in that sense - up to what you want. Of course the package database changes will be stored in upper_changes. You can make rollback upper_changes directories by putting 2digit numeric in front of name and new rw upper_changes will be auto-generated on subsequent boots. But, yes, you have to be careful to keep rollbacks in sequence and none missing if you have been installing packages via package manager (xbps) since package database would end up wrote otheriwise.

Note that none of the NNsfs or NNdirname components care about any part of the file name except for the 2digits at the front. So 07KLVxxx.sfs could be renamed to 07.sfs and would still work the same. Easy to organise mix of sfs files or uncompressed directories as addon layers therefore - up to the user - 99 layers possible, or use 07KLV as uncompressed upper_changes for a kind of pseudo (almost) full install mode since whole main root filesystem then held in uncompressed read-write form so updates actually do then correctly overwrite previous files and not add bloat - remastering in that case just really becomes a matter of squashing up upper_changes back to sfs form again.

I see even more flexibility to do things wrong and break the package database than Debian Dog.

I'll see if I can develop a cookbook process to duplicate the results I get in Debian Dog.

edit: Fred's remaster program seems to work the same in this as in DD, i.e. it makes a .sfs file from what exactly in the file system, minus what's on a exclusion list (which Fred has made more accessible).

So, to get what i want, I prepare the file system itself (unload .sfs files, run bleachbit, etc), and then remaster.

[wiak]

I see even more flexibility to do things wrong and break the package database than Debian Dog.

Yes, you have the power to break things, but then again why would you if you understand how layering works? I suppose it can happen, though never has to me that I can remember. Easier by far though to accidentally wreck your system running as root user - that has happened to me countless times despite generally being very very careful. Alas in early stages of development my scripts occasionally have a destructive evil mind of their own and even delete themselves sometimes... Of course one of the most dangerous components of all is the initrd/init, which is also the component that provides the frugal install and RAM modes flexibility. I'm always hesitant to add or modify even one line of initrd/init code since any mistake could have serious consequencies and/or simply break facilities that used to work (hence my long hesitation to bother trying to get Ventoy or SG2D to work with KLV - I still wonder if that was worth the effort). Qemu is a different matter, and even then I prefer frugal install to a read-write qemu disk image of some sort or other.

But the convenience of being able work with uncompressed layers (temporarily or permanently), for quick manual edits, and layer-related 'experiments' keeps me amused and unhealthily sitting for hours in front on my computer. If it was MS windows I'd be bored (and drained of all energy) in no time after reading the countless depressing news stories of each day.

[dancytron]

00modules_*void.sfs only has the folder /usr/lib/modules/

01firmware-*KLV.sfs only has the folder /usr/lib/firmware.

The *rootfs.sfs file does not have anything in 07KLV-airedale_rootfs.sfs/usr/lib/modules, but does have one folder 07KLV-airedale_rootfs.sfs/usr/lib/firmware/intel in the 07KLV-airedale_rootfs.sfs/usr/lib/firmware folder.

Is the */intel folder intended to be in the *rootfs.sfs file instead of 01Firmware*.*?

[wiak]

00modules_*void.sfs only has the folder /usr/lib/modules/

01firmware-*KLV.sfs only has the folder /usr/lib/firmware.

The *rootfs.sfs file does not have anything in 07KLV-airedale_rootfs.sfs/usr/lib/modules, but does have one folder 07KLV-airedale_rootfs.sfs/usr/lib/firmware/intel in the 07KLV-airedale_rootfs.sfs/usr/lib/firmware folder.

Is the */intel folder intended to be in the *rootfs.sfs file instead of 01Firmware*.*?

It doesn't really matter where you get the firmware from much of the time and I believe the Puppy firmware rockedge was often using didn't have some needed firmware for sound open software (sof audio), but was easy to fetch via Void package manager. I believe rockedge did that and of course no problem putting that in 07KLV root filesystem - the external 00firmware just gets merged with it. Certainly xbps package manager knows nothing about 00modules nor 01firmware, but that's useful in this case. Perfectly possible to have these two merged but separation is nice and convenient sometimes. Also, there is a special intird mode that allows use of Puppy style huge kernels, which traditionally only had aufs support built in, so external 00modules was able to be loaded temporarily by the initrd just to get access to overlay module, but also provide all the modules needed by the 07KLV root filesystem. Now, that mode is not so important (but still available) since we tend to have overlayfs support more readily kernel available. In fact, we are no longer relying on huge style kernels at all so can use upstream official kernels, in much the same manner as the DebianDogs (newer ones that use overlayfs) - with just sufficient modules required for booting built into the compressed initrd.

It's worth remembering that I used DebianDogs for years and years so numbered addon layers was a natural and better approach to arranging layers from my point of view and experience, though the algorithm I use for that, including its handling of a mix of uncompressed and/or sfs layers, was dreamed out of my head - that's my favourite feature of KLV and similar FirstRib initrd-based distros. I don't think it is as great at booting from iso images - simply wasn't originally designed with that at all specially in mind, and it is always difficult to add in code that wasn't part of overall design plan, specially when there is always that danger of wrecking an otherwise solid and otherwise very flexible initrd.

[dancytron]

I don't want to mix things that were installed via the package manager and things that just came from somewhere else the package manager doesn't know about in the same .sfs. I think over time it will cause version mismatches and unexpected results when things are uninstalled.

[rockedge]

@dancytron 00modules and 01firmware are the kernel components. The package manager does not need to know the contents of those. The design of KLV allows the use of non-Void Linux kernels. Originally I stayed away from the Void kernel because it added to much size to the root_fs but now we modify the initrd.gz to accommodate a Void Linux kernel which is on a version hold and the package manager will not upgrade the kernel automatically.

KLV has other mechanisms that the package manager did not install in the root_fs but are not effected by Void Linux system updates/upgrades. That has been accounted for. The 00module and 01firmware are not designed to update automatically.

I am still updating early KLV's and WDL's that are quite old successfully.

[wiak]

Yes, no problem with that sof firmware from Void, which matches the kernel perfectly and is a separate package in its own right and thus known to the package manager and sensibly for such an important system component, upgradable. The external firmware is entirely in an sfs of its own, isn't known to the package manager, and doesn't need to be. Its fine. Of course there is nothing to stop anyone using just Void sourced firmware, but tends to be a big install since designed for any hardware imaginable. Modules is a different matter - they are kernel specific, but the modules in 00module are I presume Void official - did you need to cut them down a bit rockedge? Reallly they could have been left in 07KLV - though if pinning the kernel anyway, it doesn't really matter, and advantage of a 07KLV rootfilesystem not containing modules is that it makes it very convenient to swap over kernel/modules (e.g. use Puppy huge kernels) whenever that helps or someone wants that. Best keeping it modular the way it is.

Any firmware installed into KLV or put into 07KLV sfs takes precedence over the 01firmware sfs of course, which is also a good thing.

[wiak]

@wiak this is what the current grub.cfg in rc6.1 looks like ->

Code: Select all

set timeout=10

loadfont /boot/grub/font.pf2


color_normal=cyan/black
#menu_color_highlight=black/light-gray
menu_color_highlight=yellow/red
menu_color_normal=light-gray/black

# First five entries usefully work with Ventoy

menuentry "KLV-Airedale-rc6.1 (Ventoy RAM0 no persistence)" {
 linux /vmlinuz w_bootfrom=/KLV-Airedale-rc6.1.iso w_changes=RAM0 net.ifnames=0
 initrd /initrd.gz
}
  
menuentry "KLV-Airedale-rc6.1 (Ventoy RAM2 save on demand to iso folder)" {
 linux /vmlinuz w_bootfrom=/KLV-Airedale-rc6.1.iso w_changes=RAM2 net.ifnames=0
 initrd /initrd.gz
}

menuentry "KLV-Airedale-rc6.1 (Ventoy direct saves to iso folder)" {
 linux /vmlinuz w_bootfrom=/KLV-Airedale-rc6.1.iso net.ifnames=0
 initrd /initrd.gz
}

menuentry "KLV-Airedale-rc6.1 (Ventoy RAM2 save on demand to Persistence/Sessions)" {
 linux /vmlinuz w_bootfrom=/KLV-Airedale-rc6.1.iso w_changes=LABEL=Persistence=/Sessions w_changes1=RAM2 net.ifnames=0
 initrd /initrd.gz
}

menuentry "KLV-Airedale-rc6.1 (Ventoy direct saves to Persistence/Sessions)" {
 linux /vmlinuz w_bootfrom=/KLV-Airedale-rc6.1.iso w_changes=LABEL=Persistence=/Sessions net.ifnames=0
 initrd /initrd.gz
}

I am wondering now if the method used to make the ISO is at fault......

That will work fine rockedge. The version I downloaded at beginning of the day didn't have the iso name change in that grub.conf. I'll download most recent. The early one booted fine into Ventoy too by the way (as long as iso named back to rc6); in fact I'm posting from it now after booting via Ventoy into RAM2 save on demand mode.

[dancytron]

If you remaster 00modules and 01firmware into the main *rootfs.sfs file (as Fred's script appears to do), then how are you supposed to update them at all?

If you are going to use this structure, it seems to me like 00modules and 01firmware need to stay separate and the changes folder and *rootfs.sfs would just need to be merged into a new *rootfs.sfs.

[geo_c]

If you remaster 00modules and 01firmware into the main *rootfs.sfs file (as Fred's script appears to do), then how are you supposed to update them at all?

If you are going to use this structure, it seems to me like 00modules and 01firmware need to stay separate and the changes folder and *rootfs.sfs would just need to be merged into a new *rootfs.sfs.

I did a remaster at one point. But I moved away from that approach. After a remaster, system updates will be stored in current upper_changes and should white out unused files in the remastered sfs, much like the puppy approach, so I'm guessing that in order to update and consolidate the size of the base sfs, another remaster is necessary.

[fredx181]

If you remaster 00modules and 01firmware into the main *rootfs.sfs file (as Fred's script appears to do), then how are you supposed to update them at all?

If you are going to use this structure, it seems to me like 00modules and 01firmware need to stay separate and the changes folder and *rootfs.sfs would just need to be merged into a new *rootfs.sfs.

Yes, all merged into one, that's not ideal indeed, but couldn't make it work as you suggest, probably it's possible though, but with much more complex code.

[dancytron]

If you remaster 00modules and 01firmware into the main *rootfs.sfs file (as Fred's script appears to do), then how are you supposed to update them at all?

If you are going to use this structure, it seems to me like 00modules and 01firmware need to stay separate and the changes folder and *rootfs.sfs would just need to be merged into a new *rootfs.sfs.

Yes, all merged into one, that's not ideal indeed, but couldn't make it work as you suggest, probably it's possible though, but with much more complex code.

Just thinking out loud, if you moved all the firmware to 01firmware (there is just one stray .../intel folder in *rootfs.sfs) and then just excluded the firmware and modules directories from the build using the config file, you could keep 00modules and 01firmware just like they are and could be updated or swapped out as necessary.

[fredx181]

If you remaster 00modules and 01firmware into the main *rootfs.sfs file (as Fred's script appears to do), then how are you supposed to update them at all?

If you are going to use this structure, it seems to me like 00modules and 01firmware need to stay separate and the changes folder and *rootfs.sfs would just need to be merged into a new *rootfs.sfs.

Yes, all merged into one, that's not ideal indeed, but couldn't make it work as you suggest, probably it's possible though, but with much more complex code.

Just thinking out loud, if you moved all the firmware to 01firmware (there is just one stray .../intel folder in *rootfs.sfs) and then just excluded the firmware and modules directories from the build using the config file, you could keep 00modules and 01firmware just like they are and could be updated or swapped out as necessary.

Ah, yes, that should work, at least the kernel modules and firmware are not included in the remaster then, just add at part2 of the config (edit: intended that it's without first slash):
usr/lib/modules/*
usr/lib/firmware/*
Or if you want to keep the intel/sof firmware, add at part1: find /usr/lib/firmware -maxdepth 1 -mindepth 1 ! -name 'intel' 2> /dev/null | sed 's|/||' >> /root/excludelist
and at part2 only usr/lib/modules/*
Then the whole config:

Code: Select all

# this is a script to create /root/excludelist, which contains files/folders to be excluded from the remaster
# modify as desired, it will be executed at a later stage

###### PART 1, find commands: ###### 
# uncomment or comment to exclude or not, e.g. man doc locales
find /var/log -type f 2> /dev/null | sed 's|/||' >> /root/excludelist
#find /usr/share/doc -type f 2> /dev/null | sed 's|/||' >> /root/excludelist
#find /usr/share/man -type f 2> /dev/null | sed 's|/||' >> /root/excludelist
#find /usr/share/info -type f 2> /dev/null | sed 's|/||' >> /root/excludelist
#find /usr/share/locale -maxdepth 1 -mindepth 1 -type f 2> /dev/null | sed 's|/||' >> /root/excludelist
find /usr/lib/firmware -maxdepth 1 -mindepth 1 ! -name 'intel'  2> /dev/null | sed 's|/||' >> /root/excludelist
####################################

######  PART 2, exclude files/folders ######
### continue creating excludelist, add or remove files/folders to exclude, below are examples
# (after echo line) e.g. root/.mozilla (should be WITHOUT forward slash)
# or comment/uncomment by adding/removing # in front
echo  '
#root/.mozilla
root/.bash_history
root/.local/share/Trash/*
root/.wiakwifirc
root/.cache
etc/blkid-cache
var/cache/fontconfig/*
usr/lib/modules/*
# exclude leftover files from this remaster
root/excludelist
root/excl-cmd
# exclude xbps install cache
var/cache/xbps/*
# exclude network settings
#etc/NetworkManager/system-connections/*

' >> /root/excludelist
####################################

EDIT: But this may not work always as desired, say you compiled a kernel module or added firmware, it will not be in the remaster, so use only this way if this is not the case.

[dancytron]

Being able to easily edit the exclusion list and compute items for the list with little scripts is a powerful tool.

I'll play with it when I have time.

[fredx181]

Being able to easily edit the exclusion list and compute items for the list with little scripts is a powerful tool.

I'll play with it when I have time.

What I like about it (and want to keep) is the simplicity, which is in fact no more than something like: mksquashfs / ... <exclude this> <exclude that> <exclude some more>
With the flexible options, e.g. -e (exclude path) , -ef (exclude files/folders from a list) and -wildcard options of mksquashfs, anything can be configured the way you'd like.

[Clarity]

Sorry for the delay.

@Clarity which distro's ISO does Ventoy boot? I need to see the differences in the overall boot mechanism. ...

On the ROX folder listing here, the ONLY distros which boot directly from the Ventoy Menu is the Slacko64s and FATDOG v8s shown.

To boot the other ISO files on the list, after Ventoy Menu, I select SG2D and use its Menu list to boot all the ISOs it shows without any boot issues.

Most recently, I am seeing some issues with booting KLV vRC6s ISO files for some reason.