Issues, I got issues "/etc/issue"

In another post I mentioned how with VM’s I add this line

IPV4: \4{eth0}

To my /etc/issue… With a VM it displays the IP address on the console, e.g. in VMware ESX / vSphere / vCenter - or in VirtualBox…

I’m trying to get it work over serial - but it only shows AFTER I’ve logged in, then out (i.e. too late!)… i.e. I want it to show the IP addresses of my NICs BEFORE I login, via the serial console - BEFORE / ABOVE the login prompt.

Anyway - probably something to do with :

/etc/systemd/system/getty.target.wants/getty@tty1.service

But no idea how to make that happen… Note also - this is Raspberry / Raspbian - there’s no grub… Nearly all of the online “literature” assumes grub, and a lot if predates even systemd…

You want it to send a message to the display manager?
Or is this a dumb terminal with a login prompt? That would be easier. It needs to add something to dmesg log… thats what displays before the prompt.

Yes - not quite stupid or dumb, but yeah… that… The whole serial comms thing is beyond my skillset, so I don’t think “dumb” describes it :smiley: - e.g. a “dumb terminal” isn’t as stupid as a VGA monitor or even an LCD HDMI display…

i.e. it works - displays /etc/issue contents via “getty” on the console, that worls all the time - everytime, e.g. on a monitor connected to a server not running X or a DM / DTE - or - the “virtual” console of a server VM.

But with agetty outputting over a serial line - it doesn’t show /etc/issue until AFTER you’ve logged in, then out… which pointless… Ideally I’d like to connect via serial port (I’m using minicom, I used to use “cu” command, but it seems buggy in Ubuntu 22). Anyway - minicom seems more stable (and I’ve been using it for nearly 30 years or so) - “cu” bombs out - and anyway - when cu’s working, it still doesn’t display /etc/issue…

/usr/bin/minicom -d /dev/ttyACM0

Hmmm…

Just noticed something - tried to get in with cu (cu -l /dev/ttyACM0 -s 115200) got in, logged out - and instead of logging out to login prompt, it hungup the connection… Straight after that I tried “minicom -d /dev/ttyACM0” and it shows the two IP address entries from /etc/issue - configured thusly :rage:

My /etc/issue :

Raspbian GNU/Linux 11 \n \l

IPV4: \4{wlan0}
IPV4: \4{usb0}

And now it’s back to the previous symptom (not displaying my /etc/issue in the serial console login prompt in minicom) :

Welcome to minicom 2.8

OPTIONS: I18n 
Port /dev/ttyACM0, 09:28:51

Press CTRL-A Z for help on special keys
...
mimas login: 
...
mimas login: 
...
CTRL-A Z for help | 115200 8N1 | NOR | Minicom 2.8 | VT102 | Online 0:1 | ttyACM0

Those “…” lines are repeated entries where I’ve pressed carriage return multiple times in a futile attempt to get it to display /etc/issue…

This is not a show-stopper, its just a niggle that annoys me, and I’d like to solve it…


Note - tried a bunch of things - adding “-f” to both / all “execstart” entries :

ExecStart=-/sbin/agetty -f -o ‘-p – \u’ --noclear %I $TERM

Makes no difference…

Rebooted - it shows up first time - i.e. at the login prompt, ABOVE the login prompt - as expected. Exit minicom (hangup) run it again, and /etc/issue doesn’t show again, so I’m guessing what I need to figure out - is how to force getty to respawn on hangup…

What I want to achieve here, is two methods of connecting to my Pi Zero 2W from most devices - e.g. next week I’m going back to my old job, and they’ll probably force me to use their Windows SOE - AFAIK they don’t have a Linux SOE or MacOS option. Note my current employer does offer a choice, tried the Linux offering, RHEL 8, but never got it to connect to their GlobalProtect regional portal, so stuck with the MacBook Air they’d sent me.

My new (old) employer, has changed - i.e. it was an Aussie (Perth based ~1000 or less employees) but the company was absorbed into a mega international (with ~300K employees) - I left in April - the transaction happened last year - but now they’ve FULLY rebranded to the parent company - so I still don’t know what, if any, choices I might have for company supplied laptop, and whether I can BYOD when working from home (I LOATHE lugging a laptop back and forth from the office! and I loathe even more being FORCED to use Windows).


Update : I’ve noticed if I wait like X hours (dunno - maybe 12? 16?) when I next connect to the serial console on this device, /etc/issue IS DISPLAYED! But - sure enough, exit minicom, connect again - no IP address shown…

Note : it’s only showing the gadget (USB0) NIC IP address (it should show both - when it works, it shows both)


The systemd information displayed by getty@tty1.service (which I’ve deliberately disabled in my troubleshooting) points to some VERY useful documentation :

╭─x@mimas ~  
╰─➤  sudo systemctl status getty@tty1.service
● getty@tty1.service - Getty on tty1
     Loaded: loaded (/etc/systemd/system/getty@.service; disabled; vendor preset: enabled)
    Drop-In: /etc/systemd/system/getty@tty1.service.d
             └─autologin.conf, noclear.conf
     Active: inactive (dead)
       Docs: man:agetty(8)
             man:systemd-getty-generator(8)
             http://0pointer.de/blog/projects/serial-console.html

Which in turn pointed me to :
serial-getty@ttyGS0.service

and when I restart that - both my NIC IP addresses (via /etc/issue) are showing in the serial console… just the once… if I exit / hangup the minicom session, and reconnect, I just get the login prompt :

Welcome to minicom 2.8

OPTIONS: I18n 
Port /dev/ttyACM0, 10:46:18

Press CTRL-A Z for help on special keys


mimas login:

So - I think I’m getting closer… those getty@ systemd things don’t seem to have been doing anything (I guess one way to find out is if they’ve broken HDMI console display?) at all - or don’t seem to have broken anything by disabling (need to confirm with a mini [not micro] HDMI adaptor to an actual monitor).

I did try changing cmdline.txt (its like the ARM equivalent of GRUB - I think it’s called UBOOT) console=tty1 to console=ttyGS0 - and it broke everything… in fact :

image

The Pi’s not dead, but the serial gadget terminal is… too much uncontrolled much change…


It wasn’t the console=ttyGS0 entry in /etc/cmdline.txt… must have been the “-f” argument I added to the line :
ExecStart=-/sbin/agetty -o '-p -- \\u' --keep-baud 115200,57600,38400,9600 %I $TERM
(I put it right after “agetty”)
in
/etc/systemd/system/getty.target.wants/serial-getty@ttyGS0.service

took that out and restarted it…

Note - this screenshot shows :


Above the red line - first connect via minicom, below the redline, when I restarted serial-getty@ttyGS0


This might seem petty, but, ideally I’d like to get this working, or understand how to make it work, all the time, every time… I vastly prefer the old days, where you’d have a serial multi-plexor with a Wyse or DEC ansi / ascii terminal to connect to a UNIX server console… all that VGA and PS/2 or USB HID device connectivity seems such a waste and so inefficient…

Sure - it would make Wintel clickety-click-click-click system administrators stain their tighty-whiteys, but I reckon about 75-90% of Intel server installs, are blades, running ESX (Photon O/S using the Linux kernel) - with character based consoles - and it would be heaps better to just have serial interface for the console…

1 Like