KLV-vmhost_rc4 Works with Lenovo Ideapad With 32 bit EFI

[JusGellin]

One more question for you @JusGellin: I've reviewed this thread and I dont see what is the size of your eMMC. Would you share that with us along with your posting results of saving the session when booting from your Ventoy USB?

Thanks

emmc drive is 32G
For the Lenovo, I have a third partition named Persistence with a folder called Sessions
For the Ventoy usb stick, on partition 1,there is a folder called BOOTISOS contining all the isos and also SG2D.iso

When booting and selecting Ventoy RAM0 no persistence, it boots KLV-vmHost properly
When booting and selecting Ventoy Ram2 save on demand to Persistence_Sessions, it gives the same response when installed on emmc drive:

Code: Select all

Seeking boot partition
Please wait: ..............................................................In initrd/init at seek_timeout.  Enter exit to continue:boot:
/#

[rcrsn51]

[Update] After loading the sdhci_acpi module, I typed "exit". The machine booted successfully to the desktop.

But JusGellin cannot test this because his keyboard locks up.

[fredx181]

Progress.

On my working Chromebook, I ran "lsmod | grep mmc" and got the list of related modules.

On the machine that fails to boot, I ran the same command. The module sdhci_acpi was missing. I ran "modprobe sdhci_acpi" followed by "blkid". The emmc partitions were now listed.

The initrd.gz that I provided for to test for JusGellin here: viewtopic.php?p=143991#p143991 (generated very similar as done for Debian Dog) does have sdhci_acpi in the modprobe module list, and also sdhci-acpi.ko is present in usr/lib/modules in that initrd.gz .

For info, the module list in the init script:

Code: Select all

for m in overlay arc4 cb710 cb710_mmc cdrom crc16 crc32c_generic crc32_generic crc_itu_t cryptd crypto_simd dm_mod dns_resolver ehci_hcd ehci_pci ext2 ext4 fat exfat fuse hid hid_generic i2c_algo_bit ip6_udp_tunnel isofs jbd2 libahci libcrc32c loop lrw mbcache mmc_block mmc_core mptscsih mptspi nls_ascii nls_cp437 nls_iso8859_1 nls_utf8 vmd ohci_hcd parport scsi_mod scsi_transport_sas scsi_transport_spi sdhci sdhci_acpi sdhci_pci sdhci_pltfm sdio_uart sd_mod sg squashfs sr_mod tifm_core tifm_sd tpm uas udp_tunnel uhci_hcd uio usb_common usbcore usbhid usb_storage vfat via_sdmmc vub300 wbsd xhci_hcd xhci_pci xor ahci ata_generic ata_piix sata_mv sata_nv sata_promise sata_qstor sata_sil sata_sil24 sata_sis sata_svw sata_sx4 sata_uli sata_via sata_vsc pata_acpi pata_ali pata_amd pata_artop pata_atiixp pata_atp867x pata_cmd64x pata_efar pata_hpt366 pata_hpt37x pata_it8213 pata_it821x pata_jmicron pata_marvell pata_mpiix pata_netcell pata_ns87410 pata_ns87415 pata_oldpiix pata_opti pata_pdc2027x pata_pdc202xx_old pata_rdc pata_rz1000 pata_sch pata_serverworks pata_sil680 pata_sis pata_triflex pata_via pcmcia_core pcmcia_rsrc raid6_pq reiserfs rng_core btrfs megaraid_sas scsi_transport_sas megaraid_mbox mptspi scsi_transport_spi scsi_transport_srp nvme ; do

But still JusGellin reported that it didn't work.
edit: @rcrsn51 can you try that initrd.gz too for your tests ?

[rcrsn51]

edit: @rcrsn51 can you try that initrd.gz too for your tests ?

Yes, that initrd.gz works for me.

[rockedge]

@JusGellin

Would it be possible to boot KLVvmHost from a USB drive on the computer with the internal emmc drive and in a terminal try:

Code: Select all

modprobe sdhci_acpi

and see if the emmc partitions show up?

[JusGellin]

@JusGellin

Would it be possible to boot KLVvmHost from a USB drive on the computer with the internal emmc drive and in a terminal try:

Code: Select all

modprobe sdhci_acpi

and see if the emmc partitions show up?

They show up right away without having to modprobe sdhci_acpi:

Code: Select all

