Booting the current KL series of forum distros (Solved)

[Clarity]

I have concluded testing where I am booting the most currect series of KL distro in the following environments:

• QEMU-native KL... ISO file boot

• QEMU to Ventoy-ISO file boot

• QEMU to SG2D-ISO file boot

Namely the ISO files I have are:

• KLA-OT2base-rc3.iso

• KLA-XFCEbase-rc4.iso

• KLU-jam-rc4.iso

• KLV-Airedale-rc10.1.iso

• KLV-Airedale-rc10.iso

Results of testing in a VM

1. Booting each ISO files directly under QEMU ... Success with each ISO

2. Booting the Ventoy USB stick under QEMU, selecting each ISO from Ventoy list ... All ISOs fail

3. Booting SG2D USB stick under QEMU, selecting each ISO from SG2D list ... Success with each EXCEPT KLVs

4. Booting the Ventoy USB stick, launching its SG2D ISO file, then booting the KL... ISO file under QEMU ... Success with each EXCEPT KLVs

VM stanzas

• booting any ISO file directly
  qemu-system-x86_64 -enable-kvm -m 2G -smp 2 -device AC97 -cdrom /mnt/sdg1/BOOTISOS/KLV-Airedale-rc10.iso

• booting any USB stick directly
  qemu-system-x86_64 -enable-kvm -m 2G -smp 2 -device AC97 -hda /dev/sdg

If there are any specific test that you see issues with, please refer to which of the test you want answers.

These are mere test results and should NOT be viewed as a request. Again, this merely shows what's happening for review.

Next up....Bare-Metal test via each of the 2 ISO file boot helpers. ... as soon as a test PC is freed up.

[wiak]

[*]Booting the Ventoy USB stick under QEMU, selecting each ISO from Ventoy list ... All ISOs fail
[*]Booting SG2D USB stick under QEMU, selecting each ISO from SG2D list ... Success with each EXCEPT KLVs
[*]Booting the Ventoy USB stick, launching its SG2D ISO file, then booting the KL... ISO file under QEMU ... Success with each EXCEPT KLVs

I consider these mixed-boot mechanisms non-standard and convoluted so wouldn't bother with these particular tests most will not use anyway.

