KLV-Airedale-sr12 with the Void Linux Kernel 6.8.4_1

[rockedge]

@wiak I checked the URL's and they are pointing to the versions on owncloud.

I replaced the wget function block with those from the newest get_WDLskelinitrd_latest.sh and the kernel assembly went smoothly. Brand new initrd.gz and matching vmlinuz and 00modules SFS using skeleton initrd version="7.0.3"; revision="-rc1" Date: 05Apr2024

New repackaging of KLV-Airedale-sr12 with latest version of FR initrd ready for download in the first post of this topic.

[rockedge]

Should work now with Ventoy installations!
Please report experiences booting ISO with Ventoy......

[wiak]

Should work now with Ventoy installations!
Please report experiences booting ISO with Ventoy......

Good you got that fixed. It is possible the FR initrd would need more than exfat module to get exfat working with Ventoy though; I don't remember trying an iso using real Void kernel with Ventoy exfat partition, though maybe I did. The surprise is that @fredx181 couldn't get Sofiya's KLV-Hyprland to boot from Ventoy exfat partition - yet Sofiya used FR initrd that did include module load for exfat (assuming her iso didn't use huge kernel, which presumably would have exfat support built in anyway). Once I successfully download your new iso I'll give it a try and report if working now.

[wiak]

I did a git pull on the build script repo so I assumed I was using the latest scripts to build the Void Linux kernel for KLV that are getting the download of initrd.gz_latest and automatically deleting the downloaded version after usage by the script.

That's a bit odd though since the gitlab site does always contain the latest version of initrd-latest.gz (FR skeleton initrd). Similarly it contains the latest of the Thomas M related module insert scripts:

FRmake_initrd.sh, FRmake_initrd_dep.sh, and FRextract_kernel.sh

in https://gitlab.com/firstrib/firstrib/-/ ... ild_system

as well as latest: get_WDLskelinitrd_latest.sh in https://gitlab.com/firstrib/firstrib/-/ ... on_initrd/

However, I won't worry about it and hope new KLV-Airedale works. I still can't complete download cos of flaky internet here. Main thing to check will be uncompressed FR initrd to see it is most recent version but also that it also contains any required exfat-related module (assuming not a huge-kernel where kernel itself would contain exfat driver). If it still won't boot using Ventoy from Ventoy exfat partition, I'll have to try and work out why. It certainly would be a pity if distros couldn't be booted via Ventoy when that facility is provided by FR initrd (when appropriately constructed).

[wiak]

Should work now with Ventoy installations!
Please report experiences booting ISO with Ventoy......

Yes, all good, klv-airedale latest is booting fine from Ventoy exfat partition using latest FR initrd and Void kernel and initrd with embedded modules. Out for coffee now so didnt have time to verify you can use w_initconfig in boot isos folder to redirect save persistence automatically to anywhere you like, including when using Ventoy. But I'm sure it will work fine per the brief howto I gave under kl devwork area. I'll add to howto area later.

[Clarity]

Within a VM this boots, when launched from Ventoy USB, to desktop. As always, I take the default vSR12 Grub2 Menu's stanza to boot.

Are you able to mount the Ventoy partition and write to it?

vSR12.jpg (21.13 KiB) Viewed 1969 times

Here's a VM stanza

Code: Select all

qemu-system-x86_64 -name "Boot Ventoy USB" -enable-kvm -smp 2 -m 2048 -vga cirrus -device AC97 -net nic -net user -rtc base=localtime -boot order=d -drive file=/dev/sdg,format=raw -hdb /mnt/sdh1/PERSISTENCE.qcow2

P.S. Exact same success to desktop, when booting SG2D, as shown, above, for Ventoy launching. Thus both Ventoy and SG2D yield same result to desktop.

[fredx181]

Yes, all good, klv-airedale latest is booting fine from Ventoy exfat partition using latest FR initrd and Void kernel and initrd with embedded modules

