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.
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.