Have just tried lupu_528_k3... on my main desktop machine, hoping that once I get USB3 support working for the laptop, this could be my main Puppy.
Unfortunately, this version won't boot on my Intel D865GLC.
I tried first using the "puppy pfix=ram" parameter, which resulted in an unusually prolonged bout of "pausing" (the word displayed at least four times, I'm afraid I didn't note it carefully).
That was followed by the following text:
lupu_528.sfs not found. Dropping out to initial-ramdisk console.
/bin/sh: can't access tty: job control turned off
At which point the system locked up.
I was particularly surprised by the "...528_sfs not found" message, since obviously the file is on the CD itself. This situation also raises the interesting question of how the boot module distinguishes between the lupu_528.sfs file with the new kernel, and the old one, which has the same name and is sitting in on one of the hard drives in the system.
Could the existence of that older sfs file account for the boot failure? If so, shouldn't the new sfs file have a different name, so that one doesn't have to continually rename or remove the sfs file to use one or the other lupu?
In any case, I next tried booting without arguments, and let the boot loader find all of the lupu-save.2fs files on the system (which again resulted in four "pause" s), before selecting "0 - none" to avoid corrupting any of them.
The system then locked up with 25 rows of the following text on the display:
[188.239542] <IRQ>
Update: after renaming my old lupu_528.sfs file, I rebooted again with the new kernel, this time using both of the following arguments:
The result was exactly the same as the first time, with pfix=ram alone.
Dropping out to initial-ramdisk console.
/bin/sh: can't access tty: job control turned off
I then tried allowing the boot loader to search the system for lupu save files, adding only the
command. This produced a different ending than the previous time:
[176.088021] BUG: unable to handle kernel