Add profile=xyz Bootcode?

[helasz]

I would find it useful to have a bootcode like "profile=xyz" which should export $profile variable in order to use it for example in bootlocal.sh for differentiating general settings (most importantly network settings [ip,netmask,gateway,proxy,etc.]). In bootlocal a 'case "$profile" in ... esac' structure could handle the different settings.

Reason: I am preparing a bootable TC ISO image in order to use it in more than one OS environment as the bootmedia of a (portable) virtual machine (virtualbox). All the settings are the same except the network environment. I would void storing more than once almost the same mydata.tgz which contain several files (not neccessarily small ones).

[Alternatively tc-config script could (try to) export all the variables found among bootcodes in the form VARIABLE_NAME=xyz which do not match any existing bootcode of that form.]

[bmarkus]

If you want to precess your own boot codes just read /proc/cmdline to get actual boot codes (as long as they are not conflicting with existing codes).

[Lee]

/etc/init.d/tc-functions defines a function called getbootpram which works nicely for this:

Code: [Select]

tc@apollo:~$ . /etc/init.d/tc-functions
tc@apollo:~$ getbootparam host
cruzr0
tc@apollo:~$
(my boot loader config includes the bootcode host=cruzr0)

Works just as well for my own home made boot codes, too.

[helasz]

Thanks for both replies. That works for me.

[curaga]

Technically init does do that, but the variables only exist until login. Login clears the environment.

I'm not sure if that behavior is given in any standard though, so you should be better off using /proc/cmdline (via the getbootparam function or otherwise).


Bootlocal and -sync happen before login, so the variables are seen there:


Test command line was "quiet newcode=56".
But as mentioned, not sure how portable it is to rely on that behavior.

edit: Of course it has other downsides, like ignoring single words, and multiple bootcodes (blacklist=a blacklist=b).