Lenovo Ideapad 100S-11IBY won't boot a Puppy Install

[bigpup]

I have not read all posts in this topic, so I may say something already posted.

I would take and start over with the internal drive setup.

Do this from a Running Puppy you can get booted from a USB stick.

Use Gparted program to completely setup the internal drive. (do you fully know how to operate Gparted?)

Make a new partition table on it (type msdos)
(that should completely delete everything on it, including any hidden partitions or files.)
Who knows what Lenovo cold have hidden on the drive.
Who knows what Lubuntu installer did to the partition table.

Now make the two partitions as you did before.
Small first partition formatted fat32 flagged boot and esp.
Rest of drive 2nd partition format ext4.

Install the Puppy versions as frugal installs on the 2nd partition.
Each one in it's own directory.

Now you need a boot loader installed to boot them.

If frugalpup Installer is available to use.
The boot loader it installs has option to install uefi, legacy bios, or both boot loaders.
So if unsure install both.

Frugalpup Installer
viewtopic.php?t=337

Install the boot loader to the first partition.

Computer bios setup settings.
Disable secure boot.
Look for anything like enable legacy boot, CSM, and if there, select it for how the bios operates.

Just to eliminate maybe an issue.
When trying to boot from internal drive. Do not have any USB drives plugged in.

If still not booting.

From the 1st partition.
Post the grub.cfg file contents so we can see the menu entries it is trying to use.

Note:
Frugal install of a Puppy version is still the complete OS, just installed in a special way.
A lot of Puppy features only work as a frugal install.

[gyrog]

Boot0003* Puppy Linux - Grub2 HD(1,GPT,150145f9-7295-5041-a61c-733666a0818a,0x1000,0x96000)/File(\EFI\Puppy\bootia32.efi)

looks good, over another hurdle.

When I booted into the computer it now gives Puppy dpupbw64 selection in Grub menu.
The first time I selected that it gave errors. - see attached
But by rebooting again, all I get is a blank display.

If you get a blank display, wait a few minutes.
One of the problems with this hardware, is that it often doesn't display anything on the console until after kernel modules are loaded,
i.e. a fair way into the boot.
There is a work-around for this, but that can wait until after boot to desktop is working.

Getting back to the errors;
It looks like there is a problem with the 'grub.cfg' menuentry, or it's picking up the wrong 'grub.cfg'
I'll investigate ways of looking at the grub menuentry from the Grub menu, and report back.

[gyrog]

@bigpup
Your advice is good, and we are used to it working on "normal" PC's.
Unfortunately, this is not a "normal" PC.
I have one of these, and I run Puppy on it, but from a Puppy perspective it's "the hardware from hell".
It's "uefi/bios" is so minimilist, it has to be seen to be believed.

I gather that the "normal" process has been done, and the internal drive was not even recognised as a bootable device.
Hence the unusual process being tried.

A significant difference between the OP's computer and mine is that the OP re-partitioned the internal eMMC drive, so is starting with a new ESP; whereas I left Windows installed and installed Puppy grub2 as a multi-boot in the existing ESP.

[JusGellin]

gyrog,
Just to let you know I have just left it on with the blank display for more than 15 minutes when I stepped away. It was still in that state when I came back.

One thing I also noticed that when it goes from the grub menu to startup, it shows a two line message:

Loading vmlinuz
Loading ucode.cpio and initrd.gz

Whether it helps or not for the error message I got the first time:
I looked at the error information that came up by booting up and with my bootable Puppy USB stick I mounted the second partition of the internal hard drive.
the root is named root but it seems to not find it..... failed
I didn't see any puppy main sfs file .... failed
I didn't see any file called /tmp/bootinit.log
Toward the end where it says "*** root /Puppy/puppy_dpupbw64_10.0.4.sfs not found", I find that file is indeed on the root drive.

[gyrog]

@JusGellin,
Boot from USB.
Note the UUID of '/dev/mmcblk1p2', using "blkid /dev/mmcblk1p2".
Look at the 'grub.cfg' in the root of '/dev/mmcblk1p1'.
Check that the UUID mentioned in the Bookworm64 entry is correct for '/dev/mmcblk1p2'
Check the "linux" line for Bookworm64, and try to remember it.

