"bootspecs" - an alternative to boot parameters

Message

gyro · #1 Post by **gyro** » Sat 17 Sep 2016, 12:58

Bootspecs is a utility to provide user access to the BOOT_SPECS file in "initrd.gz".
The BOOT_SPECS file is a new facility provided by the new "init" script in new puppies based on the woof-ce 'rationalise' branch.
It can contain variable definitions to overide the ones usually set by boot parameters.

Edit, 22 Sep 2016:

"bootspecs-0.4.sfs" is attached.
This is meant to be the final version in this concept development phase.
It's useable enough to indicate if such a utility is worth pursuing.

The "Create as boot parameter line" processing has been enhanced:
It now includes some validation of parameters, this validation could be extended. Only valid parameters are passed on.
It now generates a "do nothing" file if the "OK" button is clicked with an empty text line.
The "OK" button process now displays a "Done." message when it is finished.

The "Store Boot configuration file in initrd.gz" "OK" button process now displays a "Done." message when it finishes.

The online help file, (click the "Help" button), has been significantly updated.

The sfs now contains a "bootspecs.desktop" file so "Bootspecs" appears in the "System" menu.

Old post follows.
==============================================================================
To specify the boot parameter "pfix=nocopy", you could do the following:
1. In a terminal enter "bootspecs".
2. In the menu screen that opens, click on "Create as boot parameter line".
3. In the dialog that opens, enter the text "pfix=nocopy" (without the quotes). Then click the "OK" button.
4. In the menu screen, click on "Edit as boot configuration file" to browse/edit the file created by the previous step. Close the editor.
5. In the menu screen, click on "Store Boot configuration file in initrd.gz".
6. In the "Select file dialog" that opens, navigate to, and select, the "initrd.gz" file that is to be modified. Click on the "OK" button and the new BOOT_SPECS file will be written into the selected "initrd.gz".
7. "Quit" the utility.
On reboot, the puppy sfs's will not be copied into memory, just as if you had added a "pfix=nocopy" parameter to you boot entry.

Clicking on the "Help" button will open a help page in the defaulthtmlviewer. This contains information about the "boot parameters" and "init variables" supported by this utility.

This is pre-alpha, "proof of concept" code. It could be replaced with a much more sophisticated utility, e.g. one that presents the "pfix=" options as a series of check boxes.
It is an attempt to show a possible way to make puppies "boot parameters" more accessible.

I have attached an sfs file. Load it as an extra sfs or as an adrv.

For anyone interested in the code:
This does not use gtkdialog, since I can't get gtkdialog to work with gtkbuilder and glade.
The interface is provided by custom C code using glade gtkbuilder xml gui definitions. Each C program drives a single screen based on command line parameters and returns the resultant data on standard output. A bit like my own "zenity" except that the look of the screen can be controlled by glade.
The sfs contains both 32bit and 64bit versions of the C programs. The "bootspecs" script should automatically use the appropriate ones.

Note: The package also conatins a script called "file2initrd" which could be generally used to update "intrd.gz". Just run "file2initrd" without any parameters to see usage.

Edit:
Now have "bootspecs-0.2.sfs".
This release produces error messages if it does not recognise a boot parameter.
If you get it wrong, just click on "Create as boot parameter line" again, and have another go.

Edit 2:
Now have "bootspecs-0.3.sfs"
On first run, this version sets the default "initrd.gz" to be that of the current puppy, if it finds it in the normal place.

gyro

LazY Puppy · #2 Post by **LazY Puppy** » Sat 17 Sep 2016, 23:42

Ok.

I did not have a look into the new woof ce nor did I have a look into the bootspecs program.

Though, I think you are kidding the Puppy users.

A GUI to modify a file in intrd.gz to set e.g. pfix=nocopy and then to rebuild the initrd.gz.

Oh well.

You must be kidding!

Sorry, but I can't stop laughing!!!

A GUi to modify a file in initrd.gz to have a (or even some more) boot option, that is easily modified directly in the text based menu.lst

What drugs are you on?

Ich lache mir 'nen Ast!!!

