Re: Grub-less installation of stretch
On Mon 08 Oct 2018 at 23:41:44 (+0200), Pascal Hambourg wrote:
> Le 08/10/2018 à 22:23, David Wright a écrit :
> > On Mon 08 Oct 2018 at 20:20:24 (+0200), Pascal Hambourg wrote:
> >
> > > So it may be advisable to install at least grub-common and use
> > > grub-mkconfig to generate /boot/grub/grub.cfg. If you also want to
> > > automatically update grub.cfg after a kernel package installation or
> > > removal, you may either install grub-pc (or any other grub flavour
> > > available in the arch) - without installing the boot loader - or
> > > create your own scripts in /etc/kernel/post{inst,rm}.d/ to do
> > > basically the same as zz-update-grub provided by grub-pc.
> >
> > OK. I think I'll install those as grub does seem to do some reasonably
> > complicated stuff which I don't fancy duplicating.
>
> zz-update-grub is a very simple script. Basically it just checks the
> presence of update-grub and runs it. A custom script would just need
> to call grub-mkconfig.
I guess if I only install grub-common, I can provide my own
update-grub in /usr/local/bin which could run grub-mkconfig
but also remind me that I need to rerun grub in the other
system to update the "real" grub.cfg.
> > The main thing is
> > for me to check that nothing can touch the MBR
>
> Then you can install grub-efi. It won't ever write anything to the
> MBR. But if an EFI partition is mounted on /boot/efi, it will write on
> it and will try to register in the EFI NVRAM boot variables.
That's a neat trick. But I'll probably just avoid packages like
grub-pc and grub2-common.
Cheers,
David.
Re: Grub-less installation of stretch
Le 08/10/2018 à 22:23, David Wright a écrit :
On Mon 08 Oct 2018 at 20:20:24 (+0200), Pascal Hambourg wrote:
So it may be advisable to install at least grub-common and use
grub-mkconfig to generate /boot/grub/grub.cfg. If you also want to
automatically update grub.cfg after a kernel package installation or
removal, you may either install grub-pc (or any other grub flavour
available in the arch) - without installing the boot loader - or
create your own scripts in /etc/kernel/post{inst,rm}.d/ to do
basically the same as zz-update-grub provided by grub-pc.
OK. I think I'll install those as grub does seem to do some reasonably
complicated stuff which I don't fancy duplicating.
zz-update-grub is a very simple script. Basically it just checks the
presence of update-grub and runs it. A custom script would just need to
call grub-mkconfig.
The main thing is
for me to check that nothing can touch the MBR
Then you can install grub-efi. It won't ever write anything to the MBR.
But if an EFI partition is mounted on /boot/efi, it will write on it and
will try to register in the EFI NVRAM boot variables.
Re: Grub-less installation of stretch
On Mon 08 Oct 2018 at 20:20:24 (+0200), Pascal Hambourg wrote:
> Le 08/10/2018 à 18:37, David Wright a écrit :
> >
> > (The origin of my system will differ slightly in being debootstrap
> > from another partition running jessie, rather than an upgrade of
> > an older system.)
> >
> > At step 3 (where I'm installing all the packages I want on the new
> > system) remove grub if it's there. (IOW I wouldn't deliberately be
> > installing it. I see no dependencies.)
> >
> > Step 4 as above.
> >
> > Step 5: Now I'm back running jessie (whence I executed the
> > debootstrap and so on).
> >
> > # grub-mkconfig > /boot/grub/grub.cfg
> >
> > which will os-prober the new grub-less system and add entries for it under
> > ### BEGIN /etc/grub.d/30_os-prober ###
> >
> > Step 6:
> >
> > # grub-set-default 'Debian 9 (on /dev/sda7)>osprober-gnulinux-simple-swan07'
> >
> > using the strings I find there.
> >
> > # reboot
> >
> > Would this work, and reboot into the grub-less system? Any snags or gotchas?
>
> Maybe, maybe not. The problem with a GRUB-less installation is the
> lack of /boot/grub/grub.cfg. Without it (or /etc/lilo.conf or
> /boot/grub/menu.lst), grub-mkconfig/os-prober cannot guess the correct
> parameters for the kernel command line. This includes not only
> parameters defined by the GRUB_CMDLINE_LINUX* variables in
> /etc/default/grub but also the root= parameter. Unfortunately, without
> a hint from an existing boot loader config file, it appears that
> grub-mkconfig will use the raw and possibly non-persistent root device
> name, e.g. /dev/sda7 instead of the UUID, or /dev/dm-2 instead of the
> LVM logical volume or encrypted device name.
>
> It may work if the root device is a plain partition whose name does
> not change (e.g. because there is only one disk) and the system does
> not require custom kernel parameters. Remember that logical partition
> numbers may change when creating or deleting another logical
> partition.
>
> But it won't work if the system requires custom kernel parameters or
> the root device is an LVM logical volume or encrypted device, because
> the initramfs needs root= to specify the proper form /dev/mapper/* in
> order to activate and find the device.
Fortunately I'm only in the habit of encrypting /home which is separate.
> So it may be advisable to install at least grub-common and use
> grub-mkconfig to generate /boot/grub/grub.cfg. If you also want to
> automatically update grub.cfg after a kernel package installation or
> removal, you may either install grub-pc (or any other grub flavour
> available in the arch) - without installing the boot loader - or
> create your own scripts in /etc/kernel/post{inst,rm}.d/ to do
> basically the same as zz-update-grub provided by grub-pc.
OK. I think I'll install those as grub does seem to do some reasonably
complicated stuff which I don't fancy duplicating. The main thing is
for me to check that nothing can touch the MBR, and that I have an
always functional grub setup on the older jessie system that has the
working system in menu position 0. Thanks for the hints.
The reason is that this laptop is effectively headless until either of
a) the default jessie system boots successfully or b) I reboot to the
wheezy system via grub-reboot, login and start the X server.
Either of these methods will get me VGA output to a screen; until then
I'm blind: no CMOS, no Boot menu, no Grub menu, and the only
indication that I've got a login prompt is when the disk busy light
settles at off (which means waiting sometimes for cron stuff to finish).
I'm hoping that stretch behaves like jessie and not wheezy. The system
is always on the verge of becoming a brick.
Cheers,
David.
Re: Grub-less installation of stretch
Le 08/10/2018 à 18:37, David Wright a écrit :
(The origin of my system will differ slightly in being debootstrap
from another partition running jessie, rather than an upgrade of
an older system.)
At step 3 (where I'm installing all the packages I want on the new
system) remove grub if it's there. (IOW I wouldn't deliberately be
installing it. I see no dependencies.)
Step 4 as above.
Step 5: Now I'm back running jessie (whence I executed the
debootstrap and so on).
# grub-mkconfig > /boot/grub/grub.cfg
which will os-prober the new grub-less system and add entries for it under
### BEGIN /etc/grub.d/30_os-prober ###
Step 6:
# grub-set-default 'Debian 9 (on /dev/sda7)>osprober-gnulinux-simple-swan07'
using the strings I find there.
# reboot
Would this work, and reboot into the grub-less system? Any snags or gotchas?
Maybe, maybe not. The problem with a GRUB-less installation is the lack
of /boot/grub/grub.cfg. Without it (or /etc/lilo.conf or
/boot/grub/menu.lst), grub-mkconfig/os-prober cannot guess the correct
parameters for the kernel command line. This includes not only
parameters defined by the GRUB_CMDLINE_LINUX* variables in
/etc/default/grub but also the root= parameter. Unfortunately, without a
hint from an existing boot loader config file, it appears that
grub-mkconfig will use the raw and possibly non-persistent root device
name, e.g. /dev/sda7 instead of the UUID, or /dev/dm-2 instead of the
LVM logical volume or encrypted device name.
It may work if the root device is a plain partition whose name does not
change (e.g. because there is only one disk) and the system does not
require custom kernel parameters. Remember that logical partition
numbers may change when creating or deleting another logical partition.
But it won't work if the system requires custom kernel parameters or the
root device is an LVM logical volume or encrypted device, because the
initramfs needs root= to specify the proper form /dev/mapper/* in order
to activate and find the device.
So it may be advisable to install at least grub-common and use
grub-mkconfig to generate /boot/grub/grub.cfg. If you also want to
automatically update grub.cfg after a kernel package installation or
removal, you may either install grub-pc (or any other grub flavour
available in the arch) - without installing the boot loader - or create
your own scripts in /etc/kernel/post{inst,rm}.d/ to do basically the
same as zz-update-grub provided by grub-pc.