Boot the intenral drive.
At the grub2 menu, select the Bookworm64 item, if it is not already selected.
Enter 'e' to "edit" the entry, this should show it's contents in a new "window".
Does it look like contents of the 'grub.cfg' file?
In particular check the "linux" line for the Puppy boot parameters, (pdrv=, psubdir=, pfix=).
Press the 'Esc' key to return to the grub2 menu.

[gyrog]

@JusGellin, I missed your messaage while I was composing mine.

Just to let you know I have just left it on with the blank display for more than 15 minutes when I stepped away. It was still in that state when I came back.

OK, so not working yet.

Loading vmlinuz
Loading ucode.cpio and initrd.gz

Do you still get these messages before the blank screen?
These messages are generated by the Puppy grub2 menuentry before handing control to the kernel.
So seeing them would sugggest that the correct menuentry is being activated.

[JusGellin]

gyrog,
All the things you had me checked matched up to what I saw when looking at the actual grub when the computer boots its drive.
Yes, I do get these messages each time there is a boot.
thanks

[gyrog]

@JusGellin,
It looks like grub2 is doing the right thing, but the Puppy 'init' script is failing.

One more thing to check.
Could you please post the contents of the 'grub.cfg' in the root of 'mmcblk1p1'.
Those original error messages indicated that if couldn't find the "root" drive.
And also the output from "blkid /dev/mmcblk1p2".

[JusGellin]

gyrog,

contents of the 'grub.cfg' in the root of 'mmcblk1p1'
#
set default=0
set timeout=5

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

loadfont /boot/grub/fonts/DejaVuSansMono18.pf2
set gfxmode=auto
terminal_output gfxterm

menuentry "Puppy dpupbw64 10.0.4" {
insmod ext2
search --no-floppy --fs-uuid --set=root 27cc0f02-fbe2-4e25-a84d-9ec33d7c40fe
echo "Loading vmlinuz"
linux /Puppy/vmlinuz pmedia=atahd pdrv=root psubdir=/Puppy pfix=fsck,fsckp,trim TZ=GMT0
if [ -e /Puppy/local-initrd.gz ]; then
set local_rd=/Puppy/local-initrd.gz
else
set local_rd=
fi
if [ -e /Puppy/ucode.cpio ]; then
set ucode_rd=/Puppy/ucode.cpio
echo "Loading ucode.cpio and initrd.gz"
else
set ucode_rd=
echo "Loading initrd.gz"
fi
initrd $ucode_rd /Puppy/initrd.gz $local_rd
}
if [ $grub_platform = 'efi' ]; then
menuentry "System BIOS setup" {
fwsetup
}
fi
menuentry "Shutdown computer" {
halt
}
menuentry "Reboot computer" {
reboot
}

=============================
"blkid /dev/mmcblk1p2"
/dev/mmcblk1p2: UUID="27cc0f02-fbe2-4e25-a84d-9ec33d7c40fe" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="root" PARTUUID="cf497e09-9c7b-6843-a21e-51033987a684"

[gyrog]

linux /Puppy/vmlinuz pmedia=atahd pdrv=root psubdir=/Puppy pfix=fsck,fsckp,trim TZ=GMT0

This line tells the 'init' script to look for a partition with a LABEL="root".

/dev/mmcblk1p2: UUID="27cc0f02-fbe2-4e25-a84d-9ec33d7c40fe" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="root" PARTUUID="cf497e09-9c7b-6843-a21e-51033987a684"

But this shows that /dev/mmcblk1p2 does not have a LABEL="root", even though it has PARTLABEL="root".
The 'init' script has only "busybox blkid" available to it.
If you issue this command:

Code: Select all

busybox blkid /dev/mmcblk1p2

you will see the information available to the 'init' script.
So it cannot decode "root" to "mmcblk1p2", hence it fails.

To fix, add a LABEL to /dev/mmcblk1p2:

Code: Select all

e2label /dev/mmcblk1p2 root

run

Code: Select all

busybox blkid /dev/mmcblk1p2

again to see that /dev/mmcblk1p2 now has a LABEL="root".
OR
You could edit the 'grub.cfg' and replace "pdrv=root" with "pdrv=27cc0f02-fbe2-4e25-a84d-9ec33d7c40fe", (without the quotes).
The 'init' script can decode a UUID.