Of interest, but not described, is normal booting via a physical Ventoy usb stick on physical machine (NOT ventoy usb stick plugged into a Qemu machine - if that works, that's fortunate, but certainly not supported by me).

Similarly, booting from actual SG2D stick plugged into physical machine (NOT SG2D being run under Ventoy - again 'not supported' by me, meaning my FR initrd code).

and likewise, NOT supported SG2D stick running under Qemu.

Certainly, it might end up being the case that some of these 'work', but don't have time to maintain such configurations.

What is maintained is Ventoy, SG2D, Qemu, and normal frugal install, but on physical machine - not mixed in convoluted tests sorry. By all means report these if you wish, but the results are purely for anyone's curiousity and will not lead to any code/implementation changes.

I find that all KL distros (usually) boot fine with normal Ventoy, SG2D, Qemu and frugal installs (on physical machine - not roundabout via Qemu intermediary, which I don't ever even try TBH - time is already short without such unusual tests that I really couldn't predict the likely result of...). Some distro arrangements 'may' work with such arrangements, but why bother? - just plug Ventoy or SG2D into your physical machine or if wanting virtual machines, just run the iso straight via Qemu. So important test is to find if all still boot with physical plugged in Ventoy, SG2D, which test report doesn't cover unfortunately. I presume that is the to-come bare-metal tests?

[wiak]

Okay, so this is KLA area, but above was about KLV-Airedale failing to boot using SG2D (albeit via some other boot mechanism - Ventoy or Qemu). I thus quickly put KLV-AIredale 10.1 iso onto a physical SG2D stick, plugged it in and tried.

Booted fine for the two modes I was able to test, being:

RAM0 no persistence, and:

RAM2 save on demand to Persistance labelled partition.

I wasn't able to try boot on demand to SG2D labelled usb stick since my SG2D usbstick doesn't yet have that label, so wouldn't work - that's not any fault in KLV-Airedale though.

[Clarity]

Whether you choose to dismiss the methods for booting I show, as I have reported in the past, in most every case, the methods mirror what is seen on bare-metal.

My above statement is NOT meant to anger, rather it intends to re-enforce what I have found in past years testing. The Ventoy -> SG2D USB allows me to first test in Ventoy, then to test in SG2D without a need to change USB sticks when validating the ability to boot. For all PUPs & OGs (excepting a very-very few) if the distro does not boot in Ventoy, I then check to validate behavior via SG2D in BOTH bare-metal and VM environmental tests.

Their more, of course, in the benefit of that USB.

I also have and companion test a SG2D only stick to verify when I observe misbehaviors in both Ventoy-SG2D USD and/or QEMU such that I can provide accurate feedback whenever boot-time issues surface.

In all cases, I try as best I can to give sufficient info to the developer that might be useful for any future movements they decide in an effort to be helpful.

7 methods to boot any and every bootable ISO file tested over the past 5 years. This includes IBM/Apple/Microsoft/Debian/ and other big box and small box offerings.

I do understand that boot issues can be frustrating to deal with, as many-many factors can affect the various things I've seen in distro boots over the years. Years ago, for me, it was the constant BIOS changes, then Windows came along and more BIOS changes, then Apple, then UEFI, then ... well we know this story as we, all, have seen them ... constantly.

I admire all developers as they have to endure the multiplicity of elements that they face constantly in the software world for the world of hardware their software must run on. This gets even crazier when you throw in the varied filesystem formats which can/do affect things as well.

Yes, it can be headachey, I agree.

Please dont let my post bother as it merely is just giving some examples of what I am seeing. The one benefit that QEMU afford me is that VM stanzas I use creates the EXACT Virtual PC no matter which OS I run on whichever PC is used: That virtualPC will always be an exact replica. sThis is beneficial in that as I investigate behavior in bare-metal I take note of the hardware differences between the Virtual PC versus the bare-metal.

After I complete a couple more promises I've made, I will, next, try as best I can to create a VM stanza that I am confident in which is a UEFI version. I feel the BIOS VM I currently report will be obsolete for comparison soon, if not already. To do so, of course, there are several issues that come into play as UEFI is one thing while SecureBoot is another as well as Legacy UEFI is yet another...you get the picture.

Please understand, that I am only the messenger in my reporting. It is merely my observations and does NOT mean anyone needs to change unless it is important to do so.

[Clarity]

Back to reporting.

Bare-Metal booting of the 5 KL's I've shown do not boot on my Ventoy USB stick. In every case, I have shown whether in QEMU or on bare-metal I am merely allowing each KL to boot to its menu where I allow it to default to boot without touching the console or changing default menu stanza. That is the RAM0 option at the top of their menu selections.

The Ventoy USB stick is GPT and Ventoy builder utility creates partition #1 as ExFAT. (this matches quite a few USB purchased, OOTB).

Booting the SG2D ISO file from the Ventoy selection screen, I have just complete to desktop OT2 distro. This is consistent with what was seen in my earlier post:

OT2 desktop showing bare-metal drives

Screenshot from 2023-02-11 21-37-45.jpg (105.48 KiB) Viewed 1336 times

This picture was capture using the "screenshot" utility in the desktop menu. For some reason, the PrtScn key does not launch the screenshot utility.

I will try to get the other KLs for bare-metal testing via the other USB sticks if I can get some free moments this weekend. Weather here is comfortable and outside demands are being placed on me to do work I've been neglecting.

Will return with other test in boots and session-saves as soon as I can.

[wiak]

Back to reporting.

Bare-Metal booting of the 5 KL's I've shown do not boot on my Ventoy USB stick. In every case, I have shown whether in QEMU or on bare-metal I am merely allowing each KL to boot to its menu where I allow it to default to boot without touching the console or changing default menu stanza. That is the RAM0 option at the top of their menu selections.

The Ventoy USB stick is GPT and Ventoy builder utility creates partition #1 as ExFAT. (this matches quite a few USB purchased, OOTB).

Booting the SG2D ISO file from the Ventoy selection screen, I have just complete to desktop OT2 distro. This is consistent with what was seen in my earlier post:Screenshot from 2023-02-11 21-37-45.jpgThis picture was capture using the "screenshot" utility in the desktop menu. For some reason, the PrtScn key does not launch the screenshot utility.

I will try to get the other KLs for bare-metal testing via the other USB sticks if I can get some free moments this weekend. Weather here is comfortable and outside demands are being placed on me to do work I've been neglecting.

Will return with other test in boots and session-saves as soon as I can.

I don't quite understand your report Clarity. I don't even have most KL distros on my hard drive; I am booting them all from my Ventoy usb stick! You say you are using GPT with ExFat partition #1. Where are the isos being put and what format of partition are they put on? I don't know anything about ExFAT so it 'may' be that has something to do with your failure reports. However, if Ventoy itself is booting I would have thought it doesn't matter whether the iso is supporting ExFAT or not since it has to be booted from a Linux formatted partition except for RAM0 mode or if a savefile rather than a savefolder is being used. Without fully understanding your setup, I can't duplicate and discover anything. Yes, boot issues are frustrating, I confirm that - and it is indeed perfectly possible that KL will not boot under all the plethora of circumstances. I chicken out somewhat because the maintenance and development is already too much work so instead of guaranteeing boot in all circumstances I prefer to stipulate what to use that is known to work. For now at least.

[Clarity]

@wiak My Ventoy USB version is current v71. Ventoy v88 is currently out but I have not upgraded as yet.

Screenshot from 2023-02-11 21-37-45.jpg (120.62 KiB) Viewed 1317 times

[Clarity]

You just triggered something that I think is worth my investigation: When you created your Ventoy USB did you

• create it from the Ventoy ISO/script/EXE?

• Did you set the USB to be MSDOS or GPT?

• Did the 'create' utiltiy create the filesystems on the partitions or did you change them?

• Did you have the create make a 3rd partition for you?

All of this may be instrumental in the differences of the behavior you and I are seeing.

Note: I have been building my Ventoy with options with GPT because I used the USB in both Windows as well as Linux boots. Thus I can read and write from all BIOS/UEFI system OSes this way.

It would be great if I could have a copy of your Ventoy USB. Without a lot of effort, would you, when time permits, make an image file of your Ventoy USB with whatever KL distro(s) you choose and post where I can copy it to test? (IFF you make one from scratch please keep the same Ventoy options so that I can replicate what you see)

This way, I can replicate your Ventoy behaviors and can identify the differences exposed in the testing being done by each of us. I will report back if you feel it acceptable. I will have no problem taking an image file to either USB or QEMU should you make it available)

