"bootspecs" - an alternative to boot parameters

Under development: PCMCIA, wireless, etc.
Message
Author
User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#21 Post by mavrothal »

gyro wrote: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
It is better than nothing.
But let me provide a simple use case. The current init allows to have then SFSs and savefiles all over the place, so on the fly you can combine modified SFSs with one save-file/folder and vice versa no matter where they are. The immutable BOOT_SPECS does not allow that and requires to generate a new initrd every time.
Is like getting into trouble to provide all these options and then restrict their use for no obvious benefit.

I still can not see any argument as to what is detrimental (or just remotely unsettling) with the bailout option.
It would appear that your so far argument is "I do not see it as important or likely so i do not care" and your solution is "if you are <whatever> to mess up, find other ways to solve this" :shock:
Unless you really suggest that the problem is finding and documenting the 18th boot parameter :!:

Anyway, do as you see fit. You can always add a line of code and change another, if issues arise.

BTW your wheel comments reminded me of another ancient proverb
"Do not re-invent the flat tire" :D
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

User avatar
LazY Puppy
Posts: 1934
Joined: Fri 21 Nov 2014, 18:14
Location: Germany

#22 Post by LazY Puppy »

01micko wrote:Why waste your time posting then? :roll:
To make people at least able to discover this problem:
jamesboond 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).
http://www.murga-linux.com/puppy/viewto ... 292#924292

The boot specs used from a entry in menu.lst should be always the "top layer" of boot specs, since they can be entered on the boot prompt before booting the OS.

Or in other words: these boot specs from menu.lst or boot prompt should overwrite those boot specs in BOOTSPECS file - not reverse/vice versa.

E.g.:

This BOOT_SPECS is somehow similar how the configuration files are handled in my T.O.P.L.E.S.S. Puppies. It uses a new boot option, pconfig. If pconfig is not defined in the menu.lst or not entered at the boot prompt it searches for the default configuration file, which is (for tahr602): tahr_6.0.2.cfg

By entering the pconfig option to menu.lst or at boot prompt, I can define to use a different configuration file by entering just its prefix, like: pconfig=internet.

Then it searches for tahr_6.0.2-internet.cfg.

The menu.lst and/or the boot prompt NEEDS to be the TOP LAYER for boot options/specs.

That way you can have the your preferred boot specs nailed in initrd.gz. But if there's a need to change one or some of them, it's good to have option to change them BEFORE booting the OS, BEFORE initrd.gz is accessed.

Anything else doesn't really make sense!
RSH

"you only wanted to work your Puppies in German", "you are a separatist in that you want Germany to secede from Europe" (musher0) :lol:

No, but I gave my old drum kit away for free to a music store collecting instruments for refugees! :wink:

User avatar
LazY Puppy
Posts: 1934
Joined: Fri 21 Nov 2014, 18:14
Location: Germany

#23 Post by LazY Puppy »

I might give another example to the above issue.

At times when I was using Precise 5.6 and 5.7.1 I needed to add: nouveau.noaccel=1 to the boot specs in the related entry in menu.lst to get those Puppies work properly on machines that had nvidia graphics cards installed (FX 5200 & SFX 6200 (?)).

Using BOOT_SPECS with nailed nouveau.noaccel=1 would make similar combinations of (future) Puppies & nvidia graphics cards having graphics issues when using pfix=ram from boot prompt or menu.lst.

At least by solution presented by gyro:
[ "$PRAMONLY" != "yes" ] && [ -f /BOOT_SPECS ] && . /BOOT_SPECS
wich would need then to add nouveau.noaccel=1 also manually to the boot specs in menu.lst or at boot prompt.

If you let overwrite boot specs from menu.lst or boot prompt just the one that is defined in BOOT_SPECS file, there shouldn't be any graphics issues.

From several posts I know, nouveau.noaccel=1 for nvidia graphics cards is NOT the only solution available to solve such graphics problems. I'd read similar solutions also for radeon graphics cards.

So, what ever will be done/developed for the BOOT_SPECS file, let specs in that file being overwritten by specs from menu.lst and/or boot prompt.

Each one present in the BOOT_SPECS file by those ones in menu.lst and/or at boot prompt.
RSH

"you only wanted to work your Puppies in German", "you are a separatist in that you want Germany to secede from Europe" (musher0) :lol:

No, but I gave my old drum kit away for free to a music store collecting instruments for refugees! :wink:

Sailor Enceladus
Posts: 1543
Joined: Mon 22 Feb 2016, 19:43

#24 Post by Sailor Enceladus »

@LazY Puppy: I think it's designed to override specific boot specs, not to ignore your nouveau.noaccel=1 completely. I could be wrong though. Couldn't you just add nouveau.noaccel=1 into the bootspecs anyway if you wanted to? Seems like a non-issue.