[JusGellin]

gyrog,

I changed and confirmed pdrv=root. Then rebooted.
It came up with a bunch of text, but I wasn't quick enough to see what it was showing and mistakenly rebooted again. Now on each boot, it is a blank display again. But the change made it do something. It's too bad I didn't catch that part.

[gyrog]

@JusGellin,
Ok, could you boot from USB, then do "Shut Down".
Remove USB stick.
Leave it off for a few minutes.
Turn it on and boot internal disk, and let it run a while, but observe what happens.

I hope this will get the text back.

[JusGellin]

gyrog,
By doing that, now the original error display comes up with the exact same information. The first thing it fails on is "Waiting for partition [root]" I've taken a picture of that display, but since it is exactly the same, I didn't post it.

Every time I reboot, it now comes up with that display.
Thanks

[JusGellin]

gyrog,
I might mention that when the text came up that I missed, it was different than this error display. In fact after a bunch of white text came up, then it went to the blank display the first time and then every reboot was a blank display after the grub menu. This was after I modified the grub file for pdrv=root.

[gyrog]

Please post the output from:

Code: Select all

busybox blkid /dev/mmcblk1p2

[JusGellin]

[b]busybox blkid /dev/mmcblk1p2[/b]
/dev/mmcblk1p2: LABEL="root" UUID="27cc0f02-fbe2-4e25-a84d-9ec33d7c40fe" TYPE="ext4"

[gyrog]

The whole LABEL thing looks OK now,
so it doesn't make sense that the 'init' script fails to decode "root".

If you are geting an "error" screen like the one you posted, you should be able to type commands at that point.
Could you please enter the command:

Code: Select all

cat /proc/cmdline

and post a picture showing the result.

The only other suggestion is try editing the grub.cfg "linux" line and replace "pdrv=root" with "pdrv=27cc0f02-fbe2-4e25-a84d-9ec33d7c40fe", (without the quotes).

[JusGellin]

That error display doesn't allow typing even though it is flashing cursor.
I tried changing root with the UUID. It just displays the same error only with the UUID instead.

How does the grub.cfg work?
I see it goes to where the echo "Loading vmlinuz" code is and then
continues on to the next echo "Loading ucode.cpio and initrd.gz".
So is it still running the linux command while it continues in the code to the
second echo?
It must work that way because it throws the errors after that.
thanks

[bigpup]

Try this to see what happens.

In the grub.cfg open it in a text editor and edit it.

In the menu entry that has pmedia=atahd

try a few different ones:

pmedia=usbhd

pmedia=usbflash

pmedia=ataflash

This specifically identifies the type drive and there is a chance, that this identification is wrong, in the original grub.cfg
I have seen this cause the errors you got, about not finding the Puppy SFS's.
This pmedia= does affect the boot process.

Usually pmedia=cd is the cause of issues when not booting from a CD/DVD.
But this could be what type drive controller the internal drive is being accessed by.
Is the computer doing it by USB controller or ATA, etc........

Anyway, trying this edit is an option that could affect booting.

--set=root 27cc0f02-fbe2-4e25-a84d-9ec33d7c40fe

This should be setting root to the UUID, so anything revering to root, is going to see it as the UUID number, which is a specific identifier of the partition, the Puppy files are on.

[gyrog]

How does the grub.cfg work?
I see it goes to where the echo "Loading vmlinuz" code is and then
continues on to the next echo "Loading ucode.cpio and initrd.gz".
So is it still running the linux command while it continues in the code to the
second echo?
It must work that way because it throws the errors after that.

The "Loading" messages are generated by grub2 processing the "echo" lines in the grub.cfg menuentry.
So it's a grub2 command line, rather than a Linux command line.

This indicates that the uefi/bios is booting the Puppy grub2, and that grub2 functions fine.
Getting to the second message, suggests that grub can access the mmcblk1p2 partition and load the vmlinuz.

The "Waiting for [xxxx]" message comes from early on in Puppy's 'init' script,
This indicates that the initrd.gz has been loaded, and the kernel is loaded and running.
Further, that fact that the [xxxx] corresponds to the current "pdrv=" boot parameter,
indicates that the boot parameters in the grub.cfg "linux" are being sucessfully passed to the Puppy 'init' script.

