Experimental Slacko64 - eSlacko - UPDATE (closed)

[cthisbear]

Thanks for all the replies.

I will try and set my usb up again tomorrow.

I just returned tonight after spending a few days in Mudgee.

Cheers...Chris.

[Clarity]

Hi @Gyrog Sorry for the delay.

Would you be comfortable with replacing the 'initrd.gz' file in the eSlacko iso with a different test 'initrd.gz'?
o
o
o
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?

Yes, I am willing. To do so, I use ISOmaster to mod any ISO I work on. (hopeful that @01micko has the latest version built-in.

You are aware that I use SuperGRUB2 to boot every ISO I use to run my systems. I no longer use or install Frugals for any ISOs going forward as I do not see the need with Puppy Linux's (and Ubuntu/Debian) design. The ISOs boot the system and the sessions(s) that are save is all I ever use anymore, so no more fiddling with Frugals. Once in a while, I will employ ISOmaster to create bootparm changes when necessary and this is one of those. Use of this practice is a time-saver for me

Currently, I have a 2GB SG2D USB which I boot systems from. It finds the BOOTISOS folder that has ISOs and I select the ISO of choice: In this case that would be this eSlacko64 ISO. I have, in the past, chose the "e" option on the eSlacko's Boot screen to edit any kernel parm options necessary. I am not sure what I schould do in PDRV use: Is that to point to the ISO boot partition/drive or to the SG2D drive?

If PM is better for directions while having me post back here with results, I am willing.

[gyrog]

Yes, I am willing. To do so

Thanks.

You are aware that I use SuperGRUB2 to boot every ISO I use to run my systems. I no longer use or install Frugals for any ISOs going forward as I do not see the need with Puppy Linux's (and Ubuntu/Debian) design. The ISOs boot the system and the sessions(s) that are save is all I ever use anymore, so no more fiddling with Frugals. Once in a while, I will employ ISOmaster to create bootparm changes when necessary and this is one of those. Use of this practice is a time-saver for me

That's exactly what I want you to test, I have some ideas for changes to the 'isoboot' support within the 'initrd.gz'.

Hmm...On a second reading of your comment, we may have a little problem, I'm not sure that SuperGrub2 is doing what I assumed it is doing. From the comments inside the 'isobot' script wihtin 'initrd.gz' it looked like grub2 was booting using the files within the ISO, rather than booting the ISO itself.
Do you configure SuperGrub2 for each ISO?
Do you see the splash screen for the ISO, just like you get when booting from a real CD?

Currently, I have a 2GB SG2D USB which I boot systems from. It finds the BOOTISOS folder that has ISOs and I select the ISO of choice: In this case that would be this eSlacko64 ISO. I have, in the past, chose the "e" option on the eSlacko's Boot screen to edit any kernel parm options necessary. I am not sure what I schould do in PDRV use: Is that to point to the ISO boot partition/drive or to the SG2D drive?

With my changes in place, the "prdrv=" parameter would refer to the partition that contains the ISO, the idea is to help the 'init' script locate the ISO quicker.
But I will PM you with directions when I have produced a test 'initrd.gz'.
Hmm...Maybe not.

[gyrog]

I've uploaded an 'eslacko64-initrd.gz' file to https://www.mediafire.com/folder/hkwe9y ... /init-wait.
It contains updated versions of 'init' and '/sbin/isoboot'.
It "improves" the way 'init' supports 'isoboot'.
It is meant as a replacement for the 'initrd.gz' in the eslacko64 iso.

[Clarity]

Hmm...On a second reading of your comment, we may have a little problem, I'm not sure that SuperGrub2 is doing what I assumed it is doing. From the comments inside the 'isobot' script wihtin 'initrd.gz' it looked like grub2 was booting using the files within the ISO, rather than booting the ISO itself.
Do you configure SuperGrub2 for each ISO?
Do you see the splash screen for the ISO, just like you get when booting from a real CD?

SG2D-scroll down to your choice of which download you want to use

1. Simply is a 14MB distro which when expanded to DVD or USB will seek a folder of ISOs on your system when you boot it.
2. The user does NOTHING other than to load ISOs to that folder (in my case I am using a folder named BOOTISOS).
3. When booted, it will present all eligible ISOs found in the folder for user's selection to boot.
4. Whichever one the user selects, SG2D then transfer the booting PC to that ISO and the selected ISO-distro boots as a native on the PC.
5. SG2D does NOTHING in modifying the booting ISO, its contents, its boot menu, nor its boot process, as its ONLY a presenter for selection
6. The ISO, in our cases PUPs, boots, straight away with all the same expectations one gets as if SG2D didn't exist: Thus operations are the same and at end of session (or during), saving the PUPPY-sessions as expected.

NOTES

• SG2D is merely there so that ISOs no longer need to be expanded to media in order for users to boot and use them.
• If users are working with many ISOs as we have in the PUP community, this is a time-saver to gather, test, and use the PUPs, when needed.
• I find it clever, simple and straight-forward for use with 2020 WoofCE PUPs/remasters as well as Ubuntus that I have tested and used this year since discovery.
• It can also run in KVMs.

This is as good a tool for developers who may have multiple iterations for testing as well as for users who have multiple PUPs for tire-kicking. ... too easy to setup...too easee to use!

Little to NO user questions from the seniors/students who now use it; thus no support requirement.
It is Open-Source.

[user1111]

Booted to desktop using the ram only boot menu choice within kvm/qemu, net connected fine

slacko.jpg (126.54 KiB) Viewed 1945 times

Odd arrangement ...

Laptop boots a 5.2MB vmlinuz with integral initrd (and all relevant modules/firmware built in) that boots into vesa framebuffer, wifi net connects and uses framebuffer vnc (fbvnc) to vnc into my desktop system (through a compressed/encrypted ssh tunnel). The desktop has Fatdog booted (gui desktop running) so vnc drops straight into that, and within which I qemu'd the experimental slacko iso.

Ran through quicksetup and set keyboard/locale etc. OK. ran network wizard opting for the simple choice (which is really just setting up a 10.0.2.15 type sub-network connection within the qemu from the Fatdog's 192.168.1.15 network ethernet connection).

The desktop system is very light on ram, 1.7GB available (htop), so even to run Fatdog reasonably I add a swapfile to that. I upped that from a 1GB swapfile to 4GB given that I allocated 2GB to the qemu booting of experimental slacko (i.e. dd'd a 4GB file (dd if=/dev/zero of=swapfile bs=4096 count=1024000), mkswap swapfile; chmod 0600 swapfile;swapon swapfile). Whilst that swap is being used whilst running experimental slacko - its still very responsive (more than comfortably so, given that its also serving the display through ssh/vnc/wifi).

<OT>Note the 24 degrees core cpu temperature. On Sunday I removed the cpu heat sink and fan to clear out a load of crud, had no thermal paste to re-seat the sink and was worried that might cause heat dissipation issues - but apparently not </OT>

EDIT: Has the choice of the original Puppy theme also included

s2.jpg (125.5 KiB) Viewed 1932 times

[Clarity]

@Rufwoof is showing us how to run and test the eSlacko64 PUP in a KVM. Note: He includes the command that is used to boot an ISO file. Very nice depiction for those who want to know how to do these tests in a rapid manner. Thanks are due him!

@Gyrog I have tested the "new" INIT, exchanging it using ISOmaster and booting via SG2D. I used oldest of the 4 UEFI PCs (old except the most recent need BIOS upgrades not done in years).

The result is shown in this GIF

[cthisbear]

Ok! I booted with this...many thanks.

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

My Simplecom wireless was not seen ..as expected.

Using TP-Link TL-WN725N usb adapter...not seen by Frisbee.

Had to add R8188eu to the list in Network Manager to make it connect.
Pita. I thought TP-Link were supported better than that.

I know it's easy to criticise but with Windows 10 as bad as it is,
and still not as nice as Win 7 or my Win7 Lite by eXPerience,
even after my killing it's mind boggling s..t,
getting the Pilgrims across to a more usable OS would be nice if Frisbee in this Slacko
would find the wireless.

I attached a pic.

:::::::

Windows 10 evil..how to fix it as I tested it...

http://www.murga-linux.com/puppy/viewto ... 26#1057726

::::::::::::

Once again no disrespect.

perdido saved me in Radky Stretch with a Simplecom pet.

http://murga-linux.com/puppy/viewtopic. ... 53#1008253

::::::::

One other annoying this is deleting text here with this Firefox,
and the same with Geany text...the delete button doesn't work,
have to hit backspace to delete my poor typing efforts.

Cheers....Chris.

[user1111]

@Rufwoof is showing us how to run and test the eSlacko64 PUP in a KVM. Note: He includes the command that is used to boot an ISO file. Very nice depiction for those who want to know how to do these tests in a rapid manner. Thanks are due him!

Not me Clarity, I had a great coach, that made kvm/qemu easy-peasy when combined with a great system (Fatdog)

https://docs.google.com/document/d/1SaJ ... 7-rzE/edit

As I recall, I did make a minor contribution ... in the way of the QEMU defined Guest PC image within that document Otherwise nada.

[Clarity]

I saw this in the 1st pic of your post.

qemu-system-x86_64 -enable-kvm -m 2048 -cdrom eslacko64.iso

It is a clear sign, IMHO, and thanks. That document (immediately above you show) is very useful and seems to cover an understanding for user use.

I will try to run those steps for this distro; namely eSlacko64 Alpha.

Good work and good info from you.

[bigpup]

cthisbear,

You seem to think this is some kind of new version of Slacko to be released for general use.
IT IS NOT!
It is just to test the ideas being offered to change how Puppy boots.

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.

Use it for nothing else but testing the new way Puppy boots.
Tell us about any boot up problems only.

[cthisbear]

bigpup:

Good day mate.
I was happy to see it boot...so no offense.

I've recently had a bigger internet allowance as Ihotspot on a Circle Life Mobile plan...
100gigs for $28.00 per month.

https://www.circles.life/au/plan/

Because NBN took so long to reach me and I was over it.

So I have plenty of bandwith to play with and I am trying a few Puppies out.

Cheers Biggie....Chris.

[01micko]

UPDATE to eSlacko64 6.9.9.11

Latest woof-ce init-experiment; (however distro-specs doesn't reflect that because I copied over the old DISTRO_SPECS after ./merge2out). New init changes are in place.

See main post for a delta file to upgrade the original iso.

[gyrog]

@01micko,
Thanks for the updated iso file. It functions the way it is supposed to.

The idea behind the update is for 'isoloop' to work like the main 'init' script.
if you specify the partition, then Puppy will wait, if necessary, for that particular partition to become known, no matter what technology is causing the need for the wait.
If you don't specify the partition, then Puppy doesn't know what to wait for, so it waits for an arbitary time, (default is 5 seconds), in the hope that all partitions will be available by then.

The updated 'isoboot' takes 2 boot parameters, "iso_dev=" to specify the partition that contains the iso file,
and the original "find_iso=" that specifies the full path of the iso file, relative to the root directory of the partition.

The partition can be specified by the partition name, volume label, or UUID, just as with the rest of 'init'.

The parameter name "iso_dev" could easily be changed, if there is something else that is more convenient.

Personal note:
To me this update is simply fixing 'init', when I saw that things could be done in a better way.
It is not an endorsment of booting iso files.

[01micko]

Personal note:
To me this update is simply fixing 'init', when I saw that things could be done in a better way.
It is not an endorsment of booting iso files.

It is a bit fiddly booting the iso files. It doesn't necessarily require linux but is certainly easier to use it with supergrub2. I revised the main post.

I successfully used ETP's guide to install supergrub2 and the eslacko iso to a usb stick. Note that it appears that supergrub2 doesn't support secureboot so didn't boot on my laptop and used my desktop that has GPT partitioning (linux only - so no secure boot enabled). It boots fine following ETP's guide. 5 second 'waiting' message was observed. On shutdown there is no offer to save to an alternate location, only the boot partition, which in this use case is absolutely fine IMHO. It saves there fine and found the save directory fine also with no boot paramaters.

HTH

[gyrog]

5 second 'waiting' message was observed. On shutdown there is no offer to save to an alternate location, only the boot partition, which in this use case is absolutely fine IMHO. It saves there fine and found the save directory fine also with no boot paramaters.

That's what I would expect to happen.
'isoboot' sets the partition where it located the ISO file as the specified save partition.
The install partition for an "isoboot" is usually '/dev/loop0'. if no save partition is set, Puppy assumes it can write to the install partition, but trying to save to '/dev/loop0' is not particularly helpful.

Supergrub2 specifies the relative path to the ISO file as a boot parameter when it boots Puppy.
(Otherwise the 'isoboot' script does nothing.)
So why doesn't it specify the other vital piece of information, i.e. the partition that contains the ISO file. It must know this when you select the ISO file for booting?
Or does it?
Could someone who is booting with supergrub2, please report the contents of '/proc/cmdline' on a Puppy that has been booted with supergrub2.
Then I can see exactly what boot parameters it is passing.
Obviously it is not specifying "iso_dev=".

If we can detect the partition from the boot parameters, then 'isoboot' can avoid the arbitary "Waiting 5 seconds", and wait for the detected partition directly, if necessary.

[01micko]

Could someone who is booting with supergrub2, please report the contents of '/proc/cmdline' on a Puppy that has been booted with supergrub2.
Then I can see exactly what boot parameters it is passing.
Obviously it is not specifying "iso_dev=".

If we can detect the partition from the boot parameters, then 'isoboot' can avoid the arbitary "Waiting 5 seconds", and wait for the detected partition directly, if necessary.

Here it is..

Code: Select all

# cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz pfix=fsck pmedia=cd find_iso=/BOOTISOS/eslacko64-6.9.9.11.iso

[gyrog]

Here it is..

Code: Select all

# cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz pfix=fsck pmedia=cd find_iso=/BOOTISOS/eslacko64-6.9.9.11.iso

Thanks.
But disappointing, nothing there to indicate the partition containing the "find_iso=" file.
I was hoping there might be a "root=" or some such thing.
It's frustrating because the searching has already been done, there is no value in making Puppy do the search again, and possibly getting a different answer.

[Clarity]

@01micko I did boot SuperGRUB2 (aka SG2D) EFI version via CD (found here) on my 2018 AIO AMD touch system. ALL of my ISOs are on my HDD in a folder "boot-isos".

Once at the SG2D Menu, I merely hit the Enter key and immediately hit the End key on the keyboard. Wait a minute and all of the ISOs are presented for selection.

I chose the upgraded Slacko v11 and it booted. I forgot to post the contents of the /proc...

I will follow this, later, with the boot screens, captured on camera; and the contents of that file once I reboot the system.

I have had success in booting the SG2D on both BIOS and EFI using the CD approach as well as the USB approach via hybrid ISO to USB.

Corrected: The ISOs need NOT be on the same device as the SG2D boot unit. The save-session folder/file will be saved to the root of the unit that Puppy ISO was booted from.

SG2D will search the attached devices attached to the PC for folder(s) of ISOs. The root folder name must be /boot-isos. SG2D will list all bootable ISOs it finds in the "boot-isos" folder for selection. My example is this:

2Mick.jpg (88.07 KiB) Viewed 2220 times

Hope this preliminary is helpful status info.

Edit: Rebooted Slacko. Contents of /proc/cmdline is
BOOT_IMAGE=/vmlinuz pfix=fsck pmedia=cd find_iso=/boot-isos/eslacko64-6.9.9.11.iso

Session is saved in a session-folder in the root of the drive containing the booted Slacko ISO file.

[gyrog]

And the save-session folder/file can be elsewhere attached to the system as well and Puppy will find it. ... same as if the PUP was booted native withoug SG2D's presence.

Are you sure?
Could you please do a "first boot"/"first shutdown" again using the updated eslacko iso, and report what options are provided by 'shutdownconfig' to change the location of the savefolder/savefile?
When I do a manual isoboot, (using an appropriate grub2 boot entry), 'shutdownconfig' does not give me any option to select the save partition.

Thanks for testing.

[Clarity]

@GyroG

Are you sure?

I MUST APOLOGIZE to @01micko for a misleading post. I was thinking that a session file could be moved to the root of another partition and the boot process would find and use the moved session. This DOES NOT WORK! And its the same for all 2020 PUPs.

The only way I have been told for a 2020 PUP to find a session file in the root or a folder on another partion is via the "psave=" boot parm on the kernel line at boot time. Here's an example from "/proc/cmdline" where I tested such:

Code: Select all

BOOT_IMAGE=/vmlinuz pfix=fsck pmedia=satahd find_iso=/boot-isos/eslacko64-6.9.9.11.iso psave=sda7:Sessions/

I have tested eSlacko by issuing "e" on the 8.11 boot line, and added the changes seen above. The pmedia command was tested using various changes from the original "cd"...none of the pmedia changes affected the boot or it finding the saved session in the "Session" folder on sda7 (an HDD which is different from the location of the booting ISO file)

Sorry for my misguide.

[gyrog]

The only way I have been told for a 2020 PUP to find a session file in the root or a folder on another partion is via the "psave=" boot parm on the kernel line at boot time. Here's an example from "/proc/cmdline" where I tested such:

Code: Select all

BOOT_IMAGE=/vmlinuz pfix=fsck pmedia=satahd find_iso=/boot-isos/eslacko64-6.9.9.11.iso psave=sda7:Sessions/

I have tested eSlacko by issuing "e" on the 8.11 boot line, and added the changes seen above. The pmedia command was tested using various changes from the original "cd"...none of the pmedia changes affected the boot or it finding the saved session in the "Session" folder on sda7 (an HDD which is different from the location of the booting ISO file)

When you use 'isoboot', 'pmedia=' is of little significance, it should probably reflect the save partition, e.g. 'pmedia=atahd'.

(Please consider the following as a mini-tutorial on one of the finer points of the 'psave=' boot parameter.)
If you are trying to specify that the savefolder should reside in a directory called 'Sessions' in the root of the 'sda7' partition, you should specify

Code: Select all

psave=sda7:/Sessions/

What your specification actually says to 'init' is that the savefolder resides on the 'sda7' partition in a 'Sessions' directory which is a sub-directory of the directory whose name is specified in the 'PSUBDIR' variable. The presence or absesnce of a leading '/' is significant. It probably works because 'PSUBDIR' is not specified.
The trailing '/' is also significant, without it the specification will be considered to be the path for the actual savefolder itself, not the path to the directory containing the savefolder.

[gyrog]

@Clarity,
The current default save location for 'isboot' is the root of the partition that contains the iso files.
What would be a better default path for the save location on that partition?
It could be a directory with a name derived fom the iso filename, although the name of the save-folder already contains the name of the Puppy.
It could be a sub-directory of the directory containing the iso files. e.g. ./isosaves/
Or both of the above, or something else.

[gyrog]

Test "SAVESPEC" the latest stuff in the 'init-experiment' branch of woof-ce.
See viewtopic.php?p=10002#p10002 for details.

[01micko]

New version 6.9.9.12 iso is out. Latest 5.4.77 kernel is in making a delta quite large so no delta.

See main post

Iso booting with SG2 can now make a save file/folder pretty much where ever you like if you first add a SAVESPEC file, see viewtopic.php?p=10002#p10002 for more details on how to do that.

I believe the SS_ID varaible in the SAVESPEC can be either the partition label or in the absence of that the UUID of the partition. Using /dev/sdXn or whatever is unreliable.

[TerryH]

First time using eslacko, downloaded eslacko-6.9.9.12 and used frugalpup to install to an SD card using a USB Card reader. This was also first time using frugalpup. The new install was in a directory on a reformatted SD card 2GB as fat 32. First boot no problems. Completed first run setup connecting wifi. I rebooted and created a save file. On reboot using grub2, everything went well.

On of the things I wanted to test was booting using the SD card reader on this Dell laptop, which all previous attempts have failed. The SD card I used was an old class 6 card, so had no expectations on how long it would take, just to check if it would boot. It took ages, but successfully completed booting. So, a great result. Great job by gyrog on the init and also frugalpup.

All working well. Thanks.

[gyrog]

New version 6.9.9.12 iso is out. Latest 5.4.77 kernel is in making a delta quite large so no delta.

Thamks.

I believe the SS_ID varaible in the SAVESPEC can be either the partition label or in the absence of that the UUID of the partition. Using /dev/sdXn or whatever is unreliable.

Just to clarify,
If the partition is on an internal disk, then partition name, e.g. "sda5" will probably work, but if it's on a usb device, it's unreliable since it could be "sdb5" or "sdc5", depending on the presence or otherwise of other usb storage devices.
So, please use a unique Volume Label, or UUID. You can get the UUID using the "blkid" console command.
Note: This is the same as for "pdrv=" and "psave=" boot parameters.

[gyrog]

@TerryH,
You are welcome.

[baldronicus]

Hi @gyrog and @01micko . Please accept my apologies if you would prefer that responses be made in the other thread. This is going to end up being another monster- apologies.

Copied eSlacko64-6.9.9.12 to a USB drive using f2StickPup and an Athlon64-X2 based machine. The only save location options made available at shutdown were the partitions in the USB drive. Hence I ended up sending the save to the "expected" second partition. Checked after a reboot and no "SAVESPEC" file had been generated. I suspect due to the save folder being in the "expected" location.
As an aside there was also no "Waiting" message, but I think this was as before.

Tried using a USB drive that had the Fatdog USB MBR image setup, as I could set up a third partition for the test. Saving to the third partition resulted in the generation of the "SAVESPEC" file, as expected.

Thought I would try the USB on another system, so deleted the save folder following a reboot using pfix=ram. However, I didn't delete the "SAVESPEC" file.
Booted the CSM mode A4-9125 and used the Xorgwizard this time. A "waiting" message did appear, again, as before.
Saving on shutdown, the location for the save file/folder was not given as an option. Only the other questions were asked, which is as expected, I think. Bailed out of the save. After a reboot the "SAVESPEC" file was deleted and another save at shutdown resulted in a similar result to above. Obviously/presumably there has to be a reboot after deletion of the "SAVESPEC" file for things to return to a "base" condition.
Rebooted again and saved on shutdown. Again only the partitions on the USB drive were available as options and, when checked after a reboot, a fresh "SAVESPEC" file had been generated. All as expected.

[Edit- Got a bit carried away.]

Thanks, and apologies for inflicting more suffering (I just can't seem to be short and succinct).

[gyrog]

Please see viewtopic.php?p=10180#p10180 for more SAVESPEC information.
Note that there are a couple of things still to do in this project.
Please give feedback as to which partitions should be offered by 'shutdownconfig' when no PSAVEPART is specified at boot time.