Last night I was scrolling through the forum and I thought it said "boobsexs", might be a perfect match for your TOPLESS. :lol:

User avatar
LazY Puppy
Posts: 1934
Joined: Fri 21 Nov 2014, 18:14
Location: Germany

#25 Post by LazY Puppy »

The nouveau.noaccel=1 was just an example - not meant only for my specific use on the nvidia machines.

What I tried to say in a short form:

Overwriting submitted boot options/specs by a BOOT_SPECS file in initrd.gz will make boot loader's (like grub4dos) ability -to edit the boot parameters- completely useless. You can change what you want at the boot prompt, it just won't have any effect, if it is overwritten by a file in initrd.gz that is only editable by extracting and rebuilding the initrd.gz. That's just a stupid invention !!!

A better way -of course- would be to store that BOOT_SPECS file OUTSIDE of the initrd.gz (e.g. inside of a sub-directory of the boot directory (or like some call it: install directory) (that's where I store the T.O.P.L.E.S.S. config files). Though, you just don't need a GUI plus compiled C-Code binaries to edit such BOOT_SPECS files then. All you need is a text editor.

It's completely stupid to override specific boot specs submitted from menu.lst and/or submitted by boot prompt...

Edit:

What's the next great invention coming up here?

Compiling grub4dos to remove the ability to edit the boot parameters? Should make grub4dos binary probably a few kb smaller in its size... ...a mean part in Puppy as it seems :lol: :wink:
RSH

"you only wanted to work your Puppies in German", "you are a separatist in that you want Germany to secede from Europe" (musher0) :lol:

No, but I gave my old drum kit away for free to a music store collecting instruments for refugees! :wink:

User avatar
LazY Puppy
Posts: 1934
Joined: Fri 21 Nov 2014, 18:14
Location: Germany

#26 Post by LazY Puppy »

Addition to my previous post.

The more I think about this BOOT_SPECS the more I found reasons to let this look really like a stupid invention.

What if the user had setup pfix=ram inside the BOOT_SPECS file usually running on his home machine generally in pupmode 5 and where the main sfs will fit into RAM completely with some amount of free ram left for the use of programs- let's assume it is a remastered version, and it is much bigger in its size as the plain original version to have the favorite tools ready for a use instantly .

Let's assume also it is installed onto usb flash drive to have it portable for the use on different machines to help out friends having issues booting windows etc.pp..

And let's assume also one of these windows friends needs some help, though the Puppy just fits into RAM but won't left any useful amount of free RAM to run needed programs.

You just can't change to pfix=nocopy if pfix=ram is nailed in the BOOT_SPECS file and if pfix=ram is the one and only option to disable the BOOT_SPECS file and its containing settings.

How will you boot on such machine and use the tools to fix your friends windows with that puppy?

What would you prefer?

- to edit the BOOT_SPECS file in initrd.gz (should work with low, low, ram) and doing a reboot (editing the initrd.gz afterwards again for the default use at home)
- just to enter pfix=nocopy at the boot prompt

so, again: what would anyone prefer?
RSH

"you only wanted to work your Puppies in German", "you are a separatist in that you want Germany to secede from Europe" (musher0) :lol:

No, but I gave my old drum kit away for free to a music store collecting instruments for refugees! :wink:

Sailor Enceladus
Posts: 1543
Joined: Mon 22 Feb 2016, 19:43

#27 Post by Sailor Enceladus »


User avatar
LazY Puppy
Posts: 1934
Joined: Fri 21 Nov 2014, 18:14
Location: Germany

#28 Post by LazY Puppy »

Sailor Enceladus wrote:I found this:
https://github.com/puppylinux-woof-CE/woof-CE/commit/f1be3f53c640ef44c04f516f5a81f6ea96f6e283

It looks like gyro read your mind LazY Puppy ;)
No, obviously he doesn't. :wink:

The patch shows code that will disable the use of BOOT_SPECS ONLY if pfix=ram is submitted. :roll:

If a user/menu.lst/boot prompt submits e.g. pfix=nocopy and there is pfix=ram defined in BOOT_SPECS, the puppy continues to boot straight loading its main sfs into ram. And there is NO reason, why a Puppy user should NOT choose to boot his puppies by default using pfix=ram defined in BOOT_SPECS.

This is stupid. :idea:

This is DISABLING the ability of all boot loaders (like grub4dos) to edit the boot parameters. Stupid, stupid, stupid! :idea: :idea: :idea:

You can give a warning/information to NOT to use pfix=ram in BOOT_SPECS, but that's not less stupid.

This is just NOT well thought out to an useful end... :evil:

If there is any pfix= submitted by menu.lst or boot prompt, it should disable the use of pfix= defined in the BOOT_SPECS file. And so it needs to be done for each and every possible boot parameter to submit. :!:

Anything else is NONSENSE !!! :!:

This is like a car, where you can display, to turn left or to turn right, but it always turns to the right, unless you don't display where to turn (which would be pfix=ram then). :lol: :lol: :wink:

JUST DO NOT DO SUCH USELESS additions to the initrd.gz !!! :roll:

Go, get yourself a beer or a coffee or what else and start fixing something useful like the issues to install and use brother printers in puppy.

BUT DO NOT override any boot option/parameter/specs, that is submitted by menu.lst and/or boot prompt. :D

Edit:

Anyone else here in this topic being truly able to SEE THE WOOD FOR THE TREES?

Or just can't them see the wood for the trees at all?

Edit 2:

The boot prompt is the earliest and first possibility to "modify" how the OS will boot/run/execute. It's completely NONSENSE to disable this early possibility (to "modify" the OS) by "hard" coded specs being nailed in BOOT_SPECS in initrd.gz. This is

STUPID, NONSENSE, STUPID, NONSENSE, STUPID, NONSENSE
:evil: :evil: :evil: :evil: :evil: :evil: :evil: :evil: :evil: :evil: :evil: :evil: :evil: :evil: :evil: :evil: :evil: :evil: :evil: :evil: :evil: :evil: :evil:
RSH

"you only wanted to work your Puppies in German", "you are a separatist in that you want Germany to secede from Europe" (musher0) :lol:

No, but I gave my old drum kit away for free to a music store collecting instruments for refugees! :wink:

Sailor Enceladus
Posts: 1543
Joined: Mon 22 Feb 2016, 19:43

#29 Post by Sailor Enceladus »

LazY Puppy wrote:Anyone else here in this topic being truly able to SEE THE WOOD FOR THE TREES?

Or just can't them see the wood for the trees at all?
The Beautiful People? https://youtu.be/onzH6fcp4sc?t=66

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#30 Post by mavrothal »

Is hard for me to follow long, highly emotional post and pick up valuable bits, but trying it I thought that might be a good idea bootspecs to reed /proc/cmdline and get this as initial input to be edited by the user (plus the content of any previous BOOT_SPECS file of course) or at least consider it and warn for any conflicts arising.

In the process I realised that although bootspecs in essence does set kernel command line parameters, they are not parsed there (nor I could find a way to amend them there) so there is no easy way for other apps to know how do we boot. But I can not think of any program reading cmdline. Does any of the grub and friends reads/needs that file?

BTW LazY Puppy, is better to take a look or try a program before you critique it. BOOT_SPECS does not inactivate the command line, it just takes precedence if the same command is both at the command line and BOOT_SPECS. This makes sense since the user decide to go that way having established both the command line and BOOT_SPECS him/herself.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#31 Post by rufwoof »

Don't know if this may be of any help/interest, but man live-boot (debian) ... snippet as attached, indicates that they support a boot parameter file.

Might provide a indicator of a common format/filename (location) to perhaps use.
Attachments
s.jpg
(79.07 KiB) Downloaded 407 times

User avatar
LazY Puppy
Posts: 1934
Joined: Fri 21 Nov 2014, 18:14
Location: Germany

#32 Post by LazY Puppy »

it just takes precedence if the same command is both at the command line and BOOT_SPECS. This makes sense since the user decide to go that way having established both the command line and BOOT_SPECS him/herself.
Taking precedence over the command line or boot prompt (as I named it) is what I meant by disabling/deactivating the command line/boot prompt.

And that's just NONSENSE!!!

Taking precedence over the command line/boot prompt is NONSENSE!

Even if the user decides to have established both the command line and BOOT_SPECS - it is NONSENSE.

If you can change boot specs only by editing the initrd.gz (better saying the BOOT_SPECS file) is completely NONSENSE!

Settings submitted by the boot prompt/command line needs to take precedence over the settings in BOOT_SPECS file. The boot prompt/command line is the first possible step, where one can modify the boot specs. Sorry, but anything else is not thought out to an useful end - so, it's just NONSENSE.

Mark my words!

You all should take a break and think over one more time...

Edit:

Btw.: I had already downloaded and looked into the bootspecs sfs. Though, not much to see there since most progs are binaries. Source code NOT included.
RSH

"you only wanted to work your Puppies in German", "you are a separatist in that you want Germany to secede from Europe" (musher0) :lol:

No, but I gave my old drum kit away for free to a music store collecting instruments for refugees! :wink:

Sailor Enceladus
Posts: 1543
Joined: Mon 22 Feb 2016, 19:43

#33 Post by Sailor Enceladus »

@LazY Puppy: What do you think of this part below? I tend to agree with mavrothal here (bold added by me):
mavrothal wrote:BOOT_SPECS does not inactivate the command line, it just takes precedence if the same command is both at the command line and BOOT_SPECS. This makes sense since the user decide to go that way having established both the command line and BOOT_SPECS him/herself.

User avatar
LazY Puppy
Posts: 1934
Joined: Fri 21 Nov 2014, 18:14
Location: Germany

#34 Post by LazY Puppy »

No, this doesn't make sense.

Options in BOOT_SPECS that takes precedence over the options submitted by menu.lst or command line/boot prompt will make the command line/boot prompt useless for those options that are setup in file BOOT_SPECS.

Which is quite similar to disable the command line/boot prompt.

Once the user had chosen to use the BOOT_SPECS file he is not able anymore to submit anything else from command line/boot prompt than pfix=ram (if the wanted option is setup already in file BOOT_SPECS).

As BOOT_SPECS is currently developed only pfix=ram will disable the use of file BOOT_SPECS.

Though there are many more options to be setup in BOOT_SPECS and/or submitted by command line/boot prompt.

This is nonsense.

Parameters/options setup in file boot specs should take place ONLY if there is no equal option submitted by menu.lst and/or command line/boot prompt.

If pfix is submitted by command line/boot prompt the pfix in BOOT_SPECS should NOT be used. And so it needs to be handled for all boot options to be submitted.
some boot specs to be submitted by command line/boot prompt (incomplete) wrote:pkeys)
pmedia)
psavemark)
pdev1)
zdrv)
adrv)
ydrv)
underdog)
plang)
psubdir)
pfix)
All these options are usable from command line/boot prompt ONLY if either NOT setup in BOOT_SPECS and/or combined with pfix=ram (which disables the use of BOOT_SPECS).
RSH