with the bootspecs program wrote:To specify the boot parameter "pfix=nocopy", you could do the following:
1. In a terminal enter "bootspecs".
2. In the menu screen that opens, click on "Create as boot parameter line".
3. In the dialog that opens, enter the text "pfix=nocopy" (without the quotes). Then click the "OK" button.
4. In the menu screen, click on "Edit as boot configuration file" to browse/edit the file created by the previous step. Close the editor.
5. In the menu screen, click on "Store Boot configuration file in initrd.gz".
6. In the "Select file dialog" that opens, navigate to, and select, the "initrd.gz" file that is to be modified. Click on the "OK" button and the new BOOT_SPECS file will be written into the selected "initrd.gz".
7. "Quit" the utility.
On reboot, the puppy sfs's will not be copied into memory, just as if you had added a "pfix=nocopy" parameter to you boot entry.

without the bootspecs program wrote:To specify the boot parameter "pfix=nocopy", you could do the following:
1. Open file menu.lst in text editor
2. Change the appropriate entry in menu.lst
3. store menu.lst

01micko · #3 Post by **01micko** » Sun 18 Sep 2016, 04:29

LazY Puppy wrote:Ok.

I did not have a look into the new woof ce nor did I have a look into the bootspecs program.

Why waste your time posting then?

I will take a look in due course.

Sailor Enceladus · #4 Post by **Sailor Enceladus** » Sun 18 Sep 2016, 05:09

@LazY Puppy: I think the idea was inspired by this thread?
http://www.murga-linux.com/puppy/viewtopic.php?p=923227#923227
http://www.murga-linux.com/puppy/viewtopic.php?p=923278#923278

edit: Or maybe not. If it addresses sunburnt's problem maybe we should post a link to this thread there too?

jlst · #5 Post by **jlst** » Sun 18 Sep 2016, 05:24

LazY Puppy · #6 Post by **LazY Puppy** » Sun 18 Sep 2016, 11:09

jlst wrote:You have nothing of value to add to this thread... your TOPLESS app is shit..

Yes, it's that big one shit.

