#3065 Issue `closed`: No serial console in recovery system on Debian Trixie (systemd errors)¶

Labels: bug, waiting for info, ready-to-close?, no-issue-activity

martinnaughton opened issue at 2023-11-05 16:13:¶

ReaR version ("/usr/sbin/rear -V"): Relax-and-Recover 2.7 / Git
If your ReaR version is not the current version, explain why you can't upgrade:
OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):

PRETTY_NAME="Debian GNU/Linux trixie/sid"
NAME="Debian GNU/Linux"
VERSION_CODENAME=trixie
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):

OUTPUT=ISO
OUTPUT_URL=file:///media/hd/227DDF392FC0ECAC/
#OUTPUT_URL=null

BACKUP=NETFS
BACKUP_URL=file:///media/hd/227DDF392FC0ECAC/
BACKUP_PROG=tar
BACKUP_PROG_EXCLUDE=("${BACKUP_PROG_EXCLUDE[@]}" '/media' '/var/tmp', '/var/lib/docker/', '/var/cache/apt/archives' )

Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR):
lenovo P52
System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
X86
Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
BIOS
GRUB
Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
local SSD
Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):
Description of the issue (ideally so that others can reproduce it):
When starting the rescue iso from a usb stick. I dd the iso on to the usb stick. the rescue media will be stuck trying to start tty0

You can see it will not start on tty and it will be stuck on this for ever.
Screenshot from 2023-11-05
16-02-26

Workaround, if any:
In the start add this line to the end
console=tty1 systemd.unit=getty@tty1.service

Add the following to your local.conf file and it will will work on tty1 every time without having to do the work

USE_SERIAL_CONSOLE="no"
KERNEL_CMDLINE="console=tty1 systemd.unit=getty@tty1.service"

I noticed on my computer there is only one getty@tty0.service. there is no getty@tty1.service so maybe there is an issue in the script getty@tty0.service

ls /usr/share/rear/skel/default/usr/lib/systemd/system/getty*
/usr/share/rear/skel/default/usr/lib/systemd/system/getty@.service  /usr/share/rear/skel/default/usr/lib/systemd/system/getty.target

/usr/share/rear/skel/default/usr/lib/systemd/system/getty.target.wants:
getty@tty0.service  serial-getty@ttyS0.service

Attachments, as applicable ("rear -D mkrescue/mkback!)" debug log files):

You can drag-drop log files into this editor to create an attachment
or paste verbatim text like command output or file content
by including it between a leading and a closing line of
three backticks like this:

verbatim content

jsmeix commented at 2023-11-06 13:42:¶

In ReaR version 2.7 we got some new issues with serial console
because of a fix for a bug with serial console setup before, cf.
https://github.com/rear/rear/pull/2749#issuecomment-1196427586
which points to the subsequent issue
https://github.com/rear/rear/issues/2843
which shows a generic way how to get serial console setup right
by manually specifying the right serial console setup, see
https://github.com/rear/rear/issues/2843#issuecomment-1196592017
which I implemeted via
https://github.com/rear/rear/pull/2699

So for ReaR version 2.7 the best way is to manually specify
the right serial console setup via the config variables

USE_SERIAL_CONSOLE
SERIAL_CONSOLE_DEVICES
SERIAL_CONSOLE_DEVICES_KERNEL
SERIAL_CONSOLE_DEVICE_SYSLINUX
SERIAL_CONSOLE_DEVICE_GRUB

see the descriptions in usr/share/rear/conf/default.conf
for ReaR 2.7 online at
https://github.com/rear/rear/blob/rear-2.7/usr/share/rear/conf/default.conf#L3094

In current GitHub master code I implemented
"Copy the console= kernel arguments from the original system" via
https://github.com/rear/rear/pull/2961

This should make serial console setup for the ReaR recovery system
more user-friendly (provided the 'console=' kernel arguments from
the original system are also right for the ReaR recovery system).

On https://en.opensuse.org/SDB:Disaster_Recovery
see the section
"Testing current ReaR upstream GitHub master code"
how you can have several ReaR versions in parallel
each one in its own separated directory
without conflicts between each other.

In general I recommend to try out our latest GitHub master code
because the GitHub master code is the only place where we fix things
and if there are issues it helps when you use exactly the code
where we could fix things.