ScPup & ScPup64 - Slackware Current based Woof-CE pups

[gyro]

Sorry folks.

It looks like my "unavailable mmc kernel module" theory is wrong.

"mash" has reported that inserting an SD card after booting, does not cause the loading of a module.

And I have done some testing on my Lenovo IdeaPad 100S:

I know that it has an "unavailable mmc kernel module" issue.
So I if my theory were correct, I would expect the Lenovo to exhibit the issue, and kernel panic.
But it did not, it boots scpup32 out of the box, fine, i.e. with the "offending" code in the 'init' script.

Without the needed mmc kernel module, the 'init' script is completely unaware of any mmc devices, as seen in '/initrd/tmp/probepart.log'

So, I have nothng.

gyro

[01micko]

I have a Dell Latitude E7270 laptop with builtin card reader. The reader is not available for booting unless I use gyro's initrdmodules tool.

The computer boots fine from a usb stick with the sdcard plugged in, but nothing can be found on it until zdrv is loaded of course.

For the record, I'm running slacko64-6.9.9.10 fresh out of woof-ce.installed to a usb stick with gyro's other utility f2stickpup, part of frugal pup. Secure boot is enabled on this machine.

On my sdcard I installed the same OS as on my stick. On the stick I ran the initrd modules facility which installed the rtsx_pci and rtsx_pci_sdmmc modules to the initrd.gz. Unfortunately, the init script didn't get updated so I manually patched it with the diff in gyro's first post of the related initrdmodules topic.Once I got this sorted I proceeded to boot the card. I was able to reproduce the kernel panic. Completely different OS and kernel. Again for the record, the kernel is freshly compiled 4.19.125.

I also booted the stick with the patched initrd and the sdcard plugged in but no kernel panic. I only got the panic when booting off the sdcard.

Frankly, I don't understand it. There seem to be no syntax errors in the init code and it is a simple operation to grep the probedisk log and decide which way to proceed.It does seem though that the script decides that we should check if the card needs resizing so the error possibly comes from /sbin/resize_part, but that looks ok to me too. Works just fine on raspberry pi boards.

The only thing I can think of is to set a boot parameter to specify if a partition needs resizing. It does work, am booting from the sdcard right now.

Further thoughts appreciated.

[gyro]

Frankly, I don't understand it.

Hear, hear.

Yes, the code looks benign, if it had any syntax errors etc..., I would expect it to kernel panic on all hardware.
However you could remove any lingering doubt by extracting '/sbin/resize_part' from the initrd.gz and running it from the running system after booting from the usb stick.

It would also be ineresting to see if recompliling the kernel so that the mmc host modules identified by 'initrdmodules' get builtin, makes any difference.
I have a memory of a comment about the kernel, that some drivers only work properly if they are builtin.
If this proves sucessful it would be interesting to see if a test kernel with all mmc host modulles builtin would work for the other folk.
The idea is to remove the need to use 'initrdmodules'.

Another thing that could be tried, is to prove that the 'init' script has working access to the SD card.
Boot from the usb stick, but add some hack code into the 'init' script that mounts the SD card, "cat"s a text file that exists on it, and umounts it. The contents of the text file should appear in '/initrd/tmp/bootinit.log' in the running system.

I must try booting from an SD card in my Lenovo IdeaPad.
All my testing was done booting from a usb stick.

Just a thought on your code:
The SD card in my Lenovo is "mmcblk2" not "mmcblk0", so activating the resizing code with a boot parameter like "sdresize=2" might be an advantage.

I read somewhere in the forum that BK had done some work in compiling a more mmc friendly kernel, in Quirky or EasyOs. We probably should track down the kernel config file he used, and update the woof-CE kernel config files appropriately.

Another 2 cents worth.

gyro

[gyro]

Is it my late, late, late night stupidity, or is there a problem with '/sbin/resize_part' trying to actually resize the same partition that it's booting from.

gyro

[bigpup]

On my Hp Stream 14

I am booting from an emmc drive.
It is the internal drive for this computer.

I am using the 5.4.6 kernel that comes in ScPup64 20.01

Have to use a different older initrd.gz to get it to boot.

The initrd.gz in ScPup64 20.01 causes kernel panic.

This is the initrd.gz that is working OK.

[bigpup]

Hi bigpup,

Compiled a driver in scpup64 kernel 5.4.6 from sources at https://github.com/mid-kid/r8822be

I stuck it here http://ibm-pc.org/puppy/scpup64/k5.4.6/ ... r8822be.ko
It needs firmware rtl8822befw.bin

No idea if it will work as I don't have a device with that chipset.

Thanks for compiling the driver!!
I just have not tried using it, yet

[gyro]

Do you know what kernel config is needed?

While the kernel panic issue does not seem to be an "mmc module issue", there is an "mmc module issue" in that "01micko" had to resort to using the 'initrdmdules' utility and the 'initrdmdules' patch to the 'init' script to do his tests.

A place to start with the "mmc module issue" would be to recompile the kernel with a modified 'DOTconfig':
The basic idea is; In the section headed "# MMC/SD/SDIO Host Controller Drivers", replace every "=m" with "=y".

Although this could be slightly modified based on BK's 'DOTconfig-5.4.12'.

BK's 'DOTconfig-5.4.12' leaves the following as modules:

Code: Select all

