Experimental Slacko64 - eSlacko - UPDATE (closed)

[01micko]

eSlacko64 is an experimental puppy release to test out some experimental init ideas by @gyrog. This is to test out booting from usb/sdcard/mmc to see if waiting for the device is better than waiting for the USB susbsystem.

NOTE: new version is released to add @gyrog 's improvements to saving with the SAVESPEC file and for booting an ISO file from usb

Download

eslacko64-6.9.9.12.iso 350MB
devx_eslacko64_6.9.9.10.sfs devx 134MB (this is the old one, use it)

checksums
0efee6f9d007aab0bb9652f0973e7dfc eslacko64-6.9.9.12.iso

-----------------

Please test USB, sdcard, MMC installs as well as normal frugal installs. frugalpup by @gyrog , a program to install pups to almost any media in both legacy BIOS mode and UEFI secure boot mode is included.

Also included is the 5.4.70 real time (RT) kernel which is also experimental. This is just something I added because I could. Stability so far is 8 hours without issues! This should not affect any boot issues, but may affect day to day stability issues so this release should be treated as alpha software. Don't use it in a production situation. For testing only. As for the rest of userspace, well not much is new but it should mostly work. Report what you think is necessary as not a hell of a lot of testing by me has been done.

I do not need to know about geany and rox-filer bugs. They will be fixed in due course.

Have fun!

[bigpup]

Tried it as a frugal install (setup by Frugalpup installer), on a USB flash drive, with more than one USB drives plugged into computer.
This seems to work and boots with no problem.

Other Puppies, on the same USB, cannot boot if there are other USB drives plugged in.
They report problems finding the needed files on the USB.

Cannot test on a SD card on this computer.

[gyrog]

Tried it as a frugal install (setup by Frugalpup installer), on a USB flash drive, with more than one USB drives plugged into computer.
This seems to work and boots with no problem.

Did you notice a "Waiting for partition [<partition-id>]" message flash by on the console early in the boot?

[bigpup]

Yes, I do see that "Waiting for partition [<partition-id>]" message.
Then it continues to do a normal boot to desktop.

[gyrog]

Yes, I do see that "Waiting for partition [<partition-id>]" message.

Good, the different "Waiting" message is the indication that the experimental 'init' script is actually in use.
Thanks for testing.

Edit: Of course it is very good news that it seems to be fixing the multiple usb drive issue.

[bigpup]

Tried it installed on a SD card using Frugalpup Installer to do the install.

with one or more USB drives plugged into computer.
This seems to work and boots with no problem.

Other Puppies, on the same SD card, cannot boot if there are USB drives plugged in.
They report problems finding the needed files on the SD card.

[bigpup]

I have one laptop that has not been able to boot from a Puppy installed to the internal emmc.
Always get the error message not being able to find the Puppy files.

Installed eslacko64, using frugalpup installer, on the internal emmc.
eslacko64 can boot with no problem.
Boots to working desktop.
Posting this from it.

Fossapup64 9.5 on the internal emmc will not boot. Gives the error messages not finding files.

Note:
This is on a Chromebook using a completely replaced bios firmware by MrChromebox.
So not a normal bios.
But hey, it works with your change to the initrd!!!!

[gyrog]

I have one laptop that has not been able to boot from a Puppy installed to the internal emmc.
Always get the error message not being able to find the Puppy files.

Installed eslacko64, using frugalpup installer, on the internal emmc.
eslacko64 can boot with no problem.
Boots to working desktop.

Excellent news.

Did you get a "Waitiing" message?
I've often wondered if one of Puppy's difficulties with emmc drives might be that they reqired some waiting, not supplied by 'wait4usb'.

[Clarity]

Standard that I use for booting ALL 2020 PUPs is via SuperGrub2 (SG2D).

All ISOs are placed in the BOOTISOS folder.

This system, prior to boot, has a non-bootable USB-HDD, and a SG2D USB stick which everyone knows is bootable. This system has no HDD.
Note: In the past, this configuration would not boot via the SG2D USB unless the USB-HDD was disconnected before boot.

The SG2D USB along with the USB-HDD present, booted eSlacko64 without ANY issues to desktop.

I have attached the pertinent log files for development review.

I have 2 other configurations where the system will not boot when their USB-HDDs are present using the past 2020 PUPs. Will report when tests are done on each of those platforms.

Relevant to developers/users?
When desktop arrives, the USB-HDD is shown as sda while the booting SG2D stick is shown as sdb. This is the usual occurences on ALL SG2D disc/disk boots. It is not abnormal behavior.

[gyrog]

The SG2D USB along with the USB-HDD present, booted eSlacko64 without ANY issues to desktop.

