ScPup & ScPup64 - Slackware Current based Woof-CE pups

[gyro]

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

I just compiled kernel 5.4.46 in ScPup64 with DOTconfig changes.
After the compile, I noticed that the produced DOTconfig contained an additional configuration set,

Code: Select all

CONFIG_MISC_RTSX=y

I have attached 'DOTconfig-5.4.46-120620'.
I've also attached 'mmc.diff' which shows the changes that I now consider to be those required for mmc support, well at least a starting point that is better than our current kernel configs.
Using these changes, the resultant kernel should support "01micko"s Realtek mmc card reader, without any need to use 'initrdmodules',
as should my new 64-bit kernel 5.4.46.

gyro

[gyro]

I've uploaded 'huge-5.4.46-gyro-64.tar.bz2' to http://www.mediafire.com/folder/21fyvbi4xglau/kernels, for ScPup64.

This kernel package does not contain any firmware, it requires the presence of an fdrv...sfs.

gryo

[gyro]

I've uploaded 'huge-4.14.184-gyro-pae.tar.bz2' to http://www.mediafire.com/folder/21fyvbi4xglau/kernels, for ScPup.

This kernel package does not contain any firmware, it requires the presence of an fdrv...sfs.

This kernel provides much improved mmc support, the equivalent of 'huge-5.4.46-gyro-64.tar.bz2'.

Note that the kernel config variables required for Realtek support are slightly different between kernel v4 and kernel v5.

gyro

[bigpup]

@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

Using the initrd.gz that only boots to a prompt.
I see this:
Loading vmlinuz
Loading initrd.gz
stops at a prompt

Type debugsave
Get a bunch of errors about stuff not being found.
Ends with no partitions found.
So, I cannot provide debugsave info.

I tried this with the original initrd.gz that is in ScPup64 20.01.
This boots to point of kernel loading, but stops with bunch of error messages and kernel panic.
No prompt provided.
So, cannot provide debugsave.

Bionicpup64 8.0 boots OK.

ScPup64 20.01 using the the initrd.gz from ScPup64 19.09+0-uefi-T.iso boots OK.

The boot loader, is the UEFI boot loader, installed by Frugalpup Installer.
Secure boot is enabled in the UEFI bios.

This is the drive I am using.

[01micko]

@bigpup if you plug in a usb stick you might be able to save the debug logs on that.

Also try @gyro's kernel and init script. (edit.. gyro's init wont work.. see below for explanation)

Your drive is indicated as gpt via that screen shot which explains the kernel panic as fdisk will error because it only supports mbr so init stops and boot can't go on which confirms my initial hunch.

The problem I now face is that I either have to do an early init check on the partition type or find a utility other than fdisk to check the partition sizes in the init function check_resize_part().

[bigpup]

OK.

But Booting Bionicpup64 8.0
I see information about e2fsck doing a check and giving the results of that check.
e2fsck 1.44.1 (24-Mar-2018)
The boot process continues as a normal boot to working desktop.

Same e2fsck checking drive information, with results.
Booting ScPup64 20.01, using the the initrd.gz from ScPup64 19.09+0-uefi-T.iso.
e2fsck 1.45.6 (20-Mar-2020)
It also boots OK.

[01micko]

OK.

But Booting Bionicpup64 8.0
I see information about e2fsck doing a check and giving the results of that check.
e2fsck 1.44.1 (24-Mar-2018)
The boot process continues as a normal boot to working desktop.

Same e2fsck checking drive information, with results.
Booting ScPup64 20.01, using the the initrd.gz from ScPup64 19.09+0-uefi-T.iso.
e2fsck 1.45.6 (20-Mar-2020)
It also boots OK.

fsck just checks filesystems, it doesn't care about partitioning.

I have an init script for you to try.

