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 Fri 26 May 2017, 11:07
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 3 of 3 [37 Posts]   Goto page: Previous 1, 2, 3
Author Message
rufwoof


Joined: 24 Feb 2014
Posts: 1862
Location: UK

PostPosted: Tue 20 Sep 2016, 05:53    Post subject:  

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.
s.jpg
 Description   
 Filesize   79.07 KB
 Viewed   350 Time(s)

s.jpg

Back to top
View user's profile Send private message 
LazY Puppy


Joined: 21 Nov 2014
Posts: 1923
Location: Germany

PostPosted: Tue 20 Sep 2016, 07:09    Post subject:  

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

In Deutschland bekommt jeder Depp Asyl, sogar BW-Soldaten, weil in den Behörden die absolut größten Deppen sitzen. Mathelehrer Hungerland: wer ungeeignet scheint, für das Fach-Abi, der bewerbe sich schnell bei einer Behörde!
Back to top
View user's profile Send private message 
Sailor Enceladus

Joined: 22 Feb 2016
Posts: 1080

PostPosted: Tue 20 Sep 2016, 19:32    Post subject:  

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


Joined: 21 Nov 2014
Posts: 1923
Location: Germany

PostPosted: Tue 20 Sep 2016, 20:31    Post subject:  

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

In Deutschland bekommt jeder Depp Asyl, sogar BW-Soldaten, weil in den Behörden die absolut größten Deppen sitzen. Mathelehrer Hungerland: wer ungeeignet scheint, für das Fach-Abi, der bewerbe sich schnell bei einer Behörde!
Back to top
View user's profile Send private message 
gyro

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

PostPosted: Thu 22 Sep 2016, 01:09    Post subject:  

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

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

PostPosted: Thu 22 Sep 2016, 01:10    Post subject: New version  

For latest version see first post.
gyro
Back to top
View user's profile Send private message 
LazY Puppy


Joined: 21 Nov 2014
Posts: 1923
Location: Germany

PostPosted: Thu 22 Sep 2016, 14:27    Post subject:  

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

In Deutschland bekommt jeder Depp Asyl, sogar BW-Soldaten, weil in den Behörden die absolut größten Deppen sitzen. Mathelehrer Hungerland: wer ungeeignet scheint, für das Fach-Abi, der bewerbe sich schnell bei einer Behörde!
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 3 of 3 [37 Posts]   Goto page: Previous 1, 2, 3
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.1421s ][ Queries: 14 (0.0236s) ][ GZIP on ]