Fantastic news. Please edit the title of the thread (in the first post) and prepend [SOLVED] to help others who encounter this problem.

That might help (if the manufacturer has bothered to fix the problem) but it might also brick your machine. Be careful!

Lol. It would if the implementations were of a reasonable quality but apparently that hits the profit margin too much

For my Debian bullseye system I have a systemd timer calling this simple rsync script every week to back up the system to the spare internal drive in my ThinkPad:

#!/usr/bin/env ksh

_date="$(date -I)"
error_log=/var/log/backup_errors-"$_date".log
uuid=ae1c7741-67e6-4919-b3d8-3d3626709ae1

function rsync_backup {
   /usr/bin/rsync -aAXq --delete --exclude={'/dev/*','/proc/*','/sys/*','/tmp/*','/run/*','/mnt/*','/media/*','/lost+found','/efi/*','/home/empty/Music/*','/home/empty/Downloads/*'} / /mnt/debian/ 2>"$error_log"
   [ -a /mnt/backup-* ] && rm /mnt/backup-*
   touch /mnt/backup-"$_date"
}

function clear_logs {
   if [ "$(stat -c %s "$error_log")" = 0 ]
   then
      rm "$error_log"
      printf 'Empty error log deleted.\n'
   else
      printf 'Errors in log, not deleting.\n'
   fi
}

printf 'Mounting backup partition...\n'
if mount /dev/disk/by-uuid/"$uuid" /mnt ; then
	printf 'Mounted backup partition.\n'
	printf 'Beginning backup...\n'
	rsync_backup
	printf 'Backup complete.\n'
else
	printf 'Backup failed, partition not mounted correctly.\n'
fi

printf 'Clearing empty error log files...\n'
clear_logs

printf 'Un-mounting backup partition...\n'
umount /mnt && printf 'Un-mounted backup partition.\n'

printf 'All done :-)\n'

I won't share the systemd .timer & .service units because I'm pretty sure nobody will find them of any use :-)

For my Alpine system I drop this script in /etc/periodic/daily/ to take a snapshot of the root filesystem every day and create a submenu listing the available snapshots in GRUB (five snapshots are kept at any one time with the excess being deleted by the script):

#!/bin/sh

PATH=/usr/sbin:/usr/bin:/sbin:/bin
time=$(date +'%Y-%m-%d@%T')
grub_dir=/boot/grub
config_file="$grub_dir"/alpine-snapshots.cfg
snapshot_dir=/snapshots
subvol_dir="$snapshot_dir"/alpine
uuid=$(findmnt -o uuid -n /)
kernel=/boot/signed-vmlinuz-lts
parameters='rw quiet modules=btrfs'
ucode=/boot/amd-ucode.img
initrd=/boot/initramfs-lts