Sorry to say. Still not good for me, kernel panic again.
Used the new sr12 ISO, all seems fine in theory (decompressed initrd.gz and noticed latest version (5 apr) of init and w_init) and exfat in the module list to be modprobe'd.
What I see quickly passing by (before the kernel panic message) is that it seems to search only in my nvme HDD partitions, not in sda (which is my Ventoy USB).

Further explorations I did:
- when having the sr12 ISO also on my HDD, it boots (as was before, no news) checked if exfat was loaded: lsmod | grep exfat it was NOT.
- added exfat to the removal exceptions (on modprobe -r ... line) in w_init, rebuilt the initrd.gz , rebuilt ISO (replaced initrd.gz with the modified one) tried booting it with Ventoy, NO LUCK, again... kernel panic.
- then added the modified ISO also on one of my nvme partitions, booted with Ventoy, it booted ok of course, but wanted to check if exfat was loaded, and yes it was.

@Clarity are you able to test sr12 with Ventoy directly from USB (without using qemu) ?, curious if it does work for anyone else.
EDIT: For what it's worth, my Ventoy disk showing from Gparted:

2024-04-07_10-13-03.jpg (35.28 KiB) Viewed 1956 times

[Clarity]

vSR12(1).jpg (32.11 KiB) Viewed 1950 times

Forum	------ Bare-Metal ------	------- QEMU (VM) -------	PXE

Distro	Ventoy	SG2D	Native	Ventoy	SG2D	PXE
KLV-Airedale vsr12	N(6)	N(6)	Y	Y	Y	N(6)

Legend for 'N' (No) in table

• (1) - Drops out to GRUB prompt

• (2) - Stops at Console w/o Desktop

• (3) - TRAP/Abend during boot

• (4) - IMG Not Supported by Launcher

• (5) - Requires session-save parm, manually added, to GRUB2 Menu stanza for boot

• (6) - Not tested

[fredx181]

vSR12(1).jpg

Isn't that from qemu again ?

@Clarity are you able to test sr12 with Ventoy directly from USB (without using qemu) ?, curious if it does work for anyone else.

[Clarity]

Isn't that from qemu again ?
@Clarity are you able to test sr12 with Ventoy directly from USB (without using qemu) ?, curious if it does work for anyone else.

See table above

Dont have a test PC avaiable. Will test bare-metal during the afternoon.

P.S. My USB is a "cheap" 128GB v1.0.97 Ventoy upgraded a few months ago. I cannot remember if is Secure Boot or not. EVERY ISO & IMG file is kept in its BOOTISOS folder. As reported, SG2D finds them...as well.

BTW: Can anyone guide me in how to use "take-a-gif" to capture the booting of the VM window?
I could use a GIF capture to compare what I will see when booting bare-metal from both SG2D as well as Ventoy.

vSR12(2).jpg (83.28 KiB) Viewed 1930 times

[wiak]

What I see quickly passing by (before the kernel panic message) is that it seems to search only in my nvme HDD partitions, not in sda (which is my Ventoy USB).

Unfortunately my laptop that has nvme disk is out of action at the moment, but I guess that wouldn't help track down your issue since its the sda you say isn't being search.

I am also simply using a Ventoy usb, but since sda is the harddisk, the usb is seen at sdb and the usb is partitioned with Ventoy label having exfat partition where I have placed a /BOOTISOS folder with KLV-Airedale-sr12 inside it and all works perfectly fine booting. Also the w_initconfig mechanism I added to latest FR initrd to redirect save persistence anywhere user wants is indeed working perfectly fine with Ventoy.

Based on the failure report, the only obvious difference would seem to be that sda versus sdb matter. I'll check the FR initrd/init code to see if something about it would make it ignore sda, though I can't imagine off the top of my head why it might do that... Aside from that, I'm not sure how to help since no such boot failure here; I'll keep thinking about it based on the fail report given though since must be something behind the issue of course.