It has made me up to stop doing remasters to store very many settings that are usual stored in save files and/or at remasters. I love that shit, as it lets me use puppies from unicorn, vivid, tahr etc.pp. modified to my needs including to boot directly into German language, setup preferred wallpapers (one for each desktop, 10 desktops with different icons on it) and themes for icons, gtk, jwm, sounds, preloaded .sfs files (at boot up) up to 120 out of the box (including to load them to a top layer or just to a default layer) with menu pipes to external files at boot partition and/or two more partitions (that I'm calling parallel partitions).

Hassle of save files, hassle of remastering - BEGONE!

And do you know what?

I'm controlling this by boot options in menu.lst, so if there are 10 or even 50 or even 100 different config files, I can boot 10 or even 50 or even 100 different setup puppies based on just a single installation without to use a save file or doing remasters (which usually breaks some stuff).

What a shit!

Love it!

augras wrote:Hi, EUREKA ! it works !
So i can see all your menus and icons and make a better translation.
You have made a real great work and i think it's the better way for a puppy.

jlst · #7 Post by **jlst** » Sun 18 Sep 2016, 11:18

I can't believe mods allow trolling in the cutting edge area!!

gyro · #8 Post by **gyro** » Sun 18 Sep 2016, 11:20

@LazY Puppy,
I'm glad you got a laugh, Puppy is supposed to be fun.

Obviously, this utility is not designed for you.

Strangely, I find it a little more convenient than editing my menu.lst directly.

But more than that, the file that gets added to initrd.gz, actually contains init variables, so it has the capability to preset any variable in init, not just the ones set by boot parameters.
The utility provides ready access to that file. The boot parameters interface in the utility, is just that, an interface using the more documented parameters.
Although not implemented yet, the utility provides an opportunity to do some validity checking of the parameters.

So, I don't think I've gone completely tropo.

gyro

LazY Puppy · #9 Post by **LazY Puppy** » Sun 18 Sep 2016, 11:25

jlst wrote:I can't believe mods allow trolling in the cutting edge area!!

So, why did you remove the content of your post I'd replied to?

Removing posts content or changing it after a reply has done to such posting is the real troll behaviour.

So, you're the troll here?

augras wrote:Hi, EUREKA ! it works !
So i can see all your menus and icons and make a better translation.
You have made a real great work and i think it's the better way for a puppy.

stemsee · #10 Post by **stemsee** » Sun 18 Sep 2016, 12:48

Any useful new addition is welcome, imo.

It looks useful and 'easy' to use, to me! I don't know if it will work with JL64 700 initrd.xz, or FatDog initrd, but I will give it a go. I can see the 'quick' benefit and other potentials this might offer!

It's not as comprehensive as topless, and it's not as big either!

I will test it out too!

stemsee

mavrothal · #11 Post by **mavrothal** » Sun 18 Sep 2016, 14:25

Quick test.

Code: Select all

# bootspecs 
File '/root/.config/bootspecs/BOOT_SPECS' not found
# ls /root/.config/bootspecs/
bootspecs_as_params.txt  bootspecs.conf

Indeed initrd.gz is unchanged.
Does it require an initrd with a BOOT_SPECS file already in it?

gyro · #12 Post by **gyro** » Sun 18 Sep 2016, 15:05

mavrothal wrote:Indeed initrd.gz is unchanged.
Does it require an initrd with a BOOT_SPECS file already in it?

No, initrd.gz was unchanged because it found no file to copy into it.
There should have been a /root/.config/bootspecs/BOOT_SPECS file created, which is the file that gets copied into the initrd.gz.
The question is why did /root/.config/bootspecs/bootspecs_as_params.txt get created, but not /root/.config/bootspecs/BOOT_SPECS?

Edit later:
The script parses the entered line for puppy boot parameters.
If the line does not contain any valid puppy boot parameters, then no
/root/.config/bootspecs/BOOT_SPECS is produced.

Hmm.., some room for improvement.

gyro

mavrothal · #13 Post by **mavrothal** » Sun 18 Sep 2016, 17:29

gyro wrote: Hmm.., some room for improvement.

Given that this utility can render a system unusable I think it might be better to only provide menu driven options, verify that the DISTRO_SPECS in the system and target initrd are the same as well as the location of the initrd (maybe from from the BOOTCONFIG).
Finally you might want to include an init parameter to ignore bootspecs for the times when user ingenuity breaks best intentions.

gyro · #14 Post by **gyro** » Mon 19 Sep 2016, 01:04

mavrothal wrote:I think it might be better to only provide menu driven options

I agree, but the chance of me doing that much gui programming in Puppy are highly unlikely.

mavrothal wrote:verify that the DISTRO_SPECS in the system and target initrd are the same as well as the location of the initrd (maybe from from the BOOTCONFIG).

The whole idea of having a "Select file dialog" for "initrd.gz" is so that the "initrd.gz" file that needs to be modified can be modified from any running Puppy.
Though it might be an idea to preset the default to the current "initrd.gz", if it's in the usual place.

mavrothal wrote:Finally you might want to include an init parameter to ignore bootspecs for the times when user ingenuity breaks best intentions.

If a modified "initrd.gz" is mucking up a puppy, then replace it with the "initrd.gz" from the iso.
If we want to save puppy users from themselves, then we shouldn't be running them as "root".

gyro

mavrothal · #15 Post by **mavrothal** » Mon 19 Sep 2016, 04:52

gyro wrote:
mavrothal wrote:Finally you might want to include an init parameter to ignore bootspecs for the times when user ingenuity breaks best intentions.
If a modified "initrd.gz" is mucking up a puppy, then replace it with the "initrd.gz" from the iso.
If we want to save puppy users from themselves, then we shouldn't be running them as "root".

I do not know about you but I have made my fair share of typing mistakes or just oversights.
When suddenly your system says puppysfs is not found because you mistyped sda21 instead of sda12, you do not even know what is going on before you start looking for the original initrd from the original iso.
Similarly because you modified superpup-123 in the removable sdc1 instead of sda1
or just because you want to test something and want to change variables for that one run etc.
Regarding root you may want to consider that the most common puppy diagnostic advise is "boot with pfix=ram" and any root effects are gone (assuming not a full install)

So having

Code: Select all

if [ -f /bootspecs -a "$PBIGNORE" = "" ]; then . /bootspecs; fi

might not be such a big trouble.

gyro · #16 Post by **gyro** » Mon 19 Sep 2016, 08:04

@mavrothal,
Why would anyone reboot setting your $PBIGNORE unless someone suspects the contents of the "/BOOT_SPECS" file in the current "initrd.gz"?
And a simple solution to a suspect "/BOOT_SPECS" file in the current "initrd.gz", is to replace the current "initrd.gz" with a known good copy of "initrd.gz".

gyro

mavrothal · #17 Post by **mavrothal** » Mon 19 Sep 2016, 10:09

gyro wrote:@mavrothal,
Why would anyone reboot setting your $PBIGNORE unless someone suspects the contents of the "/BOOT_SPECS" file in the current "initrd.gz"?

Obviously to verify the suspicion and actually given the opportunity to correct it through the bootspecs script without being forced to boot another OS find the original initrd and replace the problematic one.
But why such a strong opposition to the inactivation option? What problem do you envision it might generate?

jamesbond · #18 Post by **jamesbond** » Mon 19 Sep 2016, 10:39

I'm just a passer-by but I've been watching this thread with interest. I came to the same conclusion as mavrothal and was about to suggest the same thing - a pfix=ignore_boot_specs, but mavrothal beat me to it.

Allow me to add one more reason why this is a good idea and why your reply below is not sufficient:

gyro wrote:And a simple solution to a suspect "/BOOT_SPECS" file in the current "initrd.gz", is to replace the current "initrd.gz" with a known good copy of "initrd.gz".

Because, if this happens to the only machine that boots, and there are no known good copy of Puppy elsewhere (on USB, on disc, etc), you can't even boot the system to "replace initrd with a known good one".

In the past, "pfix=ram" will guarantee that you can always boot the system no matter what (if the Puppy previously boots on that machine). A boot-spec that is baked into initrd and cannot be bypassed effectively makes it impossible to recover from silly mistakes when those mistakes get to the boot-specs.

Perhaps what can be done is to ensure that when pfix=ram is given, then any boot-spec is ignored?

gyro · #19 Post by **gyro** » Mon 19 Sep 2016, 11:06

mavrothal wrote:Obviously to verify the suspicion and actually given the opportunity to correct it through the bootspecs script without being forced to boot another OS find the original initrd and replace the problematic one.
But why such a strong opposition to the inactivation option? What problem do you envision it might generate?

Why invent a new wheel if I already have a wheel that is adaquate to do the job.
How do you set this variable?
It can't be done via the /BOOT_SPECS file, so we have to invent a new boot parmateter, which has to be specified as a boot parameter, and documented as a boot parameter etc....

gyro

gyro · #20 Post by **gyro** » Mon 19 Sep 2016, 11:29

jamesbond wrote:Because, if this happens to the only machine that boots, and there are no known good copy of Puppy elsewhere (on USB, on disc, etc), you can't even boot the system to "replace initrd with a known good one".

I do not see this as a likely scenario. Everyone starts using puppy with a stock standard iso. So we're talking about someone who is carless enough to lose their original boot media, and foolish enough to put their single bootable puppy at risk.

jamesbond wrote:In the past, "pfix=ram" will guarantee that you can always boot the system no matter what (if the Puppy previously boots on that machine). A boot-spec that is baked into initrd and cannot be bypassed effectively makes it impossible to recover from silly mistakes when those mistakes get to the boot-specs.

Perhaps what can be done is to ensure that when pfix=ram is given, then any boot-spec is ignored?

This pfix=ram thing makes some sense, losing that gaurantee is not good.
So I'm thinking that in "init", the inclusion of "/BOOT_SPECS" could be

Code: Select all

[ "$PRAMONLY" != "yes" ] && [ -f /BOOT_SPECS ] && . /BOOT_SPECS

gyro

(old)Puppy Linux Discussion Forum

(old)Puppy Linux Discussion Forum

"bootspecs" - an alternative to boot parameters

"bootspecs" - an alternative to boot parameters