CONFIG_MMC_REALTEK_PCI=m
CONFIG_MMC_REALTEK_USB=m

At least 1 of these represents a moudle already mentioned in this forum topic, so I suggest changing these to "=y".

BK's 'DOTconfig-5.4.12' also leaves the following unset:

Code: Select all

# CONFIG_MMC_RICOH_MMC is not set
# CONFIG_MMC_SDHCI_F_SDH30 is not set
# CONFIG_MMC_ALCOR is not set
# CONFIG_MMC_SPI is not set

So probably these could be left unset.

gyro

[gyro]

On my Hp Stream 14

I am booting from an emmc drive.
It is the internal drive for this computer.

I am using the 5.4.6 kernel that comes in ScPup64 20.01

Have to use a different older initrd.gz to get it to boot.

The initrd.gz in ScPup64 20.01 causes kernel panic.

Obviously the drivers for your emmc haredware are builtin to the default kernel, others are not so fortunate.

I have attached a test 'init' script that contains the line:

Code: Select all

#  /sbin/resize_part $FS

so it will never try to do the actual partition resize.
The idea is to identify if the issue is related to the code in the actual 'init' script or the code in '/sbin/resize_part'.
Could you please, replace the 'init' script in the release 'initrd.gz' with this test 'init' script, and reboot using this "patched" 'initrd.gz'.

gyro

[gyro]

I've attached another test 'init' script.

This one uses a different method of parsing the output from "fdisk -l".

gyro

[peebee]

A place to start with the "mmc module issue" would be to recompile the kernel with a modified 'DOTconfig':

64-bit kernel 5.7.2 has the suggested config changes:
http://murga-linux.com/puppy/viewtopic. ... 96#1060596

[bigpup]

On my Hp Stream 14

I am booting from an emmc drive.
It is the internal drive for this computer.

I am using the 5.4.6 kernel that comes in ScPup64 20.01

Have to use a different older initrd.gz to get it to boot.

The initrd.gz in ScPup64 20.01 causes kernel panic.

Obviously the drivers for your emmc haredware are builtin to the default kernel, others are not so fortunate.

I have attached a test 'init' script that contains the line:

Code: Select all

#  /sbin/resize_part $FS

so it will never try to do the actual partition resize.
The idea is to identify if the issue is related to the code in the actual 'init' script or the code in '/sbin/resize_part'.
Could you please, replace the 'init' script in the release 'initrd.gz' with this test 'init' script, and reboot using this "patched" 'initrd.gz'.

gyro

Did not boot.
Only got to point of loading the kernel and stopped,

No kernel panic, but stopped with only something looking like the process stopped.

[bigpup]

I've attached another test 'init' script.

This one uses a different method of parsing the output from "fdisk -l".

gyro

No boot.
Stopped at loading kernel.
No kernel panic, but stopped with only something looking like the process stopped.

[gyro]

@bigpup,
Thanks for testing.
Unfortunately the result is a little confusing. I had expected that either of those 'init' scripts would have either worked, or produced the kernel panic.

gyro

[gyro]

64-bit kernel 5.7.2 has the suggested config changes:
http://murga-linux.com/puppy/viewtopic. ... 96#1060596

I've had a look at this kernel package, while it should solve the "mmc module issue" for my Lenovo, I don't think it will do the same for "01micko"s test machine, I think it might also need:

Code: Select all

CONFIG_MISC_RTSX_PCI=y
CONFIG_MMC_REALTEK_PCI=y

I intend to actually try this new kernel on my Lenovo, as soon as I can.

Later edit: Your kernel 5.7.2 worked fine on my Lenovo, both the internal mmc device (mmcblk1) and the mmc sdcard (mmcblk2) were seen by the 'init' script wihout any kernel modules being involved.

gyro

[gyro]

The only thing I can think of is to set a boot parameter to specify if a partition needs resizing. It does work, am booting from the sdcard right now.

Does it work both, when you specify that a partition needs resizing, and when you don't?

gyro

[mash]

@gyro

Both init scripts dropped me to the prompt at boot. I think this is the same point as bigpup wrote.

[bigpup]

@gyro

Both init scripts dropped me to the prompt at boot. I think this is the same point as bigpup wrote.

The same for me.
I was not sure that was actually a prompt it stopped at.
So, I just said stopped.

[01micko]

@bigpup and @mash.. just before the prompt doesn't it say "To save debug info to a partition, type 'debugsave'" '

Do it and post the results (just zip up the resulting directory on your drive)

DISCLAIMER: probably doesn't support nvme type drives

[01micko]

@gyro, I didn't test with the presize param set, I would expect to get the kernel panic. I'll attach the init I used and @mash and @bigpup can test it too, without changing boot options.

A thought did occur to me. If the mmc/sd/whatever drive is formatted gpt then fdisk will fail, probably critically.

[gyro]

A thought did occur to me. If the mmc/sd/whatever drive is formatted gpt then fdisk will fail, probably critically.

Hmmm...it could be that the code in 'init' is working too well, after your commit.
Maybe folk who have a problem, also have an "mmcblk0" that can be seen by the 'init' script.

At least you have your own test bed, unfortunately my Lenovo, won't even recognise the micro SD card as a boot device, even though I can successfully boot from it when it is inserted in a usb stick adapter and plug it in as a usb stick.

gyro