Or if you prefer, I could make and post an image on my end.

Whichever works for you, I will follow-thru.

[wiak]

It has long ago been explained, @Clarity that any distros initrd/init has to, by itself, also find the location of where the isos are stored (even though Ventoy has its own search routine and finds your isos in boot-isos, FR initrd will not...). Some distros look all over the system in every partition. FR initrd is not an auto-search everywhere kind of distro - it was designed to be told where to find things (via appropriate LABEL or UUID). As I said weeks ago, months ago probably, FR initrd/init searches only in two places otherwise (for iso searching): a folder exactly named as /BOOTISOS or in / of the Ventoy disk. I will not be expanding FR initrd search code to include boot-isos, sorry.
You are putting your isos into a directory named boot-isos; they will not be found there by KL system. It is as simple as that. I never said boot-isos was a location FR initrd/init uses or searches; it doesn't. Yes, I know that SG2D also happens to search in directory path /boot-isos and also in /BOOTISOS and probably some other places, but that is irrelevant to the distro itself, which also has to do its own search - however SG2D is less of a problem because it provides the directory path to the distro. Ventoy however does not - the distro itself has to find wherever the iso is (even though Ventoy knows...) and FR initrd/init thus had to have special search code put into it, but it is not Ventoy, it is not SG2D it is FirstRib, and FR searches are limited to BOOTISOS or /. Summary, FR/KL distro is NOT Ventoy nor is it SG2D; it does not search all over the disk like they do. You don't seem to understand how these mechanisms work - you seem to think that they discover the iso and then the distro found can just boot - that is INCORRECT. The iso is discovered only for themselves; strange though it may seem to you, the distro itself then has to find its own iso via its OWN search routines (it cannot use the search routine of Ventoy - it is not part of Ventoy).

i.e. Create a directory called exactly /BOOTISOS on your Ventory disk, stick the KL distros into that, and they will most likely work. You don't need a copy of my Ventoy disk - that is the arrangement you need.

[Clarity]

ah-ha! I overlooked that:

SG2Dhas no problem with several that he looks for on a system and Ventoy could care less. But I DO remember now that you pointed that out and it probably is the difference.

