Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Thu 19 Oct 2017, 14:27
All times are UTC - 4
 Forum index » Advanced Topics » Cutting edge
"bootspecs" - an alternative to boot parameters
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 2 of 3 [37 Posts]   Goto page: Previous 1, 2, 3 Next
Author Message
gyro

Joined: 28 Oct 2008
Posts: 1401
Location: Brisbane, Australia

PostPosted: Mon 19 Sep 2016, 04:04    Post subject:  

@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
Back to top
View user's profile Send private message 
mavrothal


Joined: 24 Aug 2009
Posts: 2881

PostPosted: Mon 19 Sep 2016, 06:09    Post subject:  

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?

_________________
== Here is how to solve your Linux problems fast ==
Back to top
View user's profile Send private message 
jamesbond

Joined: 26 Feb 2007
Posts: 3055
Location: The Blue Marble

PostPosted: Mon 19 Sep 2016, 06:39    Post subject:  

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?

_________________
Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.
Back to top
View user's profile Send private message 
gyro

Joined: 28 Oct 2008
Posts: 1401
Location: Brisbane, Australia

PostPosted: Mon 19 Sep 2016, 07:06    Post subject:  

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
Back to top
View user's profile Send private message 
gyro

Joined: 28 Oct 2008
Posts: 1401
Location: Brisbane, Australia

PostPosted: Mon 19 Sep 2016, 07:29    Post subject:  

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:
[ "$PRAMONLY" != "yes" ] && [ -f /BOOT_SPECS ] && . /BOOT_SPECS
gyro
Back to top
View user's profile Send private message 
mavrothal


Joined: 24 Aug 2009
Posts: 2881

PostPosted: Mon 19 Sep 2016, 09:23    Post subject:  

gyro wrote:
So I'm thinking that in "init", the inclusion of "/BOOT_SPECS" could be
Code:
[ "$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" Shocked
Unless you really suggest that the problem is finding and documenting the 18th boot parameter Exclamation

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" Very Happy

_________________
== Here is how to solve your Linux problems fast ==
Back to top
View user's profile Send private message 
LazY Puppy


Joined: 21 Nov 2014
Posts: 2007
Location: Germany

PostPosted: Mon 19 Sep 2016, 09:36    Post subject:  

01micko wrote:
Why waste your time posting then? Rolling Eyes

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/viewtopic.php?p=924292#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) Laughing

No, but I gave my old drum kit away for free to a music store collecting instruments for refugees! Wink
Back to top
View user's profile Send private message 
LazY Puppy


Joined: 21 Nov 2014
Posts: 2007
Location: Germany

PostPosted: Mon 19 Sep 2016, 12:42    Post subject:  

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:
Quote:
[ "$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) Laughing

No, but I gave my old drum kit away for free to a music store collecting instruments for refugees! Wink
Back to top
View user's profile Send private message 
Sailor Enceladus

Joined: 22 Feb 2016
Posts: 1250

PostPosted: Mon 19 Sep 2016, 16:53    Post subject:  

@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. Laughing
Back to top
View user's profile Send private message 
LazY Puppy


Joined: 21 Nov 2014
Posts: 2007
Location: Germany

PostPosted: Mon 19 Sep 2016, 17:13    Post subject:  

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

No, but I gave my old drum kit away for free to a music store collecting instruments for refugees! Wink
Back to top
View user's profile Send private message 
LazY Puppy


Joined: 21 Nov 2014
Posts: 2007
Location: Germany

PostPosted: Mon 19 Sep 2016, 18:08    Post subject:  

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

No, but I gave my old drum kit away for free to a music store collecting instruments for refugees! Wink
Back to top
View user's profile Send private message 
Sailor Enceladus

Joined: 22 Feb 2016
Posts: 1250

PostPosted: Mon 19 Sep 2016, 18:55    Post subject:  

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

It looks like gyro read your mind LazY Puppy Wink
Back to top
View user's profile Send private message 
LazY Puppy


Joined: 21 Nov 2014
Posts: 2007
Location: Germany

PostPosted: Mon 19 Sep 2016, 19:49    Post subject:  

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 Wink

No, obviously he doesn't. Wink

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

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 or Very Mad

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

Anything else is NONSENSE !!! Exclamation

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

JUST DO NOT DO SUCH USELESS additions to the initrd.gz !!! Rolling Eyes

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

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 or Very Mad Evil or Very Mad Evil or Very Mad Evil or Very Mad Evil or Very Mad Evil or Very Mad Evil or Very Mad Evil or Very Mad Evil or Very Mad Evil or Very Mad Evil or Very Mad Evil or Very Mad Evil or Very Mad Evil or Very Mad Evil or Very Mad Evil or Very Mad Evil or Very Mad Evil or Very Mad Evil or Very Mad Evil or Very Mad Evil or Very Mad Evil or Very Mad Evil or Very Mad

_________________
RSH

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

No, but I gave my old drum kit away for free to a music store collecting instruments for refugees! Wink
Back to top
View user's profile Send private message 
Sailor Enceladus

Joined: 22 Feb 2016
Posts: 1250

PostPosted: Mon 19 Sep 2016, 22:36    Post subject:  

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
Back to top
View user's profile Send private message 
mavrothal


Joined: 24 Aug 2009
Posts: 2881

PostPosted: Tue 20 Sep 2016, 00:23    Post subject:  

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.

_________________
== Here is how to solve your Linux problems fast ==
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 2 of 3 [37 Posts]   Goto page: Previous 1, 2, 3 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Cutting edge
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1977s ][ Queries: 14 (0.0156s) ][ GZIP on ]