get_snap_info() {
	snap_list=$(for snap in "$snapshot_dir"/* ; do printf '%s ' "$(basename -- "$snap")" ; done)
	snap_number=$(printf '%s\n' "$snap_list" | wc -w)
	old_snap=$(printf '%s\n' "$snap_list" | awk '{print $1}')
}

if grep -q ' / .*snapshot.*' /proc/self/mounts ; then
	printf 'Booted into snapshot, no action taken.\n'
else
	printf 'Removing old configuration file...\n'
	if [ -e "$config_file" ] ; then
		rm "$config_file"
	else
		printf 'No configuration file found.\n'
	fi
	printf 'Creating new snapshot...\n'
	btrfs subvolume snapshot / "$snapshot_dir"/"$time"
	get_snap_info
	while [ "$snap_number" -gt 5 ] ; do
		printf 'Removing excess snapshot...\n'
		btrfs subvolume delete "$snapshot_dir"/"$old_snap"
		get_snap_info
	done
	printf 'Creating new configuration file...\n'
	printf '#\n' > "$config_file"
	for entry in "$snapshot_dir"/* ; do
		ed "$config_file" > /dev/null <<!
1i
menuentry '${entry##*/}' {
	search --fs-uuid --set=root $uuid
	linux $subvol_dir/${entry##*/}$kernel root=UUID=$uuid rootflags=subvol=$subvol_dir/${entry##*/} $parameters
	initrd $subvol_dir/${entry##*/}$ucode $subvol_dir/${entry##*/}$initrd
}
.
w
!
	done
	printf 'All done!\n'
fi

Snapshots aren't really backups, as such, but I'm tracking Alpine's edge version and the ability to rollback to a prior state is very useful with a rolling release distribution. I have a similar script in my Arch box that's called by another systemd timer unit.

For the family laptop I run rsync manually to a pair of separate stand-alone hard drives. Backups for that are too important to automate...

I always backup from a running system with all of the target partitions mounted. This is fine with rsync as long as you don't mind the stuff you're working on during the backup process not being saved.

The grub-pc package is for non-UEFI systems but your EFI system partition suggests that is not appropriate.

Check for /sys/firmware/efi, that will only exist if you are booted in UEFI mode.

If you see the rescue prompt then that means GRUB cannot find it's modules. Use the set command to find where it is looking.

That's far too vague — what were the *exact* commands that you used?

I would recommend dpkg-reconfigure instead of grub-install & update-grub but the target package would depend on whether you have a UEFI system or not.

^ I think the error message is referring to the NVRAM contents rather than the hard drive.

@OP: you can stop GRUB from attempting to update the NVRAM entries:

# debconf-set-selections <<<'grub-efi-amd64 grub2/update_nvram boolean false'

Alpine Linux uses the dynamically-linked busybox version for /sbin/init, /bin/sh and the core utility programs that are usually supplied by GNU's coreutils package. So it should really be called Alpine busybox/Linux :-)

Static linking doesn't really work for glibc anyway, which is another advantage of musl libc.

I'll stop dragging this thread off-topic now. Sorry all.

I’d just like to interject for a moment. What you’re refering to as Linux, is in fact, systemd/Linux, or as I’ve recently taken to calling it, systemd plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning systemd system made useful by the systemd corelibs, shell utilities and vital system components comprising a full OS as defined by Red Hat.

Many computer users run a modified version of the systemd system every day, without realizing it. Through a peculiar turn of events, the version of systemd which is widely used today is often called Linux, and many of its users are not aware that it is basically the systemd system, developed by the systemd project.

It uses tint2 instead of xfce4-panel and it has a version of jgmenu, which is a brilliant stand-alone menu system. Not sure why they don't just use the Lithium version of jgmenu though, the developer is also a BunsenLabs developer so it is very well supported in those repositories.

They're using xfce4-session v4.12.1-6 (ie, the stock Devuan beowulf version).

So it's using Xfce but with tint2 as the panel and jgmenu for the menu:

The jgmenu package is taken from BunsenLabs' stretch-backports repository, which is a bit of a strange choice, and the backported kernel is used, which will expose the system to known vulnerabilities for longer that most would consider prudent.

The website is decidedly minimal but won't show anything without javascript enabled and there is no live image yet (I had to install the system to test it). The "source code" is available from the GitHub site but it just contains the README.md & LICENCE files, which is a shame because I would have liked to see the live image configuration.

The installer offered a choice of init system — sysvinit, openrc (as a service manager with sysvinit as PID1) or runit — but my test shows sysvinit even though I requested runit. I should probably report that as a bug...

See http://forums.debian.net/viewtopic.php?f=10&t=148806 & http://forums.debian.net/viewtopic.php?f=6&t=148829

The Debian wiki has a Bumblebee page with the same instructions but you don't have to wade through a swamp of adverts & javascript to read that.

Check the firmware ("BIOS") options, there may be a setting to change from "Hybrid" to "Discrete" for the NVIDIA card. Try looking under Config → Display → Graphics Device.

See https://download.lenovo.com/pccbbs/mobi … r_v1.0.pdf & https://download.lenovo.com/pccbbs/mobi … n_v1.0.pdf for some examples.