mmcblk2
|-mmcblk2p1
|-mmcblk2p2
-mmblk2p3
mmcblk2boot0
mmcbk2boot1

I think I see mmcblk2 as also as mmcblk1

[JusGellin]

@@Clarity
When I run Ventoy and select SG2D.iso on this laptop, and then select Detect and show boot methods, I just get a blank display

[JusGellin]

@rockedge @rcrsn51
I just noticed something peculiar.
When I boot using Ventoy or a frugal install on a usb stick,
I noticed that if Bookworm is booted up and lsblk is run that the emmc drive is designated with a 1 as mmcblk1
If I boot a KLV type the emmc drive is designated with a 2 as in mmcblk2

I need to look further to see if this is consistent.

[JusGellin]

Looking a little further, even though the device names are different, the UUID's are still the same.

[rcrsn51]

I noticed that if Bookworm is booted up and lsblk is run that the emmc drive is designated with a 1 as mmcblk1

This behaviour is common with emmc drives, particularly if you do warm restarts instead of cold boots. That's why uuid's are important.

[Clarity]

@@Clarity
When I run Ventoy and select SG2D.iso on this laptop, and then select Detect and show boot methods, I just get a blank display

BKWP64 v10 view of Ventoy USB.jpg (49.94 KiB) Viewed 1394 times

It may be time to post this problem to SG2D's author.

[rcrsn51]

@Clarity : While we all enjoy another Ventoy/SG2D adventure, you should recognize that it has nothing to do with JusGellin's actual problem.

@rockedge : It looks like JusGellin's situation has reached an impasse. I tested some other KL distros on my second emmc machine and they had the same boot failure as JusGellin. But in every case, I could fix it by loading the sdhci_acpi module.

I am surprised that Fred's init did not fix the problem for JusGellin. I have used Fred's DebianDog version successfully on many emmc units. Without more participation from other emmc owners, it's hard to know how widespread the problem is.

As you know, I am a strong believer in the importance of beta testing and have often been criticized as being "unreasonable". What I see here is a whole family of distros with a common problem that could have been detected early on with more testing.

OTOH, if you don't see emmc machines as a significant part of your target audience, it doesn't really matter.

Bill

[wiak]

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