Great news,
and thanks for testing.

Did you get a "Waiting" message on the console early in the boot?
If so what was it?
(The "Waiting" message gives a clear indication if the new "waiting" algorithm was activated.)

It's interesting looking at your "bootinit.log", the 'init' scsript is not picking-up the filesystem type of the 'loop0' device,
this is because the 'init' script looks for it in a list that contains only real partitions along with their filesystem types, the "search" code has similar problems.
Fortunately, this little issue does not appear to prevent a sucessful boot.
The code is quite "real partition" centric, but it doesn't have to be. It could do with a re-write using 'blkid' to get the information, but not today.

[watchdog]

My Asus K52N laptop does not support usb boot. I use Plop boot manager to boot usb sticks and it works in the usual manner. I have tried to use a mmc sd card 4 gb with eslacko64. No go. Used msdos and gpt partiton table. Grubfordos and grub2 and frugalpup. The sd card does not boot.

[gyrog]

My Asus K52N laptop does not support usb boot. I use Plop boot manager to boot usb sticks and it works in the usual manner. I have tried to use a mmc sd card 4 gb with eslacko64. No go. Used msdos and gpt partiton table. Grubfordos and grub2 and frugalpup. The sd card does not boot.

Depending on when the failure occurs in the boot process, this could be a hardware limitation, bootloader issue, or Puppy issue.
The last message on the console when the boot fails, should provide an indication.

[watchdog]

Depending on when the failure occurs in the boot process, this could be a hardware limitation, bootloader issue, or Puppy issue.
The last message on the console when the boot fails, should provide an indication.

I think a hardware limitation: Plop boot manager does not find the mmc as usb partition to boot.

[bigpup]

I have one laptop that has not been able to boot from a Puppy installed to the internal emmc.
Always get the error message not being able to find the Puppy files.

Installed eslacko64, using frugalpup installer, on the internal emmc.
eslacko64 can boot with no problem.
Boots to working desktop.

Excellent news.

Did you get a "Waitiing" message?
I've often wondered if one of Puppy's difficulties with emmc drives might be that they reqired some waiting, not supplied by 'wait4usb'.

No, I see no waiting message.
Just the normal boot messages.
This is probably not the best computer to test this on. It is not using a normal bios.
But your code changes did make it work when it did not.

[watchdog]

I have had someway success installing to mmcblk0p1 sd card fat32 formatted booting with Plopkexec:

https://www.plop.at/en/plopkexec/full.html

I just copied some selected files from the iso with the following isolinux.cfg:

Code: Select all

default syslinux
LABEL syslinux
COM32 /chain.c32
kernel /vmlinuz 
append initrd=/initrd.gz pmedia=ataflash pfix=fsck

Then I have run:

Code: Select all

syslinux --install --force /dev/mmcblk0p1

pic.png (91.78 KiB) Viewed 4517 times

EDIT: the same worked for ScPup64.

EDIT1: obsolete. Read:

viewtopic.php?p=8137#p8137

[Clarity]

@gyrog, sorry for the delay. You asked for the "waiting ...". Here is the booting console log.

eSlacko64 console log2.jpg (39.43 KiB) Viewed 4480 times

[gyrog]

@Clarity,
Thanks.
I should have expected that, a call to 'wait_for_dev' is coded into the '/sbin/isoboot' script.
It would be nicer if you got a "Waiting for partition [iso9660]" message, but it would seem that that wouild require a complete rework of the 'isoboot' stuff.
I'll settle for "it works", for now.

[gyrog]

No, I see no waiting message.
Just the normal boot messages.
This is probably not the best computer to test this on. It is not using a normal bios.
But your code changes did make it work when it did not.

Thanks.
Hmmm..it might not be my "Waiting" changes to 'init', since there is no "Waiting" message, it's doesn't seem to be waiting for something it didn't wait for before. So there is a possibility that it is working because the eSlacko kernel has improved mmc support, after all we only sorted out proper mmc support in the kernel, a few months ago.

The only way to be sure, would be to replace the kernel (and zdrv) in a suitable Puppy that previously failed, with the kernel (and zdrv) from eSlacko.

[gyrog]

I have had someway success installing to mmcblk0p1 sd card fat32 formatted booting with Plopkexec:

Very interesting.
I'm not particularly familiar with 'plopkexec', so I may have this completly wrong:

The initial boot is some bootloader on 'sda1' which then boots 'plopkexec' which then chains to syslinux on 'mmcblk0p1', which boots Puppy?

Hmmm...this is getting quite off topic. But I'm sure yours is not the only machine that refuses to boot for an SD card.
So perhaps you could outline exactly how this works, on a more appropriate topic, and report here, which topic that is.

