Puppy Linux Discussion Forum

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?

Clarity wrote: Sun Oct 25, 2020 4:59 pm Yes, I am willing. To do so

Clarity wrote: Sun Oct 25, 2020 4:59 pm 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

Clarity wrote: Sun Oct 25, 2020 4:59 pm 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?

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.

@GyroG wrote: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?

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.

• 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.

Clarity wrote: Tue Oct 27, 2020 12:34 am @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!

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

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.

gyrog wrote: Sat Oct 31, 2020 11:56 am
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 wrote: Sat Oct 31, 2020 11:43 pm 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.

gyrog wrote: Sun Nov 01, 2020 12:07 pm

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..

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

01micko wrote: Mon Nov 02, 2020 8:14 am

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.

@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:

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.

Clarity wrote: Wed Nov 11, 2020 6:20 am

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.

@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:

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.

Clarity wrote: Thu Nov 12, 2020 7:20 am

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

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.

@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.

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

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.

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.

01micko wrote: Sun Nov 15, 2020 1:07 am

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.

01micko wrote: Sun Nov 15, 2020 1:07 am

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.

@TerryH,
You are welcome.

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).

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.