Keyboard, mouse don't work after replacing kernel

[Jasper]

Hi @dimkr

I am back to using the stock vanilladpup-10.0.50 and would like to know if it is possible to change the kernel.

I have tried this using @ozsouth 6.6.25 64bit USRMERGE LOW-LATENCY Kernel Aufs/Overlayfs

viewtopic.php?f=65&p=117782#p117782

The bootup was successful and no error messages were displayed and I got to my desktop and it automatically connected to my WiFi.

The issue that arose was that I could use my laptop's touchpad but was unable to use the keyboard.

I also have a USB mouse connected and that did not function too.

Any suggestions?

[dimkr]

It is possible to swap the kernel (as long as fdrv and zdrv are usrmerge-adjusted), but kernels are easy to misconfigure (missing drivers, bad defaults, settings that make more sense for servers rather than PCs, etc') so expect varying quality. Kernel configuration files are ~10k lines, and that means infinite room for human error.

If you want to retrofit a kernel newer than the one in Debian 12, I can recommend stealing the kernel from a Vanilla Dpup 11.0.x development build at https://github.com/vanilla-dpup/unstable/releases. It's built the same way as the 10.0.x kernels: this is the Debian kernel, with very very very few tweaks to make it work under Puppy. However, 11.0.x tracks Debian testing (= Debian 13 development), so the kernel is much newer: currently it's 6.6.x but it will eventually jump to 6.8.x and beyond.

To do so, download an image, decompress it and mount the partition:

Code: Select all

~# gunzip vanilladpup-11.0.115-labwc-uefi.img.gz
~# losetup -fP --show vanilladpup-11.0.115-labwc-uefi.img
/dev/loop6
~# mkdir /tmp/x /tmp/y
~# mount /dev/loop6p1 /tmp/x
~# mount /dev/loop6p2 /tmp/y

Then, you have vmlinuz, ucode.cpio, zdrv*.sfs and fdrv*.sfs in /tmp/x or /tmp/y. Replace the files in your 10.0.x installation with these ones (after renaming fdrv and zdrv to the correct names) and this kernel should work fine.

If you want to go even more 'bleeding-edge', you can try https://github.com/vanilla-dpup/woof-CE ... kernel.yml. Select the latest job run, go to Artifacts and there you can find a kernel based on the Debian unstable kernel, which is even newer than the one in Debian testing (currently 6.7.x).

[Jasper]

@dimkr

I have encountered a small problem initially

I am using Fossapup95 presently and will try again on the VanillaDpup install to see if I can view the contents contained with 'X' & 'Y'.

At the moment both directory are empty

[dimkr]

@Jasper In your case it's /dev/loop5, hence /dev/loop5p1 and /dev/loop5p2.

[ozsouth]

@Jasper - my kernels are suited to generic puppies. Vanilladpup is configured for Debian, so don't mix them. As dimkr says, there are many ways to misconfigure kernels. I know the day is coming when my configs won't cut it - actually thought it had happened a year ago, but with older mainline pups still seems ok for now.

[dimkr]

Vanilladpup is configured for Debian

The opposite, it's the Debian kernel - it's built from the Debian kernel source as-is, without big patches like aufs, inside a clean Debian container with Debian's GCC, etc'. And it's built with Debian's kernel configuration plus few (130 out of 10k+, which is about 0.01%) overrides for Puppy (see https://github.com/puppylinux-woof-CE/w ... s/bookworm). Most of them are must-haves for it to boot from a certain kind of device, partition or file system, but some of them are only related to resource usage or performance. Any working kernel from another distro should work for Puppy, if the must-haves among these 130 settings are changed to the value that's suitable for Puppy and you rebuild the kernel correctly (clean, known-to-work build environment with same development tools installed, etc').

If you configure a kernel from scratch, you have 10k lines to look at, and it's super easy to miss these 130 important lines. This is the only reason why some Puppy kernels seem to work better, and why some kernels randomly fail to boot from the eMMC in this Chromebook or the SD card reader in that laptop.

[Jasper]

@dimkr

The change to '5' does the trick

I seem to have messed up my files somehow

One thing I did notice is that the initrd has a different extension in the latest build ie zst instead of gz.

Also, I have been switching between the regular and retro ISO as I am having difficulties with restarting X on the initial desktop. The screen just turns black and the mouse only remains on the desktop. Tried this 3x on two different devices. Strange as it worked perfectly before.

Determined to get it work, so will preserve ...... not sure if I simply swapped over the fdrv when I was using the retro build.

As always, rushing in

[dimkr]

One thing I did notice is that the initrd has a different extension in the latest build ie zst instead of gz.

Don't take initrd.zst from there! It won't work with 10.0.x.

Take only vmlinuz, ucode.cpio, fdrv and zdrv.

[Jasper]

@dimkr

I have tried this again, substituting the loop number to the corresponding one ie 4.

The directory informs me that it is 1.7gb and should contain the fdrv etc but it is empty

I do remember that I did not/could not unmount previously, so just powered down.

The X directory does contain the boot files only.

Is there a way to retrieve the contents?

[dimkr]

The X directory does contain the boot files only.

What do you mean by "boot files"?

Is there a way to retrieve the contents?

The contents of SFSs? You can view their contents just like any other SFS.

[Jasper]

@dimkr

After you spotted my initial error I could see the contents of both X and Y directorys.

From memory X contain a directory Boot/EFI (only a single directory).

The Y directory did contain the ucode, fdrv, etc.

I did try this again running through the same commands and noticed the loop(number) changed. A few times it said 7 and then 4.

I changed the commands with the number presented onscreen.

Now, I can see the directory's X and Y but in the Y directory there are only the 2 folders the other contents are not viewable.

I did try the 'See All' option in Rox and there is no difference in the display.

I checked the Properties and the Y directory has 1.7gb of content contained within but I cannot see it, weird I know.

Also, I should have mentioned that I could not unmount the contents so, just have to power down and then it unmounts the drive itself.

I have to be honest, I most probably did something wrong myself, but cannot figure out what exactly.

[dimkr]

It's a writable image, it's not read-only. Maybe you moved the files out of it, so now it appears empty.

Maybe try to redownload?