[watchdog]

I have had someway success installing to mmcblk0p1 sd card fat32 formatted booting with Plopkexec:

Very interesting.
I'm not particularly familiar with 'plopkexec', so I may have this completly wrong:

The initial boot is some bootloader on 'sda1' which then boots 'plopkexec' which then chains to syslinux on 'mmcblk0p1', which boots Puppy?

Hmmm...this is getting quite off topic. But I'm sure yours is not the only machine that refuses to boot for an SD card.
So perhaps you could outline exactly how this works, on a more appropriate topic, and report here, which topic that is.

Done. Thanks @gyrog.

viewtopic.php?f=85&t=1133

[gyrog]

@Clarity,
Would you be comfortable with replacing the 'initrd.gz' file in the eSlacko iso with a different test 'initrd.gz'?
I have a couple of ideas for changing the 'isoboot' and 'init' scripts to make better use of the new "Waiting" method.
And it takes a lot longer for me to upload a complete iso, rather than a single 'initrd.gz' file.

Just to be sure, to be sure:
When you are booting an iso file, this is done via a bootentry that resides on some re-writable device, and so can easily be edited?
e.g. you could easily add a "pdrv=" boot parameter?

[cthisbear]

Hello old friends.

I decided to give this 64 Pup a try.

Considering I have a multipup usb I have stuffed up the booting needed for this Slacko.

For Slacko64 I have named it as a folder in lowercase as is my normal practice.

slacko64

:::

As I use Radky most of the time my menu is ....

title Radky Stretch 2 (sdc1/radkyStretch)
find --set-root --ignore-floppies /radkyStretch/initrd.gz
kernel /radkyStretch/vmlinuz pmedia=usbflash psubdir=radkyStretch pfix=fsck
initrd /radkyStretch/initrd.gz

I had an issue with my last Pup I downloaded just before the Murga crash,
so I couldn't fix it.

Should the boot be something like this considering the sfs is named...
puppy_eslacko64_6.9.9.10.sfs

title Slacko64 Oct2020 (sdc1/slacko64)
"Start slacko64"
linux /vmlinuz pmedia=usbflash
initrd /initrd.gz

This is what doesn't finish booting..

title Slacko64 Oct2020 (sdc1/slacko64)
find --set-root --ignore-floppies /slacko64/initrd.gz
kernel /slacko64/vmlinuz pmedia=usbflash psubdir=slacko64 pfix=fsck
initrd /slacko64/initrd.gz

Thanks Chris

[01micko]

@cthisbear welcome to the new normal!

I usually have the UUID of the partition in the 'find --set-root' line. The name of the partition also works (if it has a name).

Puppy's init has probably changed substantially since dpup-stretch 7.5.

If you can possibly use 'frugalpup' (in the menu) to install it would be helpful.

Other wise, use the lines you have in the menu.lst with a major change to the 'find --set-root' line.

If you can, from a running pup (or other linux as root) run this:

Code: Select all

blkid /dev/$DEVICE

where $DEVICE is sda1, sda2, sdb1, sdb2 or whatever your USB partition where puppy is installed is.

Here is my case (note using an mmc card instead of USB stick)

Code: Select all

# blkid /dev/mmcblk0p2
/dev/mmcblk0p2: UUID="087633fd-caec-413d-91e6-95a8e267b365" TYPE="f2fs" PARTUUID="19ce9256-02"

If I were using grub4dos to boot I would have my 'find' line as so:

Code: Select all

find --set-root uuid () 087633fd-caec-413d-91e6-95a8e267b365

..and on my kernel line..

Code: Select all

kernel=/slacko64/vmlinuz pdrv=087633fd-caec-413d-91e6-95a8e267b365 pmedia=usbflash psubdir=slacko64 pfix=fsck

'frugalpup' does all this for you.

HTH

(gyrog, please correct me if wrong)

[gyrog]

I'm not going to say @01micko is wrong, but I am going to generate a slightly different one, easily.

In a console, I issue the command:

Code: Select all

bootentry /mnt/home/puppy/eslacko64 g4dos > boot.txt

The file 'boot.txt' then contains:

Code: Select all

title Puppy eslacko64 6.9.9.10
    find --set-root --ignore-floppies uuid () 0db94719-cdf1-44b7-9766-23db62fb85a5
    kernel /puppy/eslacko64/vmlinuz libata.noacpi=1 net.ifnames=0 pmedia=atahd pdrv=Work psubdir=/puppy/eslacko64 pfix=fsck,fsckp TZ=AEST-10
    initrd /puppy/eslacko64/initrd.gz