The contents of the "pdrv=" parameter have been checked against "busybox blkid",
but 'init' fails to decode the partition, from either it's LABEL or UUID.
This would suggest that the "blkid" command in 'init' can't "see" the internal disk.
Which implies that the kernel can't see the internal disk.

So, I intend to stay away for a few days, while I checkout the defult kernel in BookwormPup64_10.0.4, on my Lenovo.
I'm running BookwormPup64 on my Lenovo, but it's BookwormPup64_10.0.1.
I run Puppy in my Lenovo with an fdrv specifically tailored for my Lenovo hardware.
I'm not sure if that's signifacant, but I intend to check it out.

Note: I'm not surprised by the blank screens and unresponsive keyboard, with a failed boot.
My experience with this hardware suggests that you can't be sure of reliable communication to the screen and from the kyboard,
untill the kernel modules have finished loading, and that happens fairly late in the boot process, long after the errors being seen here.

If you get it to work, or decide to abandon the process, please post here.

Just one suggestion, if the problem is related to the kernel, installing another Puppy as well, e.g. S15Pup64-22.12, might work.
i.e. use "FrugalPup->Boot" to "append" S15Pup64-22.12 to the existing grub.cfg.

[JusGellin]

gyrog,
Thank you so much for working with me on this. It's impressive that you really know your stuff and can think of things to look at and try. It's also so amazing to me for you to be able to give me things to try without you actually seeing what I am doing. I have learned a lot just from this. It is a thrill to be able to think of things to try for troubleshooting a problem like this. I've learned a lot, but have a long way to go to understand this. I've really enjoyed your help.
I intend to keep looking to try things and to understand all that you had me do. If I have any breakthroughs, I'll definitely post them.
Thanks again

bigpup,
Thanks for some more suggestions. I was wondering if going to the edit grub would take affect for when I got out of it and it continued to boot. In fact I found that I just had to do the edit and then ctrl x out to see it work (I searched to find how to save edits and found this only works for the one time it runs). I tested that this worked by echoing some text and see it show up. What is the best way to make permanent change? I'm still not sure about that.
I will definitely try different pmedia entries as you suggested which answers my question of making the changes permanent.

I'm really glad to see a lot of activity going on for Puppy Linux. I looked at using it back several years ago but it just didn't do what I wanted. Now looking at it, it looks like there's a lot of good useful things in it making it worthwhile to use. It's really something how small it is for all the apps it can handle. I've gone to using Linux as much as I can for the learning and just to get away from Windows. Linux just about gives me everything I need.

Puppy Linux gives me a good project to learn from and I'm looking forward to it. It's uniqueness from the other Linuxes is interesting. It looks like there is a lot to be learned by just reading what's on this forum. Also I've really enjoyed the friendliness of the forums. I've seen other forums that almost act like it is really an insult to ask a question and try to make you think how superior they are.

Thanks again and keep up the good work on this.
JusGellin

[JusGellin]

bigpup,
I also wanted to say that I also appreciated how when I tried to explain how I thought that some of this worked, you corrected me to help me understand better. A case in point is about the eMMC storage the Lenovo.
Thanks,
JusGellin

[gyrog]

@JusGellin, Thanks.

Although I will admit to some selfish motive, I also have such a Lenovo, and I've been tempted to do what you are trying to do.
So what happens here will influence what I do with my Lenovo in the future.

But, I'm really here with some "good" news;
I just did a FrugalPup install of BookwormPup64_10.0.4.iso to my Lenovo, beside the other Puppies that boot fine, making sure that I appended the grub2 bootmenu entry to my existing grub.cfg.
And it failed just like yours, unable to find the Puppy install partition.
So now I have a local "test bed", all I have to do is find out why this Puppy fails, when the other 3 boot fine.

Hopefully I'll have some results before the week is out.

[ozsouth]

@gyrog - seems lots of things have been tried, but did you look at the emmc in gparted? Even though you can see it, the hidden flag stopped my 110s from booting until I unchecked it. Near drove me mad.

[wizard]

@JusGellin
@gyrog

I'm also following this topic with interest, since I have two Lenovo Thinkpad 11e Chromebooks (converted for Linux) that fail to boot Puppy BW64 from the eMMC.

Thanks
wizard

[gyrog]

