Unable to install KL to Lenovo Ideapad laptop

[williwaw]

here is grub atched as screenshot and under here is the menu.list

Gparted looks good from here. KL is the only install on this stick?

while booted into F96 and with the new KL stick plugged in, please run blkid and post the terminal output

a screenshot of the rox window when rox is opened to the install directory please, and

what exactly do you see reported on your screen when you try to boot the KL stick. (if you only have the one computer to work with), maybe a photo with your phone?

[wiak]

if you are still working with a non ventoy usb, posting your working F96 menu.lst would help. Also, if you do not see grub4dos, please report what you see instead. this is more likely a problem with your usb formatting instead of the iso, so a screenshot of gparted showing the disk would be nice.

...
# Frugal installed Puppy

title KLV-Spectr
find --set-root uuid () B058-F511
kernel /KLV-Spectr/vmlinuz w_bootfrom=UUID=B058-F511=/KLV-Spectr w_changes=RAM2
initrd /KLV-Spectr/initrd.gz

Hello @Gnimmelf

Sorry I was a bit short with you. I thought you were giving up without providing information requested and wrongly thus got the impression you were being a time-waster. Unfortunately we do get a few disgruntled trolling on KL threads and up to mischief. But wrong is wrong, and I see now that you are doing your best to boot that KL distro and I am sure we can manage, or if not at least learn what may be the issue.

But I think I do possibly see the problem. In the above menu.lst the UUID (and gparted result) show that you have installed onto a FAT32 (windows type format) usb stick. That will not work out of the box with KL distros which without special image save file creation will not work with w_changes=RAM2 mode of operation unless on a Linux formated (e.g. ext2) partition. I 'think', however, if you change that to w_changes=RAM2 to instead w_changes=RAM0, it might boot even though it is on FAT32 partition, but I haven't tested with FAT32 install for quite a while. There are two alternatives if w_changes=RAM0 doesn't work to at least boot your system:

1. Best is to make the install onto a Linux formated usb stick instead, in which case your above menu.lst would likely work. But I understand that in reformatting you would lose the grub installed on it and so nothing would work then, and fixing that complex to explain.

2. We could make a special, empty, save image file and put that in your frugal install folder to be used on boot. All going well that would work even though the install is on FAT32 partition (and also it would work with existing w_changes=RAM2 mode and thus allow save persistence). We will get back to you on how to do this if all else fails, but first I have a question:

You say you can boot F96, but I don't see F96 mentioned at all (no grub stanza for it) in your provided menu.lst. Do you have a usb stick with F96 on it that boots and if so, could you provide the menu.lst used to boot that F96 distro. That might be a better starting point for getting the KL distro booting too.

Finally, I note you are also trying Clarity's Ventoy image disk alternative. Maybe let's try that first and get back to menu.lst method if Ventoy fails for you? It's confusing discussing two methods all at same time I feel. So:

With Ventoy you say F96 is booting but KL is not. What we need to see is the 'Ventoy' folder contents to see where you have put the isos for F96 and the one for KL. We can then discuss what might be wrong. It may indeed be also that this particular KL distro is unable for other reasons to boot on your Lenovo, but we can track that down, which would be useful to us since might be something we could add to KL to allow it to boot on machines it currently fails on. Thanks, and sorry again for my earlier feeling of frustration.

[wiak]

By the way, I think KLV-Spectrum is still a beta release and thus not recommended for getting started with KL distros. In fact, I myself, have trouble booting KLV-Spectrum on my computer; I needed to even change the kernel from that supplied to get it to boot at all on my laptop, but even that hasn't proved perfect for me - I am getting regular freezes when I can no longer click on anything.

I therefore do not recommend anyone new to KL distros to start with KLV-Spectrum. Rather I'd say try one of the KLA distros, which no-one seems to have found any fault with, or KLV-Airedale which has been out for a while. Only thing I'd worry about with KLV-Airedale choice is that it also tends to be getting released with RT kernel, which may not boot for some people if my machine is anything to go by. So maybe best start choice would be either KLA-OT2baseCE as produced by Sofiya, or KLA-XFCEbase, which has never given me any problems.

As far as the usb stick used is concerned, the 'safe' bet for successful booting is DEFINITELY to use a usb stick that has been reformatted to use Linux format partition for any and all frugal installs from this forum. I suppose one way to arrange that would be if you have a Puppy booting like F96 you could plug in a second empty usb stick and format that say ext2 format, and then use Puppy install tools available in F96 to put grub2 bootloader on it (maybe to include another frugal install of Puppy F96 or similar). That's likely what I'd do if starting from scratch. Then I'd complete a KLV-OT2baseCE frugal install alongside that hopefully booting F96 on that new usbstick and find the grub.cfg and add the appropriate grub2 menuentry stanza for KLV-OT2baseCE. That should then be a useful usb stick that could contain several forum distros with less likely problem with booting since using Linux format, which is definitely the easiest and best for forum distro booting more generall. FAT32 formatted partition is definitely not recommended (and not with Ventoy iso holding partition either by the way - use Linux format!).