Notes:
1 'bootentry' identifies the partition to 'grub4dos' using the UUID, but identifies the partition to the 'init' script using the Volume Label (pdrv=Work), if one exists, in preference to the UUID. "Waiting for partition [Work]" is more recognisable than "Waiting for partition [0db94719-cdf1-44b7-9766-23db62fb85a5]".
2 There is a "pdrv=" parameter, this enables the 'init' script to go straight to the partition that contains the Pupppy frugal install diretory, without resorting to any "searching". I would strongly recommend this practice.
(When you install Puppy and create the boot entry, you must know exactly where you wrote the Puppy files, so why keep this informatiion a secret from the 'init' script and force it to guess?)

@cthisbear Since your boot entry does not contain a "pdrv=" parameter, the 'init' script will use it's "search" code.
I will give "searching" another test by removing the "pdrv=" parameter from my eslacko64 boot entry.

bootentry is the script used by FrugalPup utilities to generate boot entries, you can get a "Usage" message with:

Code: Select all

bootentry

Provided of course, that you have the FrugalPup package installed. If it is not in the Puppy you are using, download 'frugalpup_20.sfs' and load it with 'sfs_load'.

[gyrog]

Reporting on recent tests:

All boots proceeded sucessfully to desktop.

On an internal HD, there were no "Waiting" messages, with or without the "pdrv=" boot parameter.
On a usb HD, there was a "Waiting 5 seconds" message (lasting 5 seconds) without the "pdrv=" boot parameter, and a "Waiting for partition [t2Lin]" message (lasting 1 second) with the "pdrv=" parameter.

In each case the contents of 'bootinit.log' indicated that "searching" code was used without "pdrv=" parameter, and not used with the "pdrv=" parameter.

So, on my machine, eslacko64 is working exactly as expected.

@cthisbear What is the last message displayed?
If you do not add a "pdrv=" parameter to you boot entry, you could add a "waitdev=10" boot parameter.
This will set the wait time for slow devices in the "searhing" code to 10 seconds, in case your usb device is very slow.

[baldronicus]

Hi @01micko and @gyrog .

So far I have only tried booting the test eslacko64 from a USB as follows.
a) Added a directory "eslacko64-test" to the "OS" partition on a USB drive used to boot Fatdog64-811 and multiple Puppies. The setup is derived from the Fatdog64-811 usb-boot-mbr.img.
Although I would normally only copy a subset of the files in the ISO across to the directory, in this case I copied all of them.
Modified grub.cfg on the USB drive to add two entries, one eslacko-test1 (without the pdrv parameter) and eslacko-test2-pdrv (with pdrv=OS).

1st test on an AMD A4-9125 based laptop in Legacy/CSM mode:
Booting with "...-test1" resulted in "Waiting for 5 seconds for slow storage devices" coming up early in the process.
The Puppy files seemed to load, but it didn't boot to a desktop, not being able to load "X".
Booting with "...-test2-pdrv" resulted in "Waiting for partition[OS]" appearing early in the process. Again Puppy files seemed to load, but the OS was unable to proceed to a desktop.
I didn't pursue things any further in either case since I suspect the element being tested had worked as expected and this machine can be finicky (needing nomodeset at times, etc).
Edit-[I suspect it may not like the real time kernel, or I might have missed something.] [should be] Heck, I'm dense. Because it is nice and easier, I have been booting off a USB drive with Fatdog and multiple Puppies. However, they are booting with the parameters that I have put into the grub.cfg file, not the parameters and options available in their respective boot menus. They are not chainloading etc.. Hence, while it mainly works, it probably isn't the best option when trying to test something. D'oh.

2nd test on an AMD A4-9125 based laptop in UEFI only mode:
Essentially the same as above.

3rd test on an AMD Turion64x2 based laptop locked in Legacy/CSM mode:
"test1"- "Waiting for 5 seconds for slow storage devices" (as expected). Booted to desktop.
"test2-pdrv"- Odd, it seemed to go straight to loading the Puppy files (unless I missed the "waiting..." message). Again booted to a desktop.

I was almost going to try to use FrugalPup to do a test installation on this machine, but after reading the Help I bailed out.
Whilst I could be wrong, I get the impression that it might be most suitable for an install to a "fresh/clean" drive. This is only an impression of course.
The "real" problem, that finished any thoughts, was the requirement for a FAT32 partition at the beginning of the drive.
Whilst I understand that a USB drive could be set up to do the boot, this machine has Windows XP, a number of older Linux distros, Fatdog and a directory with Puppies on it.
These are booting from a Legacy Grub setup (not Grub4DOS), the files for which are on a partition following the one holding XP.
I held off since I can see myself getting into a "mess".