"you only wanted to work your Puppies in German", "you are a separatist in that you want Germany to secede from Europe" (musher0) :lol:

No, but I gave my old drum kit away for free to a music store collecting instruments for refugees! :wink:

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#35 Post by gyro »

If BOOT_SPECS were included before boot parameter processing, it coud not be disabled using a boot parameter.

The current level of commitment to this utility does not make it worth more that a 1 line patch to init.
In a production version, it would be nice to have a "pfix=" option to disable it.

Given the frequency of my recent use of "bootspecs", I would have no hesitation in using it for temporary situations, e.g "fdrv=:/root/downloads/linux_firmware_20160922.sfs" and reboot to checkout missing firmware.

Given the possibility of checking the validity of parameters, it could become a safer way of specifying boot parameters. Particularly if the "Edit as boot configuration file" was changed to be a read-only viewer.

Puppy has a history of having a few configuration files in the frugal install directory, each with a single purpose. Each one of these facilities can also be specified with a boot parameter. It would simplify "init" if there were only one config file, which could handle these, and other stuff, and be simply included like DISTRO_SPECS. The facility code then only has to process the contents of a variable, not a parameter file as well.
Such a file could reside in a number of places, but in "initrd.gz" is the one that is simplest for "init" even if more complicated for the running system.

What I do with Puppy is my "fun-time".
In my "fun-time" I do those things I am interested in.
In my "paid-time" I do things others want me to do, oops my Puppy "paid-time" is zero.

