I used to do this with LILO in the old days. You could load several kernels into your MBR, and I usually had a spare "recovery" kernel in there that I knew worked as a secondary boot option. When updating on Slackware the last step is to run /sbin/lilo which would update my default entry.
With EFI partitions this is still more or less the same, the difference being is that all kernels (and initrds) live on a FAT32 partition. You could theoretically fit the entire Debian netinstall iso ( 40MB ? ) on that partition, and have the BIOS use it as a secondary boot option. The install environment also acts as a recovery mode, which is nice. I've never tried this but that might be a cool experiment to avoid having to remember where my USB installer is. GRUB has scripts that roll kernels so most distros use this by default. In reality its just a couple 'cp' commands and may be a call to efibootmgr or lilo. The install instructions for both Arch and Gentoo are great for this sort of info. They break down the requirements of boot partitions and I find myself using their documentation a lot since it is distro-agnostic. Since GRUB is responsible for rolling kernel releases in this way, you could switch to using GRUB on Slackware since it is installed by default. On Wed, Feb 6, 2019 at 2:12 AM <[email protected]> wrote: > This is losely related to: > Subject: Re: [PLUG] Fixiing Slackware upgrade mistake > > No idea about Slackware ... > > Old kernel versions through GRUB: > --------------------------------- > Bunch of distributions (openSuSE, Ubuntu, Fedora) can boot out of > previous kernel version as long as you do not remove/uninstall them. > This is done automagically by creating Grub entries for them when > installing new kernel by the install script embedded in .rpm or .deb. > > Btrfs disk/volume snapshots in openSuSE: > ---------------------------------------- > As far as I know - openSuSE is the only distro out of the box > supporting restore of any previous OS-partition state (not just kernel > changes) stored as file system snapshots. Snapshots are enabled by > installing the OS on btrfs partition (default). They are automagically > created every time you install something, run update, change config > using it Yast2 (SuSE config tool) or manually on-demand using snapper > tool. By their nature, snapshots store full disk history and take > almost no time to create. > > So, as long as you have up to date disk snapshot you can make config > changes safely. Snapper can be also used to delete old snapshots or > show differences/file changes between them, etc. > > Naturally, snapshots cost disk space. They are diferential, so they > store only the disk changes made between them. Despite that, small file > system changes can add up over couple of hunderds of them over time. > Ocasional clean up is good idea, though you can configure snapper to > only keep some number of them - there is sensible default behavior - I > do not have to do anything to recycle them by default. > > Since the snapshots are cheap and can be created for volumes or sub- > volumes (sort of partitions inside Btrfs partition) - one can setup > data/home partition snapshot creation & rotation by cron every > hour/day/week/month/etc. It is pretty handy. > > Note of caution if you are not experienced with CoW filesystems such as > Btrfs or Zfs - it makes sense to turn off CoW for volumes/sub-volumes > storing files with a lot of frequent changes such as VM images, swap > files or database files. Alternatively, one can keep such files on Ext4 > or Xfs partition. > > -Tomas > _______________________________________________ > PLUG mailing list > [email protected] > http://lists.pdxlinux.org/mailman/listinfo/plug > _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
