Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #201023 > unrolled thread

Grub-less installation of stretch

Back to article view | Back to linux.debian.user

Contents

  Grub-less installation of stretch David Wright <deblis@lionunicorn.co.uk> - 2018-10-08 18:40 +0200
    Re: Grub-less installation of stretch Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-10-08 20:30 +0200
      Re: Grub-less installation of stretch David Wright <deblis@lionunicorn.co.uk> - 2018-10-08 22:30 +0200
        Re: Grub-less installation of stretch Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-10-08 23:50 +0200
          Re: Grub-less installation of stretch David Wright <deblis@lionunicorn.co.uk> - 2018-10-09 22:10 +0200

#201023 — Grub-less installation of stretch

I didn't want to hijack the "Problem updating to Buster" thread, but
it follows on from:

On Mon 08 Oct 2018 at 18:45:01 (+0300), Reco wrote:
> 2) Mount chroot again (from inside the screen). Ensure you're able to
> run 'apt-get update' without trouble, as you'll need it.
>
> 3) Perform the usual upgrade dance:
>
> apt-get upgrade
>
> apt-get dist-upgrade
>
> The process will ask you questions (many questions, in fact), you're
> assumed to choose answers wisely ;). Take special care while upgrading
> grub.
>
> 4) Unmount chroot, exit screen (simple 'exit' should do it).
>
> 5) Reboot into your brand-new buster installation.

(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?

Cheers,
David.

[toc] | [next] | [standalone]

#201031

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.

[toc] | [prev] | [next] | [standalone]

#201050

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.

[toc] | [prev] | [next] | [standalone]

#201058

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.

[toc] | [prev] | [next] | [standalone]

#201101

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web