[Gnimmelf]

i see maybe the problem now - i created a new usb with f96 on it - installed almost exacly the same way as on my lenovos ssd.

the grub2 is installed on a small fat32 partition and the F96 on a ext4 patition.

on the usb se screenshot from Gparted.

the grub.cfg looks like:

#
set default=0
set timeout=5

set menu_color_normal='yellow/blue'
set menu_color_highlight='black/cyan'

if [ $grub_platform = 'efi' ]; then
loadfont /boot/grub/fonts/DejaVuSansMono18.pf2
set gfxmode=auto
terminal_output gfxterm
fi

menuentry "Puppy fossapup64 9.6" {
insmod ext2
search --no-floppy --fs-uuid --set=root 5e2e76f5-92f1-45da-ba5c-2b58cba40135
echo "Loading vmlinuz"
linux /F96/vmlinuz nomodeset pmedia=usbflash pdrv=5e2e76f5-92f1-45da-ba5c-2b58cba40135 psubdir=/F96 pfix=fsck,fsckp TZ=CET-1CEST,M3.5.0,M10.5.0/3
if [ -e /F96/local-initrd.gz ]; then
set local_rd=/F96/local-initrd.gz
else
set local_rd=
fi
if [ -e /F96/ucode.cpio ]; then
set ucode_rd=/F96/ucode.cpio
echo "Loading ucode.cpio and initrd.gz"
else
set ucode_rd=
echo "Loading initrd.gz"
fi
initrd $ucode_rd /F96/initrd.gz $local_rd
}
if [ $grub_platform = 'efi' ]; then
menuentry "System BIOS setup" {
fwsetup
}
fi
menuentry "Shutdown computer" {
halt
}
menuentry "Reboot computer" {
reboot
}

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

this is what works.......

so as i understand, there is a grub2/grub4 issue and maybe a fat32 issue?

I thought that i had a grub4 working - but i was wrong. booth on the laptop ssd and on the usb a grub2 is whats working......

does this help clarify?

Peace

kindly Gnimmelf

[Gnimmelf]

...
Hello @Gnimmelf

Sorry I was a bit short with you. I thought you were giving up without providing information requested and wrongly thus got the impression you were being a time-waster. Unfortunately we do get a few disgruntled trolling on KL threads and up to mischief. But wrong is wrong, and I see now that you are doing your best to boot that KL distro and I am sure we can manage, or if not at least learn what may be the issue.

Thanks, and sorry again for my earlier feeling of frustration.

No worries - All good - peace

[Gnimmelf]

Hey @Gnimmelf Hooray! We have launch! EVERYTING from this point forward is going to get easier and easier with no need to change boot stanzas, or anything to get to desktop of the ISO files you choose. More comfort and more options in use will arise.

OK, this sometimes will happen. I have a failsafe that I want you to use. It will boot things sometimes when a Ventoy boot fails. You will continue to boot ISO files. The failsafe merely adds a dimension that you find easy too.

Let's do this in 2 steps

1. Add another KL ISO file of your choice to the BOOTISOS folder. Try booting that added ISO from the list.

2. I want you to add a failsafe to the BOOTISOS folder

ADD another KL
There are 8 different KLs in this KL section of the forum. Choose any other(s) and download your choice(s) to the BOOTISOS folder. Boot and report your findings

FAILSAFE
The failsafe ISO (as I am calling it) is an ISO that I have found will boot all WoofCE PUPs and forum DOGs distros that struggle in Ventoy. AND, this failsafe works with all other WoofCE PUPs built and distributed across the forum.

The failsafe is here:

Place that ISO into the bootisos folder as well. I will give instructions on it after you have a little more success with booting the other ISOs.

BTW: what is the size of your USB? Mine is 64GB and I have many-many ISO files that I have the liberty of booting to desktop use.

P.S. I also want you to add a recent Ubuntu and/or Debian ISO file to your USB. I am confident that no matter what that ISO will boot as well on your laptop

i did the failsafe thing and it seems to work - how to proceed? to get the F96 to boot the Whole way i need to add "nomodeset" to the grub.cfg - could you show me how? i know how to in a regular usb install of F96!

[Clarity]

... only F96-ce and here i need the "nomodeset" in the grub.cfg. cant find the right place in ventoy to place it......?

I think this might help. On whichever boot manager you are using:

1. Select the ISO file you want to boot; say F96-CE for example

2. The ISO will display lines for its boot options

3. On the line that meets how you want the distro to emerge to desktop you will edit that line. In grub2 cases you will hit the "E" keyboard key to edit the stanza.

4. In the stanza, scroll-down to the linux line then scroll-right to an empty area and add your parm entry; say "nomodeset" to the line, for example "linux ... nomodeset"

5. hit keyboard F10 to allow distro to boot to desktop with your added parm to its stanza