Exactly. Lot of fuss and criticism about next to nothing. Can easily add in missing module. Different hardware situation, similar problems can arise. Anyway, existing initrd is fine since there is a grub kernel line for adding in any extra module that may be required even if not included in the current initrd module list. Used to work anyway (if not, then I'd have to fix that):

w_addmodule="blahblahblah"

so the whole family of distros with a common problem tut tut tut... might work afterall simply by using grub kernel extra argument:

w_addmodule="sdhci_acpi"

Do let me know, but of course can be added permanently if already confirmed. No sweat.

[rockedge]

@JusGellin @rcrsn51

This looks to be the "fix" for your boot situation. Add this to the kernel command line in the boot stanza's

Code: Select all

w_addmodule="sdhci_acpi"

Turned out it was a small addition to the boot stanza using an option already built in.

[rcrsn51]

Exactly. Lot of fuss and criticism about next to nothing. Can easily add in missing module.

Assuming that you have a community member who has the resources and is willing to track down the missing module.

Code: Select all

sdhci_acpi

This information came from the work done here.

Do let me know, but of course can be added permanently if already confirmed. No sweat.

I took the time to check this and it works for me.

[fredx181]

@wiak and @rockedge
Too much easy talking IMO, how should a new KL user know that he/she has to add w_addmodule="sdhci_acpi" to the kernel boot line, ok, from this thread, yes, if lucky enough reading it.
Btw, if the initrd.gz that I provided to test didn't work for @JusGellin it's very unlikely that doing the above will work (but ok, you'll never know until tested of course).

edit:

Lot of fuss and criticism about next to nothing

Not criticism, just trying to help fixing a problem.

[rockedge]

If it works I'll post a specific topic as a how-to. I don't have an emmc drive to test with so waiting for a report.

how should a new KL user know that he/she has to add w_addmodule="sdhci_acpi" to the kernel boot line, ok, from this thread, yes, if lucky enough reading it.

Even though I posted the kernel command line options for KL a short time ago, I completely forgot about trying it out in this case. Only did when @wiak pointed it out again

[JusGellin]

w_addmodule="blahblahblah"

so the whole family of distros with a common problem tut tut tut... might work afterall simply by using grub kernel extra argument:

w_addmodule="sdhci_acpi"

Do let me know, but of course can be added permanently if already confirmed. No sweat.

That works!
I booted up KLV-Airdale-sr17.
Thanks.

Of course there has to be other problems now.
I'm having wifi problems.
It allows me to set up the wifi and ip addr gives wlan0.
But it states its state as DOWN.
I need to work on that part now.

Thanks to all of you for sticking with me on this.
I know it takes time, but I sure appreciate it.

[rockedge]

@rcrsn51 your post with the results of your research and testing brought us to the <solved>.

The module you identified is the key and fortunately @wiak already had the mechanism built in to activate the module during the boot cycle.

Is it possible for you to test how it works on your machine(s)?

[JusGellin]

@rockedge
Just to also let you know,
It worked to boot KLV-Airedale-sr17 and also KLV-vmHost-rc4 on that laptop.
I'm needing the wifi firmware to manually load to these to make the wifi work, which I will do later.

Thanks

[rockedge]

@JusGellin
Link to download of two different 01firmware SFS files that might help with the WiFi. Please test!

01firmware-6.13.4_1.sfs 382 M

01firmware-6.13.2_1.sfs 373 M

[Clarity]

@Clarity : While we all enjoy another Ventoy/SG2D adventure, you should recognize that it has nothing to do with JusGellin's actual problem. ...

I concur!

I was curious if the problem might be related to GRUB2 or if it was an actual INIT issue. Those 2 products are different. Again was curious.

GLAD @wiak posted a pathway! AND also glad that @rockedge is prepping a KL firmware package that addressing additional firmware issues.

Thanks to all attempting to assist!

[JusGellin]

I will set up a link to download a 01firmware SFS that might help with the WiFi.

I got the wifi working on KLV-Airedale-sr17 and KLV-vmHost-rcr.

I looked at the firmware driver that BookwormPup64_10.0.10_nkb_v4 used.
I found this by using dmesg to see the name being used here (that same name failed for KLV's)
I found that BW used a symlink to the name it needed that was there.
Here's the symlink it used:
rtl8723bs_nic_bin -> rtl8723bu_nic.bin

Like BW both KLV's already had the driver needed like BW has.
They all have rtl8723bu_nic.bin.

So I made a symlink to the name each KLV needed:
rtl8723bs_nic_bin -> rtl8723bu_nic.bin
That worked

I'm getting to learn my way around to figure some things out --- but still a long way to go.

Thanks

[wiak]

@wiak and @rockedge
Too much easy talking IMO, how should a new KL user know that he/she has to add w_addmodule="sdhci_acpi" to the kernel boot line, ok, from this thread, yes, if lucky enough reading it.
Btw, if the initrd.gz that I provided to test didn't work for @JusGellin it's very unlikely that doing the above will work (but ok, you'll never know until tested of course).

edit:

Lot of fuss and criticism about next to nothing

Not criticism, just trying to help fixing a problem.

Listen Fred, no one said rcrsn51 did not find the solution and well done for that. That's what forum contributor help is for. The fuss and criticism I referred to was this nonsense:

"What I see here is a whole family of distros with a common problem that could have been detected early on with more testing."

There was no need for such a comment, which is unreasonable. We are hobbyists and develop what we can and when no fault previously noticed then all is well and good, but there are always going to be faults, completely unintentional and most of the time nothing whatsoever to do with poor testing. We test what we have and what we can and when something new comes up we do our best to track down solutions. Great someone found the solution; hopefully someone always will. I certainly did not find the solution - I had no means to test the problem; all I can do is provide a mechanism to use the solution, which I had done. Now we know that solution, it is easily added in; no fuss or bother or criticism warranted. Hobby. That's all.

More problems will arise. Always will. No one to blame for that in any way at all.

[JusGellin]

@JusGellin
Link to download of two different 01firmware SFS files that might help with the WiFi. Please test!

01firmware-6.13.4_1.sfs 382 M

01firmware-6.13.2_1.sfs 373 M

I thought the way to test these was to empty the /usr/lib/firmware directory when KLV-vmHost is booted up.
Then I replaced the existing 01firmware with one that I downloaded.
Then I did a save2flash and rebooted.
But when it comes up the firmware directory is still empty.
dmesg indicates it is trying to load rtl8723bs_nic.bin

So what am I doing wrong?
Is there a better way to check these 01 firmware sfs files?

If I look into both 01firmware sfs files they have that firmware file in them.

I need some direction for how to do this.

Thanks

[fredx181]

I thought the way to test these was to empty the /usr/lib/firmware directory when KLV-vmHost is booted up.
Then I replaced the existing 01firmware with one that I downloaded.
...

Replacing the 01firmware sfs is only required to do.
Best IMO to start from scratch again (by deleting the upper_changes dir) and boot with the new 01firmware sfs .
edit: to explain, as you deleted the content of /usr/lib/firmware it contains all "masked" files in upper_changes, that's why it shows still empty when you boot with the new 01firmware sfs .

[JusGellin]

I thought the way to test these was to empty the /usr/lib/firmware directory when KLV-vmHost is booted up.
Then I replaced the existing 01firmware with one that I downloaded.
...

Replacing the 01firmware sfs is only required to do.
Best IMO to start from scratch again (by deleting the upper_changes dir) and boot with the new 01firmware sfs .
edit: to explain, as you deleted the content of /usr/lib/firmware it contains all "masked" files in upper_changes, that's why it shows still empty when you boot with the new 01firmware sfs .

Oh, that's really interesting!
Is that what is called "white listing"?
Now I understand this more by actually experiencing it ---- pretty cool.

@JusGellin
Link to download of two different 01firmware SFS files that might help with the WiFi. Please test!

01firmware-6.13.4_1.sfs 382 M

01firmware-6.13.2_1.sfs 373 M

Yes, both work fine.

So, to make an old (2016 model) Lenovo Ideapad 100S-11IBY work with KLV's, two things have to be done:
1. grub.cfg needs to have its linux line modified by adding w_addmodule="sdhci_acpi" to it
2. Replace 01firmware with 01firmware-6.13.4_1.sfs or 01firmware-6.13.2_1.sfs.

How would you upgrade a firmware fix on a system that has a save upper folder that had desired settings you didn't want to lose?

Thanks

[fredx181]

I thought the way to test these was to empty the /usr/lib/firmware directory when KLV-vmHost is booted up.
Then I replaced the existing 01firmware with one that I downloaded.
...

Replacing the 01firmware sfs is only required to do.
Best IMO to start from scratch again (by deleting the upper_changes dir) and boot with the new 01firmware sfs .
edit: to explain, as you deleted the content of /usr/lib/firmware it contains all "masked" files in upper_changes, that's why it shows still empty when you boot with the new 01firmware sfs .

Oh, that's really interesting!
Is that what is called "white listing"?

Well, yes also called "whiteout files", if you delete a file that is originally part of the base system (the sfs's you boot from), then such a file is created to "hide" it from the system (say you delete that whiteout file (in upper_changes) and reboot, the file will be back again as it originally was with a pristine boot).

[fredx181]

@wiak and @rockedge
Too much easy talking IMO, how should a new KL user know that he/she has to add w_addmodule="sdhci_acpi" to the kernel boot line, ok, from this thread, yes, if lucky enough reading it.
Btw, if the initrd.gz that I provided to test didn't work for @JusGellin it's very unlikely that doing the above will work (but ok, you'll never know until tested of course).

edit:

Lot of fuss and criticism about next to nothing

Not criticism, just trying to help fixing a problem.

Listen Fred, ....

Well, I could criticize you now for the way you talk, but I'll shut up because there's no end in that. Criticizing criticism ... ... repeating ... ... not constructive and no fun either.

[JusGellin]

Well, yes also called "whiteout files", if you delete a file that is originally part of the base system (the sfs's you boot from), then such a file is created to "hide" it from the system (say you delete that whiteout file (in upper_changes) and reboot, the file will be back again as it originally was with a pristine boot).

Now I see how that works. This has given me experience:

Deleted a couple of wifi firmware files.
Checked trash and found them in there. Cleaned trash. Edit: it works without emptying trash
Did save2flash
On reboot they were gone in /usr/lib/firmware

Went to upper_changes and saw those files, which were 0 in size (whiteout files).
Deleted them.
Checked trash and found them in there. Cleaned trash. Edit: it works without emptying trash
Did save2flash
On reboot they were again in /usr/lib/firmware

I wanted to post this to help others and myself to refer back to this in the future.

Thanks again