So the question would seem to be: "why is it ignoring sda (on machine where usb appears there), but it is not ignoring sdb (on machines where usb appears there...." ????! It seems to me the answer to that will be somewhere in the FR initrd/init search function (_find_bootmnt) - shouldn't be hard to find if that is the case.

[wiak]

I wonder if it is that dev_nosrch /dev/loop ??? Which is my suspicion...

But if so, why sdb okay, but not sda, on machines that use sda for internal hard drive I wonder...

Could of course be 'forced' to search sda, but best to have a logical reason before implementing that.

A debug statement here should reveal the issue, but needs iso rebuild to test of course, which is always annoying:

Code: Select all

partitions=`cat /tmp/blkid_devs 2>/dev/null | cut -d: -f1 | cut -d/ -f3`  # parse stored blkid info for partition name only

So will echo $partitions to see what will be searched...

UNFORTUNATELY, not having an nvme and thus sda as Ventoy disk I cannot myself debug this at this time, but I guess you can Fred.

[Clarity]

I caution: Bare-metal, based upon what I see reported, 'could' expose something that is not seen in a QEMU VM.

Questions

• Could you try QEMU booting to see if you are reaching desktop?

• AND could you add SG2D (ISO/IMG) to your BOOTISOS folder and test to see if results are the same.? Reason: I seem to remember somewhere recently on a distro that booted from GRUB2 but NOT from Grub4DOS. Then, boot SG2D from the Ventoy list, then launching your offending ISO file from the SG2D ISO list it shows.

Just some thoughts until I can free a test PC, later.
BTW: Those are the 2 bare-metal tests I show in the results table, above.

[wiak]

Code: Select all

		partitions=`cat /tmp/blkid_devs 2>/dev/null | cut -d: -f1 | cut -d/ -f3`  # parse stored blkid info for partition name only
		for p in $partitions; do  # inner loop
			if ! mountpoint -q /mnt/"$p"; then
				case `blkid -o value -s TYPE /dev/$p` in 
					vfat) mount_options="-o noatime,nodiratime,suid,dev,exec,async,umask=0,check=s,utf8"
						mount_partition "$p" 10 "$mnt_options"  # 1 maybe enough
						;;
					ntfs) mount_options="-t ntfs3"
						mount_partition "$p" 10 "$mnt_options"  # 1 maybe enough
						;;
					*)	mount_options=""
						mount_partition "$p" 10 "$mnt_options"  # 1 maybe enough
						;;
				esac  # may need other format case types if different mount_options needed

Though above (as FR initrd/init code currently is) works for my Ventoy on sdb usb, perhaps a case statement for exfat with mount_options="something or other...", but I'm just guessing without capability to debug sda for Ventoy on my machine

[wiak]

What I see quickly passing by (before the kernel panic message) is that it seems to search only in my nvme HDD partitions, not in sda (which is my Ventoy USB).

Well there is that limitation in the simple FR initrd search for iso code that I specified on release; once partition with path to named iso is found the search will stop. That is why you got that apparently weird situation of iso being found on nvme hard drive when trying to boot using Ventoy from usb. Actually works at end of day even with that since the save persistence will be used correctly and who cares where the identical iso lower layer stuff is being found... But, for Ventoy, I only really catered for someone not storing same iso in two places, which confuses the search. If you remove or rename the iso on the hard drive, then you should, all going well, see sda also getting searched?????? Then the question would remain: why is it not being mounted on your system (at sda) when it is on mine (at sdb).

I should add, that when in NZ, I was using a machine with nvme hard drive and my Ventoy was on sda, and all my KL distros loaded fine via Ventoy so the failure report is an unknown issue to me.

How about using a second usb stick too, such that (hopefully) you could manage to get the Ventoy stick seen as sdb to see if that then works (sounds unlikely it will on your machine though)? You would still need to rename the on hard disk version to allow search to proceed. Are you sure you don't have a wrong FR initrd version somewhere else on your hard drive - that would be detected and prevent the sda search too.