For the record it is a simple check with fdisk (which won't error, just skip the offending code) to see if we have a GPT partition.

It works before any of the probedisk log checks.

Code: Select all

--- init	2020-05-31 11:46:29.210999690 +1000
+++ /root/spot/init	2020-06-13 07:22:03.702212647 +1000
@@ -667,6 +667,7 @@ umount_unneeded() {
 
 check_resize_part() { #must be fast, no partitions can be mounted, can't work out pupmode at this stage
  DEVICE=/dev/mmcblk0 # sd card only for now
+ fdisk -l $DEVICE | grep -qm1 "using GPT" && return
  grep "$DEVICE" /tmp/probedisk.log | grep -q 'card' || return
  FS=`grep "$DEVICE" /tmp/probepart.log | tail -n1 | cut -f 2 -d '|'`
  case $FS in

I'll attached the file as a tar. Untar and insert it into your initrd-expanded overwriting the init script and repack the initrd.gz

[bigpup]

OK, I will try it.

I was looking at fdisk information.

fdisk supports GPT since util-linux 2.23

util-linux
https://mirrors.edge.kernel.org/pub/lin ... til-linux/

[01micko]

Thanks bigpup

In the meantime, I found the source of @mash 's bug!

A stupid assumption grepping for GB! I've put in code for KB|MB|GB and that will fix it. I tested on a 8GB card which in fdisk shows up at ~8000MB. I tested with KB too because (and I don't know, but it doesn't hurt to add) smaller cards do have the possibility I guess as showing up in KB.

I'm going to commit the changes to woof-ce.

I'm still hoping your machine boots bigpup because that code shouldn't be reached at all when your machine boots.

[bigpup]

OK.

Do you have a newer initrd.gz to try or do you want me to still try what you posted above?

[01micko]

Give me a few minutes bigpup and I'll upload an initrd.gz

I'm using gyro's kernel 5.4.46 and the init I'm going to commit to woof in slacko64-6.9.9.10. My reason is to exclude that it was a scpup issue. Now I'll be using scpup64 when I update the initrd.gz.. is that ok for you?

EDIT:

I've uploded an initrd.gz for scpup64

http://01micko.com/packages/initrd.gz

Code: Select all

# md5sum initrd.gz 
c68615601ab676ade73a3c0eab774cba  initrd.gz

Make sure to change kernels to gyros, however you may need a wireless driver compiled, but it is needed for a thorough test.

[bigpup]

I have an init script for you to try.

For the record it is a simple check with fdisk (which won't error, just skip the offending code) to see if we have a GPT partition.

It works before any of the probedisk log checks.

I'll attached the file as a tar. Untar and insert it into your initrd-expanded overwriting the init script and repack the initrd.gz

Before seeing your last post. I tried this init.
It boots OK to working desktop.

Now, I will try the new kernel and initrd.gz you now offer.

I got to delete some of these hacked initrd.gz's.
I am starting to get confused on which one to use

[bigpup]

Give me a few minutes bigpup and I'll upload an initrd.gz

I'm using gyro's kernel 5.4.46 and the init I'm going to commit to woof in slacko64-6.9.9.10. My reason is to exclude that it was a scpup issue. Now I'll be using scpup64 when I update the initrd.gz.. is that ok for you?

EDIT:

I've uploded an initrd.gz for scpup64

http://01micko.com/packages/initrd.gz

Code: Select all

# md5sum initrd.gz 
c68615601ab676ade73a3c0eab774cba  initrd.gz

Make sure to change kernels to gyros, however you may need a wireless driver compiled, but it is needed for a thorough test.

Did this changing kernel to 5.4.46 and using this initrd.gz.

This boots, with no problem, to working desktop!

Note to 01micko:
Your change_kernels program.
http://www.murga-linux.com/puppy/viewtopic.php?t=101144
Could you please edit the information on the main window.
It is confusing.
It needs to just say the vmlinuz and zdrv sfs or kernel-modules sfs need to come from the new kernel package.
Only stuff from new kernel go into the input slots.

I have had to explain, to many people trying to use this, to only input stuff from new kernel package.

Really nice and easy to use, when you understand this.

Thanks very much for coding it!!!

PS:
This Hp Stream 14 laptop is very new hardware.
So, the newer the kernel, probably the better.

[01micko]

bigpup, I'm presently doing an overhaul of change_kernels with support for just dragging the whole tarball to a window as well as retaining the old method. It will also support changing /usr/lib64 to /usr/lib for deb based distros in the zdrive.

[mash]

Give me a few minutes bigpup and I'll upload an initrd.gz

I'm using gyro's kernel 5.4.46 and the init I'm going to commit to woof in slacko64-6.9.9.10. My reason is to exclude that it was a scpup issue. Now I'll be using scpup64 when I update the initrd.gz.. is that ok for you?

EDIT:

I've uploded an initrd.gz for scpup64

http://01micko.com/packages/initrd.gz

Code:
# md5sum initrd.gz
c68615601ab676ade73a3c0eab774cba initrd.gz


Make sure to change kernels to gyros, however you may need a wireless driver compiled, but it is needed for a thorough test.

This init works for me too. Either with gyro's or with original lxpup kernel.

In the meantime, I found the source of @mash 's bug!

A stupid assumption grepping for GB! Embarassed I've put in code for KB|MB|GB and that will fix it. I tested on a 8GB card which in fdisk shows up at ~8000MB. I tested with KB too because (and I don't know, but it doesn't hurt to add) smaller cards do have the possibility I guess as showing up in KB.

My problem was also GPT partitioning I believe. If I look at fdisk output there are `GiB` used, so your regexp should take this into consideration too? Or maybe it doesn't matter?

Type debugsave
Get a bunch of errors about stuff not being found.
Ends with no partitions found.
So, I cannot provide debugsave info.

Yes, had the same result. Done some random guessing looking at `/sbin` directory and you have to run `usablefs` before `debugsave`. But I think it is not needed anymore.

I will try new Woof-CE build tomorrow.

[01micko]

mash, I believe busybox fdisk only uses MB, GB whereas gnu fdisk does use MiB and GiB. In the initrd.gz we only have busbox fdisk available.

See screenshot.

Glad it works for you

[peebee]

New baselines 20.06+0 are available - see posts #1 & #2

Please note: small name change from ScPup to ScPup32 - will mean carried over save area needs a name change.

delta from ScPup-20.01+0

delta from ScPup64-20.01+0

[gyro]

This init works for me too. Either with gyro's or with original lxpup kernel.

Yes, the original kernel already had the drivers for your mmc hardware builtin, whereas it did not for 01mico's Dell.
I think you had the problem because the 'init' script was aware of your mmc device.

The lack of kernel support for many mmc devices, was not the problem here, except that it may have hidden the problem.
The lack of builtin support for mmc storage devices needed to be addressed anyway.

gyro

[bigpup]

Just to let you know.

My HP Stream 14 laptop
Frugal install of ScPup64 20.06+0 on internal emmc card.

Boots with no problem to working desktop.

To get WIFI working.
Compiled r8822be driver using this source package
https://github.com/mid-kid/r8822be
Installed rtl8822befw.bin firmware file.
Got it from here:
https://www.mediafire.com/folder/k2j223jzddy9x/firmware
Using the linux_firmware_20200614.sfs

Network controller
• Realtek Semiconductor Co., Ltd. RTL8822BE 802.11a/b/g/n/ac WiFi adapter
• VendorID=10ec DeviceID=b822
Realtek RTLB872 Cartier 2x2 ac / BT4.2 M.2
• Kernel Driver=r8822be
• Kernel Module=rtwpci, r8822be

[bigpup]

Strongly suggest you put uextract in ScPup.
http://murga-linux.com/puppy/viewtopic.php?t=87864