On Sun, 12 Aug 2012 12:49:20 +0200, Ole Christensen wrote:
> on 2012-08-11 20:14, Bit Twister wrote:
> > On Sat, 11 Aug 2012 17:00:49 +0200, Ole Christensen wrote:
> >
> >> when distro2 get a new kernel-image distro2 should
> >> update grub.cfg on sda1 and place itself on say 2de
> >> place if a variable in /etc/default/grub tell so,...
> As i see it there should be no chicken / egg 1st problem,
> but i could have overlook something,...(?)
I like to code for the worst case, disk died, it is a clean install
which does not have the variable in /etc/default/grub let alone know
if the install is to be the Production distro.
Production is defined as the distribution in control of the boot
loader installed into the MBR.
> Of cause a variable have to tell if we are master or guest OS
> and who "own" mbr,...
Master/guest are nice terms except if you have installed VirtualBox.
There, Master would be same as Guest, but you have VirtualBox guests
along with your other distros installed on the Production/Master.
> > 40_my_changes would then have to hunt down the
> > "Production/Master" /etc/default/grub file to get/set the variable.
>
> Oh,... I almost forgot Your recommended 40_my_changes,...
> but don't You think the race are over when we turn 40,...?
>
> 00_header # run by master
> 05_debian_theme # run by master
> 10_linux # run by master, modify for guest OS
> 20_linux_xen # i don't need
> 20_memtest86+ # i don't need
> 30_os-prober # should not run or modify for master, (WinOS etc)
> 40_custom # do nothing
40_my_changes was chosen so it would run after 40_custom and be
somewhat descriptive. Having checked a mint install which has a
40_custom and 41_custom I can recommend using 50_my_changes as the script name.
> Then,... on master, at update, before / in grub-update save
> a copy of old grub.cfg and as last copy the contents from
> the guest OS into the new grub.cfg,...(?)
Now you are starting to see some of the chicken/egg problems. :)
My recommendation is that you always try to code in such a way as to
avoid any manual steps where possible.
In my scripts, I use two names, fn_vorig and fn_vinstall.
_vorig is the vendor installed file.
_install is the copy of fn before I make my modifications.
In my setup, I run my new_install script, install_addons, install_toys
and install_changes. Those scripts run (whatever)_changes. Each of
those scripts check for somefn_vorig and if it does not exist, copies fn to
fn_vorig.
It then copies fn to fn_install and modifies it into fn.
In this case, new_install would call grub_cfg_changes which would have
something like
_fn=/boot/grub/grub.cnf
if [ ! -e "${_fn}_vorig" ] ; then
cp $_fn ${_fn}_vorig
fi
ln -s /local/bin/50_my_changes /etc/grub.d/
> > Just keep it simple and put the "Production" information in
> > 40_my_changes so it can know what needs to be done from the start.
>
> Sound simple enough to me,...(?)
> It's not clear to me what You mean with "Production" information,...?
> do You mean something like the output from 'lsb_release -d',...?
No, that changes on a new release and as in your case, you have other
copies of the same distribution.
First thing you have to decide is what your variable will contain as
the identifier of the Production installation. I label my partitions
so I could use _prod_distro=mga2
to identify the Production distribution.
Instead of using lsb_release, script would have something like
set -- $(df -h /)
_current_partition=$8
It then becomes a simple matter to loop through blkid output
/sbin/blkid
/dev/sda1: LABEL="SYSTEM" UUID="E858B4EB58B4BA20" TYPE="ntfs"
/dev/sda2: LABEL="OS" UUID="4614B60114B5F451" TYPE="ntfs"
/dev/sda4: LABEL="HP_RECOVERY" UUID="2A449E8C449E5A81" TYPE="ntfs"
/dev/sda5: LABEL="dos_d" UUID="07378A593F364047" TYPE="ntfs"
/dev/sda6: LABEL="cauldron" UUID="35f73957-91a80267dda6" TYPE="ext4"
/dev/sda7: LABEL="alpha2" UUID="a1db361e-a05a-4b2c20a416" TYPE="ext4"
/dev/sdb1: LABEL="swap" UUID="f4d61d52-4313-4b1b-adeb-597fb37ece22" TYPE="swap"
/dev/sdb2: LABEL="hotbu" UUID="4beb8f73fc3fb6e" TYPE="ext4"
/dev/sdb3: LABEL="mga1" UUID="ba828" TYPE="ext4"
/dev/sdb5: LABEL="accounts" UUID="ccf256ea-c-bd797f44ca9c" TYPE="ext4"
/dev/sdb6: LABEL="local" UUID="a25dac22-b-bf84c6b23c3d" TYPE="ext4"
/dev/sdb7: LABEL="mga2" UUID="5dddc24b-2e28d198f" TYPE="ext4"
/dev/sdb8: LABEL="2010_2_64" UUID="012bb3468bc" TYPE="ext4"
/dev/sdb9: LABEL="cooker" UUID="751c8a9a51b11" TYPE="ext4"
/dev/sdb10: LABEL="vmguest" UUID="1f22baedc543cb71648" TYPE="ext4"
/dev/sdb11: LABEL="video" UUID="a9736ba47cdea5" TYPE="ext4"
looking for a label with mga2 and comparing
$_current_partition to the /dev/ contents to decide if this
installation is the Production installation.