ScPup & ScPup64 - Slackware Current based Woof-CE pups
HP Stream Laptop 14
Intel(R) Celeron(R) N4000 CPU @ 1.10GHz
4GB memory
Tried frugal install of ScPup-20.01+6-uefi-T.iso and ScPup64-20.01+6-T.iso
Both boot to a kernel panic not syncing and stop booting.
Intel(R) Celeron(R) N4000 CPU @ 1.10GHz
4GB memory
Tried frugal install of ScPup-20.01+6-uefi-T.iso and ScPup64-20.01+6-T.iso
Both boot to a kernel panic not syncing and stop booting.
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
Also kernel panic during boot.
HP Probook 6475b
AMD A10-5750M APU with Radeon(tm) HD Graphics
Frugal install and booting from USB sick.
I get kernel panic for every ScPup from 20.01+0. Last working is 19.09+0. Also tried building Slacko and BionicPup from latest Woof-CE. They're both failing to boot with the same kernel panic.
"Official" BionicPup 8.0 and Slacko 6.3.2 are booting without problem.
HP Probook 6475b
AMD A10-5750M APU with Radeon(tm) HD Graphics
Frugal install and booting from USB sick.
I get kernel panic for every ScPup from 20.01+0. Last working is 19.09+0. Also tried building Slacko and BionicPup from latest Woof-CE. They're both failing to boot with the same kernel panic.
"Official" BionicPup 8.0 and Slacko 6.3.2 are booting without problem.
Thank you for reports. I obviously do not have these problems on the hardware I have available to test.....
Can people:
1. try an alternative kernel: https://sourceforge.net/projects/lxpup/ ... e-kernels/
2. post output from System -> Pup-SysInfo -> Sys-Specs -> Base Report
3. try booting with nox and if get to console run xorgwizard to select different graphics drivers
I notice both problem reports are from HP systems.... but are there other commonalities - e.g. graphics type?
Can people:
1. try an alternative kernel: https://sourceforge.net/projects/lxpup/ ... e-kernels/
2. post output from System -> Pup-SysInfo -> Sys-Specs -> Base Report
3. try booting with nox and if get to console run xorgwizard to select different graphics drivers
I notice both problem reports are from HP systems.... but are there other commonalities - e.g. graphics type?
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Tested HP Intel i3-5005u, HP Intel Celeron 1000M & HP AMD E2-9000e - All machines fine on ScPup64 20.01+2.
20.01+6 on the i3 (HD 5500 graphics) & Celeron (HD 2500 graphics) - using stock kernel & then my 5.4.27 kernel, no problems.
20.01+6 on the E2 (Radeon R2 graphics) using stock kernel, then my 5.4.27 kernel, & then
my 4.14.159 kernel, X wouldn't start - had to run xorgwizard & select modesetting.
Tried nomodeset in command line - X wouldn't start, with following error message:
Cannot access /sys/class/drm/card*/device/vendor
Usage basename FILE [SUFFIX]
Strip directory path and .SUFFIX from FILE
Another point - when I tried adding openssl 1.1.1g to ScPup64-19.06 & 20.01+2, had video issues.
Possibly unrelated, but Oscar Talks had issues with latest openssl using latest Netsurf, although gtk version suspected.
20.01+6 on the i3 (HD 5500 graphics) & Celeron (HD 2500 graphics) - using stock kernel & then my 5.4.27 kernel, no problems.
20.01+6 on the E2 (Radeon R2 graphics) using stock kernel, then my 5.4.27 kernel, & then
my 4.14.159 kernel, X wouldn't start - had to run xorgwizard & select modesetting.
Tried nomodeset in command line - X wouldn't start, with following error message:
Cannot access /sys/class/drm/card*/device/vendor
Usage basename FILE [SUFFIX]
Strip directory path and .SUFFIX from FILE
Another point - when I tried adding openssl 1.1.1g to ScPup64-19.06 & 20.01+2, had video issues.
Possibly unrelated, but Oscar Talks had issues with latest openssl using latest Netsurf, although gtk version suspected.
Tried alternative kernels 4.19.13, 5.2.11 and 5.4.6 with no luck. Still the same kernel panic.
I attach my PupSysInfo.
I tried also to track breaking change. I know that ScPup 19.09 works and 20.01 don't.
As I was expected, Slacko64 6.9.9.9 - BUILD_FROM_WOOF='HEAD;12196cacc;2019-09-15 07:49:16 +1000' boots without problems.
Next randomly chosen builds Slacko64 6.9.9.9 - BUILD_FROM_WOOF='HEAD;13ab3443f;2019-11-01 23:08:30 +0800' and Slacko64 6.9.9.9 - BUILD_FROM_WOOF='HEAD;2a16b67d5;2019-10-20 09:01:22 +0800' are booting but xorg is failing with error:
I attach my PupSysInfo.
I tried also to track breaking change. I know that ScPup 19.09 works and 20.01 don't.
As I was expected, Slacko64 6.9.9.9 - BUILD_FROM_WOOF='HEAD;12196cacc;2019-09-15 07:49:16 +1000' boots without problems.
Next randomly chosen builds Slacko64 6.9.9.9 - BUILD_FROM_WOOF='HEAD;13ab3443f;2019-11-01 23:08:30 +0800' and Slacko64 6.9.9.9 - BUILD_FROM_WOOF='HEAD;2a16b67d5;2019-10-20 09:01:22 +0800' are booting but xorg is failing with error:
Code: Select all
/usr/libexex/Xorg: error while loading shared libraries: libudev.so.1: cannot open shared object file: No such file or directory
- Attachments
-
- pupsysinfo.txt.gz
- (3.69 KiB) Downloaded 40 times
These are the systems we should be considering:
ScPup32 System built on: Sat May 2 16:50:32 BST 2020
3ae78a543f5ba2fdb9a1bb7c2098d77d ScPup-20.01+6-T.iso
BUILD_FROM_WOOF='testing;291ac8276;2020-05-02 04:38:20 +1000'
kernel 4.14.160 32bit-pae
====================
ScPup64 System built on: Sat May 2 09:47:03 BST 2020
76edc3612a308d8925c973bedde62883 ScPup64-20.01+6-T.iso
BUILD_FROM_WOOF='testing;291ac8276;2020-05-02 04:38:20 +1000'
kernel 5.4.6 64bit
====================
"We" need to determine whether the problem comes from the kernel or Woof-CE or Slackware Current....
It might be useful if somebody with the problem could try the ScPup32 kernel in UPupEF32.....thanks
====================
UPupEF32 System built on: Sun May 24 11:32:11 BST 2020
2a572a9829a31571abad32ffad10a5bf UPupEF-20.04+3.iso
BUILD_FROM_WOOF='testing;f7dd416c3;2020-05-24 17:20:36 +1000'
kernel 4.14.176 32bit-pae
ScPup32 System built on: Sat May 2 16:50:32 BST 2020
3ae78a543f5ba2fdb9a1bb7c2098d77d ScPup-20.01+6-T.iso
BUILD_FROM_WOOF='testing;291ac8276;2020-05-02 04:38:20 +1000'
kernel 4.14.160 32bit-pae
====================
ScPup64 System built on: Sat May 2 09:47:03 BST 2020
76edc3612a308d8925c973bedde62883 ScPup64-20.01+6-T.iso
BUILD_FROM_WOOF='testing;291ac8276;2020-05-02 04:38:20 +1000'
kernel 5.4.6 64bit
====================
"We" need to determine whether the problem comes from the kernel or Woof-CE or Slackware Current....
It might be useful if somebody with the problem could try the ScPup32 kernel in UPupEF32.....thanks
====================
UPupEF32 System built on: Sun May 24 11:32:11 BST 2020
2a572a9829a31571abad32ffad10a5bf UPupEF-20.04+3.iso
BUILD_FROM_WOOF='testing;f7dd416c3;2020-05-24 17:20:36 +1000'
kernel 4.14.176 32bit-pae
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Can somebody with "the problem" please try 32-bit kernel 5.4.37 from Porteus:
http://www.smokey01.com/peebee/download ... cpup32.sfs - open the sfs and copy the 2 files to the ScPup32 frugal install folder. Reboot.
My HP550 laptop does boot ScPup32 with k4.14.160 however there are crash reports in dmesg.... these go away with the Porteus kernel..... clutching at straws ....
Thanks
http://www.smokey01.com/peebee/download ... cpup32.sfs - open the sfs and copy the 2 files to the ScPup32 frugal install folder. Reboot.
My HP550 laptop does boot ScPup32 with k4.14.160 however there are crash reports in dmesg.... these go away with the Porteus kernel..... clutching at straws ....
Thanks
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Still the same kernel panic for all mentioned kernels.
Kernel version seems not relevant. (maybe...)
If this might be helpful, I downloaded Slackware live distro https://slackware.nl/slackware-live/ and it boots without problems.
Kernel version seems not relevant. (maybe...)
If this might be helpful, I downloaded Slackware live distro https://slackware.nl/slackware-live/ and it boots without problems.
No help on my HP Stream Laptop 14peebee wrote:Can somebody with "the problem" please try 32-bit kernel 5.4.37 from Porteus:
http://www.smokey01.com/peebee/download ... cpup32.sfs - open the sfs and copy the 2 files to the ScPup32 frugal install folder. Reboot.
Thanks
Intel(R) Celeron(R) N4000 CPU @ 1.10GHz
4GB memory, Intel graphics.
Still get kernel panic.
I did try to use the initrd.gz from Bionicpup64 8.0 in ScPup64-20.01+6.
It booted with no kernel panic, but stopped with could not find the sfs files.
That is understandable.
This initrd.gz from Bionicpup is looking for sfs files for Bionicpup not ScPup64.
So, maybe there is something wrong in the initrd.gz that is in ScPup64.
I notice it is much newer version, than the one in Bionicpup64.
Woof-CE developers, have been doing some tweaking of the initrd.
I did not try switching initrd.gz in ScPup32.
I assume it would have same results.
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
Thanks for the tests.........
https://github.com/puppylinux-woof-CE/w ... itrd-progs
shows the changes to initrd in recent times.......
ScPup = BUILD_FROM_WOOF='testing;291ac8276;2020-05-02 04:38:20 +1000'
so all commits should be included as at 2 May.....
I can't see anything that might be relevant to "the problem" - can anybody else?
So how to pursue?? Probably the first thing to do is to go back to:
ScPup-20.01+0-T.iso
which was:
BUILD_FROM_WOOF='testing;7890189c5;2019-12-28 08:51:15 +0100'
if "the problem" is not present in +0 - try the initrd from +0 with the other components from +6 ?
if the problem is seen in 20.01+0 we can step back to:
ScPup-19.09+7-uefi-T.iso
which has:
BUILD_FROM_WOOF='testing;5fc3e8fe3;2019-12-01 17:02:13 +1000'
Thanks!
https://github.com/puppylinux-woof-CE/w ... itrd-progs
shows the changes to initrd in recent times.......
ScPup = BUILD_FROM_WOOF='testing;291ac8276;2020-05-02 04:38:20 +1000'
so all commits should be included as at 2 May.....
I can't see anything that might be relevant to "the problem" - can anybody else?
So how to pursue?? Probably the first thing to do is to go back to:
ScPup-20.01+0-T.iso
which was:
BUILD_FROM_WOOF='testing;7890189c5;2019-12-28 08:51:15 +0100'
if "the problem" is not present in +0 - try the initrd from +0 with the other components from +6 ?
if the problem is seen in 20.01+0 we can step back to:
ScPup-19.09+7-uefi-T.iso
which has:
BUILD_FROM_WOOF='testing;5fc3e8fe3;2019-12-01 17:02:13 +1000'
Thanks!
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Yes, this is initrd with "the problem".
Although initrd from BUILD_FROM_WOOF='testing;7890189c5;2019-12-28 08:51:15 +0100' did not work in my case.
I had to go back to ScPup64-19.09+0-uefi-T.iso which is BUILD_FROM_WOOF='testing;12196cacc;2019-09-15 07:49:16 +1000'. Initrd from this ScPup boots without problems.
Although initrd from BUILD_FROM_WOOF='testing;7890189c5;2019-12-28 08:51:15 +0100' did not work in my case.
I had to go back to ScPup64-19.09+0-uefi-T.iso which is BUILD_FROM_WOOF='testing;12196cacc;2019-09-15 07:49:16 +1000'. Initrd from this ScPup boots without problems.
FYI,bigpup wrote:I did try to use the initrd.gz from Bionicpup64 8.0 in ScPup64-20.01+6.
It booted with no kernel panic, but stopped with could not find the sfs files.
That is understandable.
This initrd.gz from Bionicpup is looking for sfs files for Bionicpup not ScPup64.
you can usually get an initrd.gz to boot a different Puppy, by replacing the file '/DISTRO_SPECS' in the initrd.gz with the '/etc/DISTRO_SPECS' from the target Puppy.
gyro
@mash & @bigpup
Please try a hybrid install - all the components from 20.01+6 but renamed:and:
replace the initrd.gz with that from 19.09+0
if that install boots with no kernel panic, please swap the initrd.gz for that from 19.09+7:
http://www.smokey01.com/peebee/download ... 9+7.tar.xz
or
http://www.smokey01.com/peebee/download ... 9+7.tar.xz
We may have to repeat this with different versions of 19.09 to narrow down which commit is causing the problem.
p.s. the rename above has the same effect as @gyro's suggestion but is probably easier....
Please try a hybrid install - all the components from 20.01+6 but renamed:
Code: Select all
rename 20.01 19.09 *.sfs
replace the initrd.gz with that from 19.09+0
if that install boots with no kernel panic, please swap the initrd.gz for that from 19.09+7:
http://www.smokey01.com/peebee/download ... 9+7.tar.xz
or
http://www.smokey01.com/peebee/download ... 9+7.tar.xz
We may have to repeat this with different versions of 19.09 to narrow down which commit is causing the problem.
p.s. the rename above has the same effect as @gyro's suggestion but is probably easier....
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
19.09+7 works. I already have been testing some other builds and have another one working BUILD_FROM_WOOF='HEAD;f53e2b980;2019-12-01 19:44:38 +1000'. It is from 1st December as yours test initrd.
I was renaming DISTRO_SPECS as gyro sugest. Simple in expanded initrd folder.
Unfortunately this forum does not allow to paste 1MB file.
Looking at the initrd-progs git history there are 6th and 9th December changes to check. I will build the cb7ac56 version and go back here to report.
I was renaming DISTRO_SPECS as gyro sugest. Simple
Code: Select all
sed -i 's/19.09/20.01/g' DISTRO_SPECS'
Unfortunately this forum does not allow to paste 1MB file.
Looking at the initrd-progs git history there are 6th and 9th December changes to check. I will build the cb7ac56 version and go back here to report.
Both unfortunate, true and AFAIK unavoidable. Which is why I have an account here, https://www.mediafire.com/ It's free and provides 50 Gb of storage from which I can share files. As it is free I try not to abuse it, from time to time deleting files no longer serving a useful purpose. All mediafire asks for is a valid email address. It doesn't care whether or not it's one you rarely use.mash wrote:...Unfortunately this forum does not allow to paste 1MB file...
As I've had my account for 10 years, they've never lost a file, never sent me junk mail and only suggest an upgrade to their paid version when I log in, I highly recommend this company.
This worked for me too.peebee wrote:@mash & @bigpup
Please try a hybrid install - all the components from 20.01+6 but renamed:and:Code: Select all
rename[url]http://www.smokey01.com/peebee/downloads/test/initrd32%20ScPup-19.09+7.tar.xz[/url] 20.01 19.09 *.sfs
replace the initrd.gz with that from 19.09+0
if that install boots with no kernel panic, please swap the initrd.gz for that from 19.09+7:
http://www.smokey01.com/peebee/download ... 9+7.tar.xz
Replacing the initrd.gz and ScPup64 20.01+6 boots to working desktop.
I went right to using the initrd.gz from ScPup64-19.09+7
Did not try the 32bit version of ScPup 20.01+6.
But, it should give same results, using the initrd.gz from 19.09+7
Did not try other versions initrd.gz's.
Well, I guess I proved the initrd.gz from v19.09+7
works for fixing kernel panic.
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
ScPup64 20.01+6
Frugal install using save folder.
No wifi support for my wifi hardware.
Have not tried getting the needed firmware as your info pop up suggests.
Not really sure if this is really the best thing to make people have to do.
Realtek seems to have a lot of new hardware people are buying.
Bionicpup64 8.0 had to update needed support for several different newer Realtek hardware.
Update:
Got the needed firmware installed.
Need the kernel driver.
r8822be.ko
Frugal install using save folder.
No wifi support for my wifi hardware.
Code: Select all
Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8822BE 802.11a/b/g/n/ac WiFi adapter [10ec:b822]
• Kernel Driver: r8822beS
• Memory Used: 768.00 KB
• Path: /lib/modules/4.19.23/kernel/drivers/staging/rtlwifi/r8822be.ko
• Description: Realtek 802.11n PCI wireless core
• Description: PCI basic driver for rtlwifi
• Description: Realtek 8822BE 802.11n PCI wireless
Not really sure if this is really the best thing to make people have to do.
Realtek seems to have a lot of new hardware people are buying.
Bionicpup64 8.0 had to update needed support for several different newer Realtek hardware.
Update:
Got the needed firmware installed.
Need the kernel driver.
r8822be.ko
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
Anyone who wants to check my versions, you can download them here:
https://www.mediafire.com/file/a72erhw7 ... 01.gz/file
https://www.mediafire.com/file/t04tekv7 ... 06.gz/file
Rename it to initrd.gz and place in the frugal install folder. These are for ScPup64_20.01.
First one should probably work, the second one should fail with kernel panic.
https://www.mediafire.com/file/a72erhw7 ... 01.gz/file
https://www.mediafire.com/file/t04tekv7 ... 06.gz/file
Rename it to initrd.gz and place in the frugal install folder. These are for ScPup64_20.01.
First one should probably work, the second one should fail with kernel panic.
Many thanks for all the testing - seems like we're narrowing it down to something that changed in woof-ce between:
2019-12-01 19:44:38 +1000
& 2019-12-06 22:02:47 +1000
There were many woof-ce commits in this time period:
https://github.com/puppylinux-woof-CE/w ... 29846c+272
https://github.com/puppylinux-woof-CE/w ... 29846c+307
however we can probably discount any with rpi: or pMusic: in their title....
looking at:
https://github.com/puppylinux-woof-CE/w ... itrd-progs
tells us there were 5 commits to initrd-progs:
Commits on Dec 6, 2019
initrd: add wait message if partition needs resizing
01micko committed on 6 Dec 2019
init: improve test for boot drive
01micko committed on 6 Dec 2019
Commits on Dec 1, 2019
init: resize the last partition re 5412315 …
01micko committed on 1 Dec 2019
bugfix resize_part
01micko committed on 1 Dec 2019
resize an image file's last partition if it is of type linux
01micko committed on 1 Dec 2019
None shout out to me as being the culprit??
2019-12-01 19:44:38 +1000
& 2019-12-06 22:02:47 +1000
There were many woof-ce commits in this time period:
https://github.com/puppylinux-woof-CE/w ... 29846c+272
https://github.com/puppylinux-woof-CE/w ... 29846c+307
however we can probably discount any with rpi: or pMusic: in their title....
looking at:
https://github.com/puppylinux-woof-CE/w ... itrd-progs
tells us there were 5 commits to initrd-progs:
Commits on Dec 6, 2019
initrd: add wait message if partition needs resizing
01micko committed on 6 Dec 2019
init: improve test for boot drive
01micko committed on 6 Dec 2019
Commits on Dec 1, 2019
init: resize the last partition re 5412315 …
01micko committed on 1 Dec 2019
bugfix resize_part
01micko committed on 1 Dec 2019
resize an image file's last partition if it is of type linux
01micko committed on 1 Dec 2019
None shout out to me as being the culprit??
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64