@gyrog - seems lots of things have been tried, but did you look at the emmc in gparted? Even though you can see it, the hidden flag stopped my 110s from booting until I unchecked it. Near drove me mad.

No, I haven't. But then my Lenovo has been sucessfully booting other Puppies for quite some time.
@JusGellin, you could check this out, unlikely to make things worse.

[gyrog]

Which implies that the kernel can't see the internal disk.

And

I just did a FrugalPup install of BookwormPup64_10.0.4.iso to my Lenovo, beside the other Puppies that boot fine, making sure that I appended the grub2 bootmenu entry to my existing grub.cfg.
And it failed just like yours, unable to find the Puppy install partition.

So I replaced the BookwormPup64_10.0.4 kernel with the kernel from BookwormPup64_10.0.1, (my existing working Bookworm64 on the Lenovo).
And lo, it booted, and runs.
We have a possible workaround!!!!

I'll package the relevant kbuild, fdrv, zdrv and vmlinuz files into a tar file, and make it available for download,
so others can test it.

But, even if it works, there is still the question;
Why did the BookwormPup64_10.0.4 fail, why does the different kernel work, what's the significant difference?
Until that is found, we're stuck with this particular kernel.

My thought is to start by looking at the relevent DOTconfig files, for any possible relevent difference.
May the DOTconfig has been "cleaned-up", and somethig that appeared to be of no significance, was changed,
but this obscure hardware needs it.

So I expect there to be more "news" in the next few days.

[JusGellin]

No, and I always check the flags when I set up the partitions to make sure boot and exp flags are for the efi partition.

[gyrog]

I think I've worked out the issue.

The release kernel in BookwormPup64_10.0.4 defines the mmc driver needed by the Lenovo as a module.
The kernel that works in my Lenovo has the necessary mmc driver, built-in.

A significant difference is that in the DOTconfig for the release kernel many mmc drivers are defined as modules,
whereas in the DOTconfig for the kernel that works on my Lenovo, has the vast majority of mmc drivers built-in.

Fortunately, it looks as if the 6.1.? kernels compiled by woof-ce on github, have a lot of mmc drivers built-in.
I'm going to try a 6.1.69 kernel I recently downloaded from woof-ce on github.

Why is this a problem in Puppy?
If a module is needed to enable the kernel to read a drive, and that module is stored on said drive, it can't work.
Puppy stores it's kernel modules in the zdrv...sfs which resides in the install location, which in this case is on an mmc drive.
So the required mmc driver must be built-in to the kernel.

Note: I have not been able to identify the particular driver "module" required by a Lenovo Ideapad 100s, but it doesn't matter, as long as it's one of the drivers built-in to the kernel that is being used.

[ozsouth]

@gyrog - if useful, my 6.1.65 (non-usrmerge) & 6.6.7 (usrmerge) kernels have the following mmc drivers in DOTconfigs (kernels are in forum Kernels section):

CONFIG_MMC=y
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_MINORS=8
CONFIG_SDIO_UART=m
# CONFIG_MMC_TEST is not set

#
# MMC/SD/SDIO Host Controller Drivers
#
# CONFIG_MMC_DEBUG is not set
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_IO_ACCESSORS=y
CONFIG_MMC_SDHCI_PCI=y
CONFIG_MMC_RICOH_MMC=y
CONFIG_MMC_SDHCI_ACPI=y
CONFIG_MMC_SDHCI_PLTFM=y
CONFIG_MMC_SDHCI_F_SDH30=y
CONFIG_MMC_WBSD=y
CONFIG_MMC_ALCOR=m
CONFIG_MMC_TIFM_SD=y
CONFIG_MMC_SPI=y
CONFIG_MMC_SDRICOH_CS=m
CONFIG_MMC_CB710=y
CONFIG_MMC_VIA_SDMMC=y
CONFIG_MMC_VUB300=y
CONFIG_MMC_USHC=y
CONFIG_MMC_USDHI6ROL0=y
CONFIG_MMC_REALTEK_PCI=y
CONFIG_MMC_REALTEK_USB=y
CONFIG_MMC_CQHCI=y
# CONFIG_MMC_HSQ is not set
CONFIG_MMC_TOSHIBA_PCI=y
CONFIG_MMC_MTK=y
CONFIG_MMC_SDHCI_XENON=y