I thought I should post something even though I could try some other machines. I was also thinking of just "burning" a CD-RW for "clean" tests on some machines, without any other variables.
However, if I understand correctly, it seems to be working this way.

Would you prefer that I edit this post to add any later test, or a make a fresh post?

Thanks.

Edit- additional info and crud.
The ISO was successfully burnt to a CD-RW. When it booted there was a fleeting message about "No MBR magic", along with some other messages that went by too quickly for me. However it seemed to boot OK, so maybe not relevant. I presume as it was booting from optical media, there were no "Waiting..." messages.
Following this I decided to try to use FrugalPup to install eslacko64 to a USB drive. Blundering Baldronicus Bean Magoo has made a right wondrous mess of this. I think I might try again tomorrow. Between not concentrating and reading properly, together with, I now think, using a suspect USB drive, the result has not been good. The USB drive didn't boot. The BIOS just seemed to keep cycling, trying to get it to work.
Since I did make such a mess of it, there might be some things that might be of interest for later.
Although it is indicated that the partitioning needs to be set up in advance (clearly for the sub unit that I have forgotten the name of. D'oh. But not quite as clearly for FrugalPup- but I think that might just be my interpretation), there doesn't seem to be an actual size requirement given for the leading FAT32 partition on a device (I'll probably see it in bright flashing lights tomorrow). I realise that different environments might have different requirements, but it could be an area where some of us might need guidance.
When the USB drive didn't boot, I thought I would take a look at the boot directory. Being the click-happy nut that I am, I had to see what this phantom "i386-pc" file was, didn't I? Clicking this changed the screen background to black. I don't know what else might have been messed up, so I just rebooted. I have a vague idea that I have seen and done this before. I only mention it case there might be support questions later.
In the end I attempted to use "Boot" to reload the boot environment. It couldn't proceed as the partition was not FAT32, even though a couple of checks with GParted seemed to indicate it was. Hence my suspicion about the USB drive itself.

Apologies for the verbal waffle again.

Thanks.

[baldronicus]

Hi again. Decided to try again. Still had to mess it up a bit, as I forgot to set the "Settings" first and only remembered between the "Puppy" and "Boot" steps. It allowed me to select the "Pfix" option but not the individual settings, but it could be that I didn't give it enough time before clicking on the "Boot" button.
The USB drive (a different one) booted successfully this time. On first boot there were two filesystem check warnings about the date/time being in the future. I think this might have been due to my using UTC. However there were no "Waiting..." messages.
I think the timestamps on the filesystems may have been updated, as subsequent boots only had "e2fsck(?)'' messages that the filesystem with the pups was clean etc.. Again there were no "Waiting..." messages. I don't know if the filesystem checks might override that option, or obscure the advice message.
Oops. This was on an AMD Athlon64 X2 machine, I think.

Thanks.

[gyrog]

@baldronicus,
Amongst all that, you seem to have confirmed that the new "Waiting" code in 'init' works.
If you provide "pdrv=OS", you get a "Waiting for partition [OS]" messaage, if you don't you get a "Waiting for 5 seconds" message.
The duration of this "dumb" waiting can be modified by a "waitdev=n" boot parameter.

Warnings about date/time stamp being in the future can be ignored, they are purely informational.
But I add a "TZ=" boot parameter to my boot entries to ensure that the "init" and the running Puppy are using the same time.

I have also been surprised by the absence of any "Waiting" message when booting from a CD.
But then again there is a patch in 'init' to choose the first 'iso9660' partition that it finds, instead of using it's "searching" code.

From my perspective, if the boot gets past the "Performing a 'switch_root' to the layered filesystem..." message, the 'init' script has finished Ok, problems after that are probably some other issue.

As to the FrugalPup stuff, this is not really the right topic.
But I wiil say that the vfat boot partition does not need to be very big, FrugalPup writes only around about 10MiB to it,
so anything larger than 100MiB is quite adaquate.
Yes, FrugalPup can seem a little stange until you get used to it, but one good thing is that it always has a "Confirm" dialog before it actually does any thing, so you can safely play with it and then "Cancel" out in the "Confirm" dialog if it's not going to do what you expected.

A very easy way to setup a usb stick with Puppy is to use 'f2StickPup'.

[baldronicus]

Hi @gyrog . Thanks very much, both for your advice and for your forbearance in sifting through those posts. My apologies to all, and, in particular, yourself, for the verbose waffling, and for straying off topic. I can't seem to help myself.

Thanks again.

[gyrog]

@baldronicus, You're welcome.