Give a few moments to change the directory name to run that bare-metal test for at least the OT2 distro.

Back soon

[wiak]

ah-ha! I overlooked that:

SG2Dhas no problem with several that he looks for on a system and Ventoy could care less. But I DO remember now that you pointed that out and it probably is the difference.

Give a few moments to change the directory name to run that bare-metal test for at least the OT2 distro.

Back soon

Well, don't do your Ventoy test as part of a Qemu setup - I have no idea what the implications would be for that mix. And /BOOTISOS on the Ventoy disk has to be in a Linux formatted partition.

[Clarity]

it has worked in both. As shared with you before, my experiences has shown that the behavior seen in my QEMU tests mirror what I see on bare-metal. You can easily replicate with little to no effort if you choose.

I just tested by merely changing folder name in all 3 environments for the OT2 distro.

WORKS!!!

Thanks @wiak for that observation. I expect that the other KLs will also boot on that USB as well.

Lastly, an interesting observation is that, before, you correction to me, OT2 did NOT have a problem booting from Ventoy ->SG2D ISO -> KL...OT2.iso -> OT2 desktop as shown using that 'boot-isos' folder with no observable problem. Its important to note, TOO, that it continues to boot with the directory changed to 'BOOTISOS''. I am NOT asking for an answer of why it does boot in SG2D as it does with the old folder name and the changed folder name.

I agree that as coded, BOOTISOS works!!!

i THANK YOU for your reminding me of that naming. ... I had forgotten. It wont happen again.

[wiak]

Lastly, an interesting observation is that, before, you correction to me, OT2 did NOT have a problem booting from Ventoy ->SG2D ISO -> KL...OT2.iso -> OT2 desktop as shown using that 'boot-isos' folder with no observable problem. Its important to note, TOO, that it continues to boot with the directory changed to 'BOOTISOS''. I am NOT asking for an answer of why it does boot in SG2D as it does with the old folder name and the changed folder name.

Nevertheless, I'll provide the answer. SG2D passes the directory path over to the booting distro via loopback.cfg using exported variable ${iso_path}. All that FR initrd needs to do then is search for the partition where the iso is (so the directory doesn't matter for that SG2D case). Ventoy does not pass ANY information to the distro via any exported variables, hence, for Ventoy boot to work, FR initrd has to not only search for the partition where the iso is, but also for a particular directory; I only coded it to search in either /BOOTISOS or in / (on whatever partition it finds the actual iso) for simplicity of the additional search code.

[Clarity]

I am going to change this thread to SOLVED ... and will reopen ONLY if i run into other ISO file boot problems.

Actually, I do NOT expect any further boot issues booting KLs ISO distros using QEMU/Ventoy/SG2D.

This is just a note for any who read this thread as it covers several boot abilities for booting ISO files.

SG2D has a secret that I known about for several years. Booting it from a DVD it will search all drives for any folders that are named with any combination, uppercase or lowercase, folder-names that is lettered bootisos or boot-isos.

In my case, up to now, I have used this knowledge to my advantage as I will use different folder names so that is allows me a visual of which partition the ISO files it list reside. I had in the past used folder naming on system drives different from the USB sticks naming to easily identify folders locations at a glance. Most of the Dsitrowatch and forum distros had not exhibited this dilemma. this is primarity because of the ISO file notation mentioned by Wiak as well as the presence of the loopback.cfg in the grub2 boot folder chain.

I really appreciate this discovery and will reflect it in my documentation going forward.

If this folder-name search changes, please alert me and I will correct any documentation to match appropriately.

FOR NOW, I must be sure that I only PUT KLs on folder-named BOOTISOS as this will insure my KLs will not have issues.

Again THANKS @wiak

All of today's exercise is REALLY beneficial to a clearer understanding for me!

[wiak]

No worries Mate, as they for some reason say down here, but I'm scottish so I haven't a clue about the jargon.

[Clarity]

Thansk Mate. If I was close by, i share a beer and a Vegemite sandwich.

[Clarity]

The finding reported on this thread has been updated with NEW reports found here.

This is the OLD post from earlier on this thread.

Back to reporting.

Bare-Metal booting of the 5 KL's I've shown do not boot on my Ventoy USB stick. ...

See the NEW post showing current findings.