Ventoy does not need a change as it merely launches the ISO files it finds on its media. So you are adjusting the F96-CE's boot stanza with any additional parms for the PC system you boot to. In this case, you PC will need this to boot. On other PCs this may not be needed.

Enjoy

[Clarity]

When you are comfortable with the methods for booting these distros, I want to share with you 2 features of KLs and the other forum distros what will make life even smoother.

Let me know when. Again we are not doing anything outlandish or complex. Everything you are and will do is rather simple...almost elementary.

[wiak]

i see maybe the problem now - i created a new usb with f96 on it - installed almost exacly the same way as on my lenovos ssd.

the grub2 is installed on a small fat32 partition and the F96 on a ext4 patition.

on the usb se screenshot from Gparted.

the grub.cfg looks like:
...
this is what works.......

so as i understand, there is a grub2/grub4 issue and maybe a fat32 issue?

I thought that i had a grub4 working - but i was wrong. booth on the laptop ssd and on the usb a grub2 is whats working......

does this help clarify?

Peace

kindly Gnimmelf

EDIT: If your Ventoy attempts prove successful, great, but if you want to also get normal frugal install working with that /F96 successfully grub2 booting usb stick you have then the following is the way to proceed:
------------------------------------------------------------------------------------

Okay, this is good. I think we may now be getting somewhere. I write the following with the understanding from what you say above that this grub2 usb stick is with the grub.cfg you pasted able to boot the F96 distro it includes? If so, please make a frugal install of KLV-Spectr-RT in a directory alongside the /F96 directory you successfully boot F96 with. i.e. make a directory /KLV-Spectr-RT sitting alongside /F96 and inside it extract the KLV-Spectr-RT iso.

Since (assuming) your F96 is booting okay then we already know the UUID of the partition you are using, which your posted grub.cfg shows as being UUID=5e2e76f5-92f1-45da-ba5c-2b58cba40135
On that basis please find attached a replacement for your (I presume) working grub.cfg on that usb stick; this new one contains exact same lines as before but with the additon of a correct stanza that should successfully boot KLV-Spectr-RT using that UUID of your usb stick ext4 partition (where you presumably have that /F96 and where you should also now put /KLV-Spectr-RT)

