KLV-vmhost_rc4 Works with Lenovo Ideapad With 32 bit EFI

[JusGellin]

I brought out my old 2016 Lenovo Ideapad 100S-11IBY.
I bought this back then with hopes to not use its installed Windows, but to use linux.
It just wouldn't work back then.

This has a 32 bit EFI and 64 bit processor which made it difficult to boot up to linux until I came to this puppy linux site.
I was able to install BookwormPup64_10.0.7 on it. But to make it boot I had to remove any of 64 bit files used for booting.
So it did work.

I had made a frugal install of KLV-vmHost on a USB stick that works on three other more current laptops.
I decided to bring the old Lenovo out and try booting it up with this up to date KLV.

And to my surprise, it worked!
How can that be since the EFI is 32 bit?
It's running with a 6.10.10 kernel also.

I'm going to try installing KLV-vmHost directly on its internal drive which is an EMMC type to see if it can boot from there as well.

[JusGellin]

Please forget my praise for this.

Evidently it was using the internal drive to boot up the 2nd partition of the usb stick.

This computer continues to be a real pain

[rockedge]

What do the boot stanza's look like that are being used to boot the Ideapad with KLV-vmHost?

I feel like this should work so perhaps there is a trick in the boot stanza format that is being overlooked.......

[JusGellin]

What do the boot stanza's look like that are being used to boot the Ideapad with KLV-vmHost?

I feel like this should work so perhaps there is a trick in the boot stanza format that is being overlooked.......

I found that for the KLV to work on USB stick, I had to use grub2.06 version.
BookwormPup64_10.0.10_nkb uses this and this works for the USB stick and the internal drive.

But this doesn't help for the internal (EMMC type) drive for the KLV.

For the boot stanza for KLV, I'm using wd_grubconfig to determine the root partition.

Code: Select all

#####grub.cfg (note the UUID or LABEL options below):
menuentry "KLV-vmHost-rc4" {
  insmod ext2
  search --no-floppy --label linuxthumb --set
  linux /KLV-vmHost-rc4/vmlinuz w_bootfrom=LABEL=linuxthumb=/KLV-vmHost-rc4 w_changes=RAM2
  initrd /KLV-vmHost-rc4/initrd.gz
}
#############################OR uuid method:
menuentry "KLV-vmHost-rc4" {
  insmod ext2
  search --no-floppy --fs-uuid --set a765554d-3fdb-45ed-b868-d67edb694da0
  linux /KLV-vmHost-rc4/vmlinuz w_bootfrom=UUID=a765554d-3fdb-45ed-b868-d67edb694da0=/KLV-vmHost-rc4 w_changes=RAM2
  initrd /KLV-vmHost-rc4/initrd.gz
}

KLV boots, but it gets to where it can't access the boot partition and gives the following:

Code: Select all

[code]Seeking boot partition
Delay will be variable up to timeout of 30 seconds
Please wait: ..............................................................In initrd/init at seek_timeout.  Enter exit to continue:boot:
/#

It times out and stops.[/code]

So it looks like BookwormPup64_10.0.10_nkb works on the internal hard drive, but the KLV doesn't.

Thanks

[rockedge]

Are you using the initrd.gz that matches the kernel? Is this the stock kernel?

I see that same error when the initrd.gz is a skeleton version for huge kernels. The Void Linux kernels each have a specific initrd.gz

[JusGellin]

Are you using the initrd.gz that matches the kernel? Is this the stock kernel?

I see that same error when the initrd.gz is a skeleton version for huge kernels. The Void Linux kernels each have a specific initrd.gz

I'm using whatever was in the iso.
Is there a way to check it to see if it is for a specific kernel?

Thanks

[JusGellin]

I tried installing KLV-Airdale-sr16. I failed the same way.

[JusGellin]

Here's where this ancient laptop stands:
Installing different versions up to the current version of BookwormPup64 works fine for installing to the internal drive.
Plus installing this on a USB stick works as well.

Installing different KLV versions of vmhost and Airedale don't work on the internal drive, but it seems that only
the latest versions installed on a USB stick do work.

The later versions of Ventoy won't boot on a USB stick, but an earlier version , 1.0.96 will boot both KLV and BW

So bottom line, KLV can't find the internal drive, but BW has no problem booting up from it.

I was wondering if there are any grub.cfg settings that can help the KLV better find the internal drive, even though I'm specifically using the UUID to boot up.
Also, is there any way to capture the boot logs when a boot fails?
There seems to be a lot of information that goes by and could be useful to see what is happening.
Unfortunately when this pc fails, it stops dead with just a flashing cursor, so no troubleshooting can be done at that point.
That's a question as well - why can't it communicate using its keyboard when it fails?

One other thing that is good about this laptop, its battery still is in good shape holding a charge after all these years.

Thanks

[rockedge]

What type is the laptop's internal hard drive? Well have to start with the communication during the system start cycle that the initrd is having finding partitions.

[JusGellin]

What type is the laptop's internal hard drive? Well have to start with the communication during the system start cycle that the initrd is having finding partitions.

It's a 32G emmc type.
lsblk identifies it as device mmcblk1.

Thanks

[JusGellin]

I tried installing KLA-plasma-KDE-CE-1.4.
It fails like the KLVs.

So it kind of seems that Bookworm did something that solved this problem.
If that could be figured out and applied to the KLs, it would seem the laptop would work too.

[JusGellin]

It is intriguing how BookwormPup64 can boot up this laptop and KLs can't when the systems are installed to the internal emmc drive.

Is it the way initrd is built and if that were built similarly, the KLs could be built to make them work as well?
The place the KLs stop is:

Code: Select all

[code]Seeking boot partition
Delay will be variable up to timeout of 30 seconds
Please wait: ..............................................................In initrd/init at seek_timeout.  Enter exit to continue:boot:
/#