[fredx181]

@wiak
I tested booting sr12 with Ventoy USB on my very old laptop (from 2007) and it booted fine (only got a very "darkish" screen, but that's another (kernel?) issue).
Perhaps interesting to mention: After search for the ISO (was found correctly on sdb1, the HDD is sda) there was a message, something like "cannot unmount sda1".
Apparently it (Ventoy mechanism or w_init, don't know) attempted to unmount sda1 (don't know what's it good for btw).
EDIT: Well, I give it a rest now (all those kernel panics made me nervous ) perhaps one day when you can test again with nvme hdd maybe you can figure out what's happening.
I've never been so keen on stuff like Unetbootin, Rufus, Ventoy, SG2D etc... now even more disliking it, just glad that I found my way to manually setup bootloader + config.

@Clarity Perhaps later I will test with qemu.

[wiak]

Apparently it (Ventoy mechanism or w_init, don't know) attempted to unmount sda1 (don't know what's it good for btw).

Yes, that message is irrelevant as far as I remember. I should take out some such messages that don't actually mean anything, but never got round to it yet...
However, I'll keep that in mind just in case it is related - you never can be sure despite seeming unlikely to me right now; didn't use nvme devices at all when first writing the search code so maybe having sda as the Ventoy disk somehow plays havoc because of unwanted umount (check later on that one...).

EDIT: Well, I give it a rest now (all those kernel panics made me nervous ) perhaps one day when you can test again with nvme hdd maybe you can figure out what's happening.
I've never been so keen on stuff like Unetbootin, Rufus, Ventoy, SG2D etc... now even more disliking it, just glad that I found my way to manually setup bootloader + config.

I will be able to (re)test on my previous nmve equiped computer once an hdmi monitor arrives in my shipping (I earlier, many months back, broke the laptop screen and haven't fixed it yet...). Best to let it rest for now - good to hear if more such nvme-related/sda failure reports though, but for now more effort than it is worth (and I can't test as things stand anyway). For others, like me on all current computers here, Ventoy booting all good. Most of the time I'm not interested in the likes of Ventoy, but it is handy for quick testing of many distro releases - all going well... saves a lot of time, but as the main boot mechanism???: not for me no. I do also find it handy for a maintained, quick grub2 install to usb sticks though - despite it involving a bit more than is actually required for that purpose.

[wiak]

I have a different little problem. Nothing to do with Ventoy but related to the new w_initconfig mechanism for redirecting location of upper_changes savefolder.
Nothing wrong with the FR initrd code mechanism, but save2flash wasn't designed to work with this new facility. So for now, don't use the w_initconfig facility; I will take a look of potential solution and report back later. Doesn't effect any usual KL functionality - just none of the w_initconfig functionality should be used right now; will certainly make it happen sooner rather than later, because it is pretty useful (especiallly when iso booting, be that via Ventoy or otherwise, but also potentially useful more generally).

[Clarity]

Screenshot_2024-04-07_09-27-40.jpg (157.75 KiB) Viewed 1837 times

Booted Ventoy bare-metal and launched GRUB2 KLVA-vSR12 to desktop.

Bug
After mount, I used Thunar to dismount the Ventoy partition. Ventoy's complete USB disappeared from the system. Not present in thunar, desktop or Gparted. Further, cannot find a system utility to retrieve the 'loss'. Its gone!

Rebooted this PC back into Bookworm64 via Ventoy and all is well and present. Next test will be bare-metal SG2D.

[Clarity]

UPDATE

I discovered the followiing that "may" have been a causation to the above boot result when launched from Ventoy.

Discovery
Three is a "boot-isos" folder on a system drive that contains the KL distros, as well. It "may' have had an impact. Not having the ability to delve into the INIT code, I am unsure how/why this could have cause the 'bug' mentioned. So I
first rename the system drive folder to something else and rebooted the tests using the same Ventoy USB. I got different results reported in the next post.

[fredx181]

Booted Ventoy bare-metal and launched GRUB2 KLVA-vSR12 to desktop.

Thanks, good to know!
Question: don't know if you followed in this thread i.e. the talking about nvme vs sda HDD partitions (as I said I have nvme HDD partitions and booting ISO from Ventoy USB doesn't work for me).
Does your HDD have nvme partitions with your recent test ? (or is it sda)

[Clarity]

I am getting the EXACT same results of booting to desktop that we saw when testing under a VM. Each boot, no matter if launched from Ventoy or from SG2D on bare-metal yields the same result.
Question

• Can anyone see/mount/use your Ventoy partition when the boot is launched from either Ventoy's list or SG2D's list?

Forum	------ Bare-Metal ------	------- QEMU (VM) -------	PXE

Distro	Ventoy	SG2D	Native	Ventoy	SG2D	PXE
KLV-Airedale vSR12	Y	Y	Y	Y	Y	N(6)

Legend for 'N' (No) in table

• (1) - Drops out to GRUB prompt

• (2) - Stops at Console w/o Desktop

• (3) - TRAP/Abend during boot

• (4) - IMG Not Supported by Launcher

• (5) - Requires session-save parm, manually added, to GRUB2 Menu stanza for boot

• (6) - Not tested

Screenshot_2024-04-07_10-41-01.jpg (159.25 KiB) Viewed 1820 times

[wiak]

I am getting the EXACT same results of booting to desktop that we saw when testing under a VM. "Each boot, no matter if launched from Ventoy or from SG2D on bare-metal yields the same result.

I think main test Fred is looking for is by someone who has a machine that has an nvme harddrive such that the Ventoy usb appears as sda (rather than often typical sdb).

Actually, I suddenly remembered my wife's business has a new Lenova laptop that may well have nvme hard drive. In fact as far as I recall it has two nvme harddrives but that should still result in the Ventoy usb appearing as drive sda. I'll look that machine out tomorrow and see if it can be used as a new test.

One weird thing, that turned out to be nothing to do with KLV or Ventoy that I discovered today:

I have an HP Folio laptop that simply refused to see the Ventoy device at all.... I did the typical press F9 key during boot to see all bootable drives, but no usb entry was appearing. I went so far as to reset the 'BIOS' to default, but still nothing. I did that a few times, and then changed a few parameters in the boot section of BIOS program but only obvious stuff like making usb available (which it was set to be all along anyway). Well, somehow, after doing same sort of settings various times and save and exit, suddenlty the usb drive appeared via F9 on boot... Weird. Previously simply couldn't detect it. Really the settings shown are identical to what they were in the first case but somehow by messing around back and forth I managed to bring usb booting back to life. Different kind of problem I suppose, but shows how weird such 'BIOS' stuff can be sometimes.

[wiak]

After mount, I used Thunar to dismount the Ventoy partition. Ventoy's complete USB disappeared from the system. Not present in thunar, desktop or Gparted. Further, cannot find a system utility to retrieve the 'loss'. Its gone!

There are a few matters related to what Thunar shows or how it shows them or that it doesn't show because of the media folder mount way it expects things (in XFCE at least) that annoy me and I'd like to address eventually. Unfortunately such matters prove to be decidedly tricky. Certainly, I can usually find partitions via commandline tricks, but that can be messy. Once Thunar is told to 'lose something' I imagine it can be difficult to get it back again... such matters are sent to test our patience for sure... No answer, just confessing there are some user issues I'm aware of that need some attention eventually...

[Clarity]

... Well, somehow, after doing same sort of settings various times and save and exit, suddenlty the usb drive appeared via F9 on boot... Weird. ...

I have an older PC, circa 2012 IIRC, that this happens frequently upon a reboot.

To get around this PC's BIOS bug, I know to shut it down. Unplug and replug the USB and its back to proper discovery following. I am certain this is a shortcoming in the PC's post functioning and/or an issue with the USBs I use. This has been the case for the many years I've had this test PC.

Hope this is helpful.

[rockedge]

I have an older PC, circa 2012 IIRC, that this happens frequently upon a reboot.

I see it also on some machines......timing issue I think.

[Clarity]

@wiak and @fredx181

I have a PC that has 2 system drives. I have, last year, converted its 2nd drive to a Ventoy Drive. Is this what has been done where drive addressing is a problem for you?

When I finish testing latest Fedora-wayland, I will test KLV-Airedale launching.That PC does NOT require USB and has been a flawless platform in booting its ISO files when interrupting POST to select that 2nd drive. I cannot remember if it addressed the Ventoy system drive as sda or sdb upon desktop arrival.

[wiak]

@fredx181

Using Ventoy usb stick on newish Levova ThinkBook 14s Yoga Gen 2

This laptop has nvme hard drives (two actually) per gparted screenshot

Thus the Ventoy usb appears on sda per gparted screenshot

Booted KLV-Airedale-sr12 without issue

During boot FR initrd/init says:

...
Please wait:...searched file partition is /mnt/sda1
iso /BOOT bootmnt/from_path is /mnt/sda1/BOOTISOS/KLV-Airedale-sr12.iso
...

after which it goes on without issue to KLV xfce desktop (posting from it, after Ventoy booting it, now).

I can only suggest there might be some issue with your HP laptop and usb detection, Fred, or some kind of kernel-related timing issue?
The FR initrd/init certainly searched correctly and worked as intended.

[Clarity]

@wiak, Thanks. This is consistent in my use with students in the past.

One thing I have them do that you might consider as you have loads of space free on the system drive. Make a small Persistence partition at the end of the primary system drive should you, may in the future, consider saving sessions. That way the primary system's partitions on the laptop is never needed to be touched; and only used, at best, as read-only data services roles.

In their operations and tests, when using the Ventoy USB is that all write operations are confined to ONLY the Sessions folder on Persistence on the superior performance of the system drive.

I advise to never put Persistence on a USB. I could show the many reasons I have found in tests, but, its unnecessary to do so ti seasoned developers.

Of course, you know the advantage this advice affords to students.

[wiak]

@wiak, Thanks. This is consistent in my use with students in the past.

One thing I have them do that you might consider as you have loads of space free on the system drive. Make a small Persistence partition at the end of the primary system drive should you, may in the future, consider saving sessions. That way the primary system's partitions on the laptop is never needed to be touched; and only used, at best, as read-only data services roles.

Actually, that's what I normally do in practice, Clarity; I relabel the usb so not having Persistence label, and make one on my main hard drive since much more efficient. But for quick testing I use usb Persistence LABEL arrangement since I can test that anywhere.

However, with the w_init (or better, the latest w_initconfig) arrangement, I can actually store save sessions anywhere on my system, even when starting from Ventoy in say RAM2 mode. That's works fine even as system stands, but better with a modified save2flash script that I'll describe to others later. Of course, a consistent "Persistence" LABEL partition arrangement, which is what you prefer, is certainly nice for most users to understand and use.

Note that I neither use Ventoy's own persistence mechanisms (they don't really work with forum distros anyway) or need it in any way; instead I let FirstRib initrd handle how to do it when Ventoy is employed - that gives us full control and reliable save persistence handling in KL distros that correctly employ the FirstRIb method. Via that FR method, NO user intervention is required AT ALL during Ventoy booting (meaning that no stopping to edit the auto-provided grub boot stanza is needed at all with KL/FR - the FR initrd automatically arranges for KL/FR save persistence to work in a seamless fashion with any and all ISO booting mechanisms, which is the ideal aim for such booting facilities to get most use advantage out of them).