Assuming you are booted in F96 to do this work, first make a backup of the working grub.cfg (maybe simply call it grub.cfgBKUP) and then put the attached grub.cfg alongside it (but remember to rename to remove the dummy .tar extension; result should simply be called grub.cfg of course). Then reboot the usb stick and you should now have both a F96 menu choice and a KLV-Spectr-Rt menu choice. And try to boot the KLV. It should certainly start booting okay - if it fails then we have a different issue, which might be a problem with the KLV-Spectr-RT kernel not being good for your machne (but it might be fine... let's hope so). If KLV-Spectr-RT boot doesn't get there... then best for now would be to download a different KL distro that is not in beta stage; I really suggest trying KLA-XFCEbase (though KLA-OT2baseCE 'might' be okay too), and make a frugal install of one of these and we'll see what grub2 menu stanza is best for that new distro; but hopefully KLV-Spectr-RT will simply work and no need for the KLA alternative...

EDIT2: From what you say about F96, it is possible you may also need to add nomodeset to the grub.cfg line starting: linux /KLV-Spectr-RT/vmlinuz
i.e. maybe need to make that: linux /KLV-Spectr-RT/vmlinuz nomodeset etc etc etc as before...

[Clarity]

@wiak @Gnimmelf and others
All of my PCs are old.

My newest is an all Intel NUC Skull Lake with an i7 CPU. This system has NO internal system drive using USB drive for boot-media and storage. This system's display is via HDMI to a TV.

Because the 2 of you are using rather late model laptops, I decided to take down the @fatdog that had been running for over a year on it, update my Ventoy disk with the latest ventoy, and add current models of KLs and PUPs.

Findings:
On this PC, Ventoy boots couple of the WoofCE PUPs booting directly from its menu. BUT, KLs are not.

1. They get to last line of "Run /vtoy /vtoy ..."

2. then next line "..... cant umount /mnt/sda1"

3. TRAP!

On subsequent boot, using Ventoy to launch SG2D the KL's wont boot there either.

I thought, wrongly, that it might be due to ventoy being a default MSDOS ventoy create. So I made another ventoy USB with both GPT and Secure-boot. But, same findings.

I am suspecting hardware, but not sure. I will test the 2 USB Ventoy disks on my old test PCs attached to the VGA monitor when I awaken. I need some sleep. Expect a report after I get about 6 hours of sleep.

FYI

[wiak]

@wiak @Gnimmelf and others
...
Findings:
On this PC, Ventoy boots couple of the WoofCE PUPs booting directly from its menu. BUT, KLs are not.

1. They get to last line of "Run /vtoy /vtoy ..."

2. then next line "..... cant umount /mnt/sda1"

3. TRAP!

On subsequent boot, using Ventoy to launch SG2D the KL's wont boot there either.

I thought, wrongly, that it might be due to ventoy being a default MSDOS ventoy create. So I made another ventoy USB with both GPT and Secure-boot. But, same findings.

Thanks for the report Clarity. In a way, this is why I suggest, if using Ventoy @Grimmelf uses an older KL distro such as KLA-XFCEbase, which is stable and boots on most machines with Ventoy because I carefully crafted its grub.cfg (along with similarly carefully crafted menu.lst and loopback.cfg for the likes of SGD2) such that they worked extremely well with Ventory, including persistence with RAM2 mode.

Following you above report, I have downloaded KLV-Spectre-RT iso and put it on my old Ventoy usb stick. It does NOT boot...

The reason is simple, the iso grub.cfg, menu.lst and loopback.cfg (in the iso /boot/grub folder) DO NOT contain the special codings I made such that they would always work in Ventoy; i.e. the guys putting the iso together have made a blunder... I have not checked recent KLV-Airedale and so on, so do not know if they also are not having these key files assembled correctly. Nothing I can do about it in posts here since requires the isos to be rebuilt the way I instructed rockedge and co earlier. I would be surprised if @rockedge would make the mistake since he is well familiar with the correct code for this, but others, who are not using Ventoy, may not have realized how important getting these key boot files correct is... hmmm.......

To rockedge, Sofiya and whoever is uploading isos. I give this example from successful KLU-jam-XFCEbase iso/boot/grub, which is another distro of mine that continues to boot successfully in Ventoy. Each of /boot/grub: grub.cfg, menu.lst and loopback.cfg contain lines of the following form:

Code: Select all

set distname=KLU-jam-XFCEbase
set revision=1.0
set savepart=Persistence
set savedir=Sessions
set bootlabel=Ventoy

and the following stanzas in these config files refer to these variables. Without that carefully made organization I instigated, Ventoy booting will fail, which seems to be the issue now. In other words, that mistake is a huge regression that destroys the excellent way previous KL releases worked with Ventoy and so the matter urgently needs to be addressed. To developers who produce KL isos I thus ask you to please refer to the structure of these critical boot files as used in my KLU-jam-XFCEbase and KLA-XFCEbase to see the correct way to make them; you are currently totally breaking Ventoy support in your KL iso releases by not using that essential structure.

[rockedge]

@wiak the reason the /boot directory is not set up with the same as KLV-Airedale, which has the correct Ventoy friendly boot code is because of the rapid development of the ISO a temporary /boot was inserted so I could get the ISO to boot on QEMU.

NO attempt has been made yet to work out the ISO boot kinks on the latest ISO's BUT rest assured, some testing has been done to have the same carefully crafted boot stanza's and to see that it works. There was trouble getting the KLV-Airedale /boot to work consistently during the building process of KLV-Spectr hence the usage of far simpler boot stanza's.

All this is to say ALL OF THESE ARE EXPERIMENTAL and the /boot directory is NOT fully sorted out yet for KLV-Spectr. @Clarity how about offering a fixed up /boot instead of complaining about it? Still not sure if any of the KL's will boot as is on UEFI systems.

Main point here is KLV-Spectr-RT is not finished yet, and it's original design IS FOR FRUGAL INSTALLATIONS and those have no need for the /boot directory at all. The fact at all that there is a booting ISO is solely for the convenience of launching a sample in a QEMU machine quickly and not CONSTANTLY REBOOTING MY BARE METAL machinery. So the Ventoy stuff is secondary and of minor importance at this time.

[Gnimmelf]

heureka! i did it (with the help from you.... )

here under is the grub.cfg

KLV -Bspwm (1.2) boots but have wifi isues
KLV-Bspwm-1.5 says "kernel panic" doesnt boot.
KLV-Airedale boots and runs
KLV-spectr -RT says "you need to load the kernel first"
Puppy fossapup64 9.6 boots and runs

thats what i tried so far i now understand why i coulndt figure it out - and i understand why you all said it was easy

hope it is usefull

kindly Gnimmelf

--------------------------------------------------------------------------------------------------------------------------------------------------------

#
set default=0
set timeout=5

set menu_color_normal='yellow/blue'
set menu_color_highlight='black/cyan'

if [ $grub_platform = 'efi' ]; then
loadfont /boot/grub/fonts/DejaVuSansMono18.pf2
set gfxmode=auto
terminal_output gfxterm
fi

menuentry "KLV-Bspwm" {
insmod ext2
search --no-floppy --fs-uuid --set 5e2e76f5-92f1-45da-ba5c-2b58cba40135
linux /KLV-Bspwm/vmlinuz w_bootfrom=UUID=5e2e76f5-92f1-45da-ba5c-2b58cba40135=/KLV-Bspwm w_changes=RAM2
initrd /KLV-Bspwm/initrd.gz
}

menuentry "KLV-Bspwm-1.5" {
insmod ext2
search --no-floppy --fs-uuid --set 5e2e76f5-92f1-45da-ba5c-2b58cba40135
linux /KLV-Bspwm-1.5/vmlinuz w_bootfrom=UUID=5e2e76f5-92f1-45da-ba5c-2b58cba40135=/KLV-Bspwm-1.5 w_changes=RAM2
initrd /KLV-Bspwm-1.5/initrd.gz
}

menuentry "KLV-Airedale" {
insmod ext2
search --no-floppy --fs-uuid --set 5e2e76f5-92f1-45da-ba5c-2b58cba40135
linux /KLV-Airedale/vmlinuz w_bootfrom=UUID=5e2e76f5-92f1-45da-ba5c-2b58cba40135=/KLV-Airedale w_changes=RAM2
initrd /KLV-Airedale/initrd.gz
}

menuentry "KLV-spectr -RT" {
insmod ext2
search --no-floppy --fs-uuid --set 5e2e76f5-92f1-45da-ba5c-2b58cba40135
linux /KLV-spectr -RT/vmlinuz nomodeset w_bootfrom=UUID=5e2e76f5-92f1-45da-ba5c-2b58cba40135=/KLV-spectr -RT w_changes=RAM2
initrd /KLV-spectr -RT/initrd.gz
}

menuentry "Puppy fossapup64 9.6" {
insmod ext2
search --no-floppy --fs-uuid --set=root 5e2e76f5-92f1-45da-ba5c-2b58cba40135
echo "Loading vmlinuz"
linux /F96/vmlinuz nomodeset pmedia=usbflash pdrv=5e2e76f5-92f1-45da-ba5c-2b58cba40135 psubdir=/F96 pfix=fsck,fsckp TZ=CET-1CEST,M3.5.0,M10.5.0/3
if [ -e /F96/local-initrd.gz ]; then
set local_rd=/F96/local-initrd.gz
else
set local_rd=
fi
if [ -e /F96/ucode.cpio ]; then
set ucode_rd=/F96/ucode.cpio
echo "Loading ucode.cpio and initrd.gz"
else
set ucode_rd=
echo "Loading initrd.gz"
fi
initrd $ucode_rd /F96/initrd.gz $local_rd
}
if [ $grub_platform = 'efi' ]; then
menuentry "System BIOS setup" {
fwsetup
}
fi
menuentry "Shutdown computer" {
halt
}
menuentry "Reboot computer" {
reboot
}

[Gnimmelf]

@wiak @Gnimmelf and others
...
Findings:
On this PC, Ventoy boots couple of the WoofCE PUPs booting directly from its menu. BUT, KLs are not.

1. They get to last line of "Run /vtoy /vtoy ..."

2. then next line "..... cant umount /mnt/sda1"

3. TRAP!

On subsequent boot, using Ventoy to launch SG2D the KL's wont boot there either.

I thought, wrongly, that it might be due to ventoy being a default MSDOS ventoy create. So I made another ventoy USB with both GPT and Secure-boot. But, same findings.

Thanks for the report Clarity. In a way, this is why I suggest, if using Ventoy @Grimmelf uses an older KL distro such as KLA-XFCEbase, which is stable and boots on most machines with Ventoy because I carefully crafted its grub.cfg (along with similarly carefully crafted menu.lst and loopback.cfg for the likes of SGD2) such that they worked extremely well with Ventory, including persistence with RAM2 mode.

Following you above report, I have downloaded KLV-Spectre-RT iso and put it on my old Ventoy usb stick. It does NOT boot...

The reason is simple, the iso grub.cfg, menu.lst and loopback.cfg (in the iso /boot/grub folder) DO NOT contain the special codings I made such that they would always work in Ventoy; i.e. the guys putting the iso together have made a blunder... I have not checked recent KLV-Airedale and so on, so do not know if they also are not having these key files assembled correctly. Nothing I can do about it in posts here since requires the isos to be rebuilt the way I instructed rockedge and co earlier. I would be surprised if @rockedge would make the mistake since he is well familiar with the correct code for this, but others, who are not using Ventoy, may not have realized how important getting these key boot files correct is... hmmm.......

To rockedge, Sofiya and whoever is uploading isos. I give this example from successful KLU-jam-XFCEbase iso/boot/grub, which is another distro of mine that continues to boot successfully in Ventoy. Each of /boot/grub: grub.cfg, menu.lst and loopback.cfg contain lines of the following form:

Code: Select all

set distname=KLU-jam-XFCEbase
set revision=1.0
set savepart=Persistence
set savedir=Sessions
set bootlabel=Ventoy

and the following stanzas in these config files refer to these variables. Without that carefully made organization I instigated, Ventoy booting will fail, which seems to be the issue now. In other words, that mistake is a huge regression that destroys the excellent way previous KL releases worked with Ventoy and so the matter urgently needs to be addressed. To developers who produce KL isos I thus ask you to please refer to the structure of these critical boot files as used in my KLU-jam-XFCEbase and KLA-XFCEbase to see the correct way to make them; you are currently totally breaking Ventoy support in your KL iso releases by not using that essential structure.

could not boot KLV-Airedale-Bspwm-Spectr-RT on ventoy - only F96-ce and here i need the "nomodeset" in the grub.cfg. cant find the right place in ventoy to place it......?

[williwaw]

heureka! i did it (with the help from you.... :thumbup: )

here under is the grub.cfg

KLV -Bspwm (1.2) boots but have wifi isues
KLV-Bspwm-1.5 says "kernel panic" doesnt boot.
KLV-Airedale boots and runs
KLV-spectr -RT says "you need to load the kernel first"
Puppy fossapup64 9.6 boots and runs

is there a space in either the directory name or the respective boot stanza?
a space in either place will cause the boot to fail

[Gnimmelf]

heureka! i did it (with the help from you.... )

here under is the grub.cfg

KLV -Bspwm (1.2) boots but have wifi isues
KLV-Bspwm-1.5 says "kernel panic" doesnt boot.
KLV-Airedale boots and runs
KLV-spectr -RT says "you need to load the kernel first"
Puppy fossapup64 9.6 boots and runs

is there a space in either the directory name or the respective boot stanza?
a space in either place will cause the boot to fail

i dont see any?

#
set default=0
set timeout=5

set menu_color_normal='yellow/blue'
set menu_color_highlight='black/cyan'

if [ $grub_platform = 'efi' ]; then
loadfont /boot/grub/fonts/DejaVuSansMono18.pf2
set gfxmode=auto
terminal_output gfxterm
fi

menuentry "KLV-Bspwm" {
insmod ext2
search --no-floppy --fs-uuid --set 5e2e76f5-92f1-45da-ba5c-2b58cba40135
linux /KLV-Bspwm/vmlinuz w_bootfrom=UUID=5e2e76f5-92f1-45da-ba5c-2b58cba40135=/KLV-Bspwm w_changes=RAM2
initrd /KLV-Bspwm/initrd.gz
}

menuentry "KLV-Bspwm-1.5" {
insmod ext2
search --no-floppy --fs-uuid --set 5e2e76f5-92f1-45da-ba5c-2b58cba40135
linux /KLV-Bspwm-1.5/vmlinuz w_bootfrom=UUID=5e2e76f5-92f1-45da-ba5c-2b58cba40135=/KLV-Bspwm-1.5 w_changes=RAM2
initrd /KLV-Bspwm-1.5/initrd.gz
}

menuentry "KLV-Airedale" {
insmod ext2
search --no-floppy --fs-uuid --set 5e2e76f5-92f1-45da-ba5c-2b58cba40135
linux /KLV-Airedale/vmlinuz w_bootfrom=UUID=5e2e76f5-92f1-45da-ba5c-2b58cba40135=/KLV-Airedale w_changes=RAM2
initrd /KLV-Airedale/initrd.gz
}

menuentry "KLV-spectr -RT" {
insmod ext2
search --no-floppy --fs-uuid --set 5e2e76f5-92f1-45da-ba5c-2b58cba40135
linux /KLV-spectr -RT/vmlinuz nomodeset w_bootfrom=UUID=5e2e76f5-92f1-45da-ba5c-2b58cba40135=/KLV-spectr -RT w_changes=RAM2
initrd /KLV-spectr -RT/initrd.gz
}

menuentry "Puppy fossapup64 9.6" {
insmod ext2
search --no-floppy --fs-uuid --set=root 5e2e76f5-92f1-45da-ba5c-2b58cba40135
echo "Loading vmlinuz"
linux /F96/vmlinuz nomodeset pmedia=usbflash pdrv=5e2e76f5-92f1-45da-ba5c-2b58cba40135 psubdir=/F96 pfix=fsck,fsckp TZ=CET-1CEST,M3.5.0,M10.5.0/3
if [ -e /F96/local-initrd.gz ]; then
set local_rd=/F96/local-initrd.gz
else
set local_rd=
fi
if [ -e /F96/ucode.cpio ]; then
set ucode_rd=/F96/ucode.cpio
echo "Loading ucode.cpio and initrd.gz"
else
set ucode_rd=
echo "Loading initrd.gz"
fi
initrd $ucode_rd /F96/initrd.gz $local_rd
}
if [ $grub_platform = 'efi' ]; then
menuentry "System BIOS setup" {
fwsetup
}
fi
menuentry "Shutdown computer" {
halt
}
menuentry "Reboot computer" {
reboot
}

[wiak]

heureka! i did it (with the help from you.... )

here under is the grub.cfg

KLV -Bspwm (1.2) boots but have wifi isues
KLV-Bspwm-1.5 says "kernel panic" doesnt boot.
KLV-Airedale boots and runs
KLV-spectr -RT says "you need to load the kernel first"
Puppy fossapup64 9.6 boots and runs

is there a space in either the directory name or the respective boot stanza?
a space in either place will cause the boot to fail

i dont see any?

Well, that's a big success overall; excellent. However:

You have wrong spaces in this one:

linux /KLV-spectr -RT/vmlinuz nomodeset w_bootfrom=UUID=5e2e76f5-92f1-45da-ba5c-2b58cba40135=/KLV-spectr -RT w_changes=RAM2

both at beginning for vmlinuz (so won't be found) and after UUID=XXXX=

Should be:

linux /KLV-spectr-RT/vmlinuz nomodeset w_bootfrom=UUID=5e2e76f5-92f1-45da-ba5c-2b58cba40135=/KLV-spectr-RT w_changes=RAM2
=============================

You might like to also try:

KLU-jamXFCEbase and KLA-XFCEbase; Arch and Ubuntu are pretty nice distros. There are other nice alternatives under KL. I don't know about the status of most of the new most recent beta builds such as KLV-spectr-RT and KLV-Bspwm, but yes, be careful with spaces and specially in names; computers are completely unforgiving, which is the most frustrating thing about them (the exception being google search engine which tries to guess what you mean and so on!).

[Clarity]

Hello @Gnimmelf

Here's is a KL distro that I would like you to test on your Ventoy USB. Add the ISO file to your BOOTISOS folder. Then, merely boot your USB, select this KL ISO and allow it to boot.

The KL's ISO file is here in this area of the forum.

Report your observation back here. Thanks

[wiak]

@wiak the reason the /boot directory is not set up with the same as KLV-Airedale, which has the correct Ventoy friendly boot code is because of the rapid development of the ISO a temporary /boot was inserted so I could get the ISO to boot on QEMU.

But the problem is, for some reason I don't understand and certainly don't maintain or support, you are using an extremely old version of FR initrd.gz in your recent iso builds (at least in KLV-Spectr-Rt).

I opened the iso and checked and you are using:

version="5.0.2"; revision="-rc2" Date: 12 Feb 2022

whereas the only supported initrd/init for over six months now is:

version="7.0.1"; revision="-rc1" Date: 09 Mar 2023

Of course you may well have found it difficult to boot using the recommended stanzas for grub.cfg, menu.lst and loopback.cfg using that old initrd and only that latest FR initrd would correctly find isos in Ventoy BOOTISOS folder, which is a side-issue certainly, but still: why using an unsupported ancient FR initrd? I have a feeling it is by "mistake" .

[wiak]

I've modified the grub configs (grub.cfg, menu.lst, and loopback.cfg) and provided an alternative KLV-Spectr-Rt-17Oct2023.iso (was the latest last time I looked), which boots in Ventory and uses latest FR initrd.gz in case this is helpful to build team or anyone wanting to test in Ventoy.

If there is some Qemu functionality not available, that should just be a matter of alternative menu.lst stanzas; please let me know if that is the case and I'll look into the matter.

For now you can download the iso from here:

https://mega.nz/file/JvETiAja#OT9c2nY6S ... 89VLP95DXM

md5sum ef44dd821c54e55329a1f86e41096ee8 KLV-Spectr-Rt-17Oct2023.iso 669MiB

[rockedge]

version="7.0.1"; revision="-rc1" Date: 09 Mar 2023

Now I am confused.

I've been using the skeleton initrd that the is marked "latest" and is retrieved by the kernel initrd build script. I've been moving stuff around so often building and testing and reusing stuff that something might have crept in. For example beta3 has a brand new Void Linux kernel I just constructed using the Firstrib build script and the on the command line "latest firstrib_rootfs" is included. So I am dependent that this is retrieving the correct version. KLV-Airedale worked well on Ventoy I thought.

All very disappointing. I can withdraw all of them until some other time.

[wiak]

version="7.0.1"; revision="-rc1" Date: 09 Mar 2023

Now I am confused.

I've been using the skeleton initrd that the is marked "latest" and is retrieved by the kernel initrd build script. I've been moving stuff around so often building and testing and reusing stuff that something might have crept in. For example beta3 has a brand new Void Linux kernel I just constructed using the Firstrib build script and the on the command line "latest firstrib_rootfs" is included. So I am dependent that this is retrieving the correct version. KLV-Airedale worked well on Ventoy I thought.

All very disappointing. I can withdraw all of them until some other time.

Which kernel initrd build script are you referring to rockedge. As far as I've noticed previously, KLV-Airedale was using 7.0.1 -rc1, I was really surprised only to notice that KLV-Spectr-RT was using such an old release. If you download from firstrib gitlab the initrd available there is 7.0.1 -rc1, not a very old indeed version="5.0.2"; revision="-rc2" Date: 12 Feb 2022. You've also been using some version 6-plus FR initrds in earlier KLV-Airedales so how come the regression back to 5.0.2 occurred?
It could be that some scripts are needing updated that I don't know about, but it is important to always check versions during development builds to help avoid such issues. Gitlab site is the only central store that should be trusted of course - I can't maintain multiple sites, some of which contain old scripts.

[wiak]

The last KLV-Airedale iso I have on this laptop is KLV-Airedale-sr5 and I just now checked its FR intird version which is:

version="7.0.1"; revision="-rc1" Date: 09 Mar 2023

You made that one too, and were using the latest initrd at that time...

[rockedge]

@wiak This is from the initrd.gz in KLV-Airedale-sr6 ->

Code: Select all

# initrd/init: simple switch_root init with overlay filesystem set up.
# Copyright William McEwan (wiak) 26 July 2019+; Licence MIT (aka X11 license)
# version="7.0.1"; revision="-rc1" Date: 09 Mar 2023

This is the initrd.gz in the current KLV-Spectr-RT ->

Code: Select all

# initrd/init: simple switch_root init with overlay filesystem set up.
# Copyright William McEwan (wiak) 26 July 2019+; Licence MIT (aka X11 license)
# version="7.0.1"; revision="-rc1" Date: 09 Mar 2023

So I am not sure what is going on here.

The ISO though has version 5...which is really odd.

[wiak]

@wiak This is from the initrd.gz in KLV-Airedale-sr6 ->

Code: Select all

# initrd/init: simple switch_root init with overlay filesystem set up.
# Copyright William McEwan (wiak) 26 July 2019+; Licence MIT (aka X11 license)
# version="7.0.1"; revision="-rc1" Date: 09 Mar 2023

This is the initrd.gz in the current KLV-Spectr-RT ->

Code: Select all

# initrd/init: simple switch_root init with overlay filesystem set up.
# Copyright William McEwan (wiak) 26 July 2019+; Licence MIT (aka X11 license)
# version="7.0.1"; revision="-rc1" Date: 09 Mar 2023

So I am not sure what is going on here.

The ISO though has version 5...which is really odd.

The FR make initrd scripts haven't been checked for many months. Maybe something happened using official Void kernel, if that's where you think it occurred. I'll check gitlab now and report back

[wiak]

Current FRmake_initrd.sh uses:

wget -c https://owncloud.rockedge.org/index.php ... k/download -O initrd-latest.gz

which is not optimum. I remember saying I hadn't time to fix all that till early 2024, but nevertheless the initrd-latest.gz from your owncloud still is 7.01 version so that doesn't seem to be what is causing the problem. I'll check the other related scripts.

EDIT: No, they all seem to be using correct initrd so I don't see where you are getting that old 5.x.x one from. Could you check the script you are using to ascertain what is happening please? Seems to just be recent since that KLV-Airedale was correct one, but the one with your RT kernel is using old initrd too.

EDIT2: Sofiya's latest KLA-OT2baseCE iso is also correctly using: version="7.0.1"; revision="-rc1" Date: 09 Mar 2023

[rockedge]

Now just kernel panic........I broke something that worked.......Ahhhhhhhhhh

This worked now

Code: Select all

set distname=KLV-Spectr
set revision=RT
set savepart=Persistence
set savedir=Sessions
set bootlabel=QEMU

with this:

Code: Select all

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

[wiak]

Now just kernel panic........I broke something that worked.......Ahhhhhhhhhh

I think I found one culprit. It is sofiya fetching initrd from own repo (but wrong version)... tut tut tut

In Sofiya's KLV-BspwmCE-1.5 Stable, which Sofiya builds from script and uses:

Code: Select all

wget -c https://gitlab.com/sofija.p2018/kla-ot2/-/raw/main/KLV-Bspwm/Kernel-6-1-38-rock-rt13c/initrd.gz -O initrd.gz

and guess what... hmmm that initrd.gz uses:

version="5.0.2"; revision="-rc2" Date: 12 Feb 2022

But seems to suggest something to do with your store for 6-1-38 kernel components???!!!!

I can only suggest you that for core FirstRib boot components and build components you always use the latest from FirstRib gitlab site, and not rely on your own stored elsewhere copies. I note you have several FR initrd at main site rockedge, some named initrd-latest, but version 6.x.x. I still don't know why sofiya is ending up with a 5.0.2 which is also now appearing in your own builds...

[rockedge]

I think the KLV-Spectr-RT is now using the same /boot as KLV-Airedale-sr6 and the ISO is remade with the above parameters, which is booting in QEMU now with persistence

[wiak]

I think the KLV-Spectr-RT is now using the same /boot as KLV-Airedale-sr6 and the ISO is remade with the above parameters, which is booting in QEMU now with persistence

I don't understand. Why is old FR initrd 5.0.2 suddenly getting used when it wasn't before. What script is bringing that in. Anyway, it is an error.

As I said, Sofiya, is also fetching an old FR initrd for use in KLV-Bspwm...! Where is that old one being stored? I suggest wiping such stores out. Use official FR gitlab for core pieces is clearly safer and better build approach for FirstRib core components (not always for kernels since I don't myself make these anyway).

It is always essential to check versions. initrd-latest is only a simplification naming of course for generic script operation; I've always said you should physically view the w_init top lines to double-check the actual version, but at FirstRib gitlab latest build scripts folder the initrd-latest really IS the latest since I keep that up to date.