#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"
  • ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):

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):

  • Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):

  • Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
    local SSD


  • 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
    Screenshot from 2023-11-05

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

  • Workaround, if any:
    In the start add this line to the end
    console=tty1 systemd.unit=getty@tty1.service
    Screenshot from 2023-11-05

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

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

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.
which points to the subsequent issue
which shows a generic way how to get serial console setup right
by manually specifying the right serial console setup, see
which I implemeted via

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


see the descriptions in usr/share/rear/conf/default.conf
for ReaR 2.7 online at

In current GitHub master code I implemented
"Copy the console= kernel arguments from the original system" via

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.

pcahyna commented at 2023-11-07 18:12:

The screenshot show many errors, so a bad console argument is probably not the problem. The issue looks a lot like #3017

pcahyna commented at 2023-11-13 18:33:

@martinnaughton can you please check if the change in #3079 fixes the problem?

pcahyna commented at 2023-11-18 18:46:

@martinnaughton #3079 merged, please retry with the latest GitHub checkout

pcahyna commented at 2024-01-08 13:25:

@martinnaughton , can you please retest?

github-actions commented at 2024-03-09 01:58:

Stale issue message

pcahyna commented at 2024-03-11 13:29:

@martinnaughton , any news?

github-actions commented at 2024-05-11 02:05:

Stale issue message

[Export of Github issue for rear/rear.]