gyro

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

New version

#36 Post by gyro »

For latest version see first post.
gyro

User avatar
LazY Puppy
Posts: 1934
Joined: Fri 21 Nov 2014, 18:14
Location: Germany

#37 Post by LazY Puppy »

Hi gyro.

I'm absolutely NOT interested in breaking the your fun-time.

I'm just interested to save you making faults like I did in my T.O.P.L.E.S.S. systems.

These systems can boot directly into e.g. DE interface, which means having LANG=de, TIMEZONE=Berlin (de) and KEYBOARD=de, just by the use of the T.O.P.L.E.S.S. configuration files.

Though, I made a BIG mistake (in 1.0.0 and 1.0.1 and 1.0.2 of T.O.P.L.E.S.S.)!

In these versions it is useless to enter e.g. plang, pkeys and ptimezone (which I invented before T.O.P.L.E.S.S.) at the command line or to submit these parameters by entry in menu.lst as all those submitted parameters are overwritten by the T.O.P.L.E.S.S. configuration files.

Fortunately I'm including a configuration file AFTER the boot parameter being processed.

Though, it took me at least two days afterwards to change all my work, so I can boot a configuration file made for my DE settings but being now still (again) able to change plang, pkeys and ptimezone by the command line for testings.

Puppy has users, puppy has developers, but that's just NOT all.

Puppy has also developing users (like me one is).

Though, I'm absolutely NOT interested in breaking the your fun-time. I just find/found it stupid, as I made such STUPID FAULT first!
RSH

"you only wanted to work your Puppies in German", "you are a separatist in that you want Germany to secede from Europe" (musher0) :lol:

No, but I gave my old drum kit away for free to a music store collecting instruments for refugees! :wink:

Post Reply