(why can't I type when it stops here like it is indicating I should?)

I can see when BW gets to this point that it hesitates for just a few seconds and then continues after it successfully finds the boot partition.

Thanks

----- As a side note: It sure is nice that now the puppy website is back to its normal fast self again - thanks @rockedge for figuring this out. ----

[rockedge]

@JusGellin Yes, we know there is code that deals with KL being installed to an internal emmc drive that is probably missing in the initrd. I think we must confer with @wiak on this one to start us off in the right direction.

Probably some small addition to the initrd to deal with the emmc type drives. We can examine what Bookwormpup is doing with the emmc types

All part of the progression forward as we find the flaws.....

[Clarity]

Hello

It is intriguing how ...

AS I remember you have a Ventoy USB. Tell me what happens when you use it to launch a KL, please. ALSO, what is the version of your Ventoy USB?

[JusGellin]

Hello

It is intriguing how ...

AS I remember you have a Ventoy USB. Tell me what happens when you use it to launch a KL, please. ALSO, what is the version of your Ventoy USB?

I can boot just about anything - BookwormPup64's and KLV's boot just fine using Ventoy - versions 1.1.05 and 1.0.99.
I can make a bootable USB stick with the installs of each of these and they boot fine.
I can frugal install BookwormPup64 on the internal emmc drive and it boots fine.

But any of the KL's fail when I try to install them on the internal emmc drive.
When it boots it gets to the place where it can't mount the boot partition and stops.
BookwormPup64 gets to the same place, hesitates briefly then continues on to successfully boot.

So it's just KL's that have a problem when they are installed on the internal emmc drive.
This is what the display shows where it stops:

Code: Select all

[code]Seeking boot partition
Delay will be variable up to timeout of 30 seconds
Please wait: ..............................................................In initrd/init at seek_timeout.  Enter exit to continue:boot:
/#

Thanks for looking at this.

[rockedge]

@JusGellin The problem is the code is not included that identifies that type of drive so the boot partition is not found.

I will discuss this with @wiak to add the bits of code needed in the initrd and add this capability.

[JusGellin]

Thanks @rockedge
I knew you said that before.

I was just responding to @Clarity so he could understand what was happening.

[fredx181]

@JusGellin and @rockedge

JusGellin , can you try booting KLV-vmhost_rc4 with this initrd.gz ? (it's for Void kernel 6.10.10_1):
https://dl.dropboxusercontent.com/scl/f ... 5a0ys&dl=1
To see if it works on your emmc drive.

To explain, few years ago there was same problem with DebianDog (not working on emmc).
I can't test myself, but I remember that it was fixed at some point, rcrsn51 confirmed at that time.

So there's chance that the above initrd.gz works on emmc, it has (similar as done for Debiandog) extended list of kernel modules to be "modprobe'd" in the init script.
edit: must say that the content of /usr/lib/modules in initrd.gz is also a little different (not much though), so if it works on emmc it may be because of that too.

[rockedge]

I can build a new initrd for a kernel and update/upgrade the root file system. Then add a Void Linux kernel that I can extract and then construct an initrd.gz for it. This might improve the failure to find an emmc type drive with the root file system partition on it.

[JusGellin]

@rockedge wrote:
JusGellin , can you try booting KLV-vmhost_rc4 with this initrd.gz ? (it's for Void kernel 6.10.10_1):
https://dl.dropboxusercontent.com/scl/f ... 5a0ys&dl=1
To see if it works on your emmc drive.

It didn't work and did the same as before.
.
I hope this works.

I can build a new initrd for a kernel and update/upgrade the root file system. Then add a Void Linux kernel that I can extract and then construct an initrd.gz for it. This might improve the failure to find an emmc type drive with the root file system partition on it.

Thanks to both of you.

[rcrsn51]

I tested this on a converted Chromebook with an emmc drive using the above uuid grub boot stanza. It worked fine.

I would suggest that you reformat the drive.

[JusGellin]

I tested this on a converted Chromebook with an emmc drive using the above uuid grub boot stanza. It worked fine.

I would suggest that you reformat the drive.

Did you have problems before?

I've reformatted many times with the same failure. It's only the KL's that fail.
BookwormPup doesn't fail with its original stanza.

I'm curious. What is your emmc device name?
When I run lsblk in BookwormPup, the drive is called mmcblk1
and the partitions are called mmcblk1p1 and mmcblk1p2.

Thanks

[rcrsn51]

Are you using the uuid of the PARTITION where the install was made?

[JusGellin]

Yes I do.
When I mentioned using lsblk I meant the device names.

[rcrsn51]

Those device names are standard for emmc drives. With what filesystem are you formatting the install partition?

[JusGellin]

I'm making the standard for EFI boot:
Drive GPT
Partition 1 - 300M fat32 boot esp
Partition 2 - Remainder of drive ext4

[rcrsn51]

Where exactly are you getting the uuid value for partition 2?

[Clarity]

@JusGellin I have just one more question-set and maybe you'll understand why.

Questions
When yu boot from Ventoy, are you able to save your session on the system drive? If so, when you reboot, does your distros find their sessions?

Reason I ask: I am NOT trying to address the boot issue when you do extractions to a system drive followed by booting. I trying to see if the running system, which Ventoy allows, has a drive related issue in your distro operational use.

Thanks in advance for your answer to the question presented.

BTW: I clearly understand what everyone else is saying and why. This is NOT an attempt to derail.

[JusGellin]

Where exactly are you getting the uuid value for partition 2?

When I install a KLV i use the script wd_grubconfig which matches the blkid command for getting the 2nd partition uuid.

[rcrsn51]

Boot off your usb drive, run blkid and confirm that the uuid is correct.

It sounds to me like your emmc drive is failing.