The integrated VGA in this T440 server shows the BIOS and the Unraid boot process. It ends with a text mode shell display, but after 10 minutes or so, times out and the screen blanks. How can I configure Unraid so the VGA display controlled by the Unraid system remains active?

This was added as a setting in v7

Settings> Console settings>



Disable Screen Blank Time.

Otherwise you need to edit the main>flash and add a append option of consoleblank=0
Main > Flash > Syslinux

Edited October 26, 2025Oct 26 by bmartino1
fix mispelling of grub line

Thank you! It even un-blanked the console on my running system when I set to disabled.

I'm trying to figure out why it takes something like 10 minutes to reboot Unraid so I want to know what's going on - if it is in Unraid, or the T440 POST.

Follow up question - Now that I've got the console monitor staying on, I'm thinking "what can I do with it"?

Is it possible to configure the system to copy the system log to the console? I might as well have some visibility on what is happening.

Now it just sits at the login prompt.

Not by default, but you can use the tail command:

tail -f /var/log/syslog

run command dmesg will show the syslog to INDEF see the log in the terminal screen use the tail command Jorge sent above. ctrl c to leave it

the -f is follow so it will constaly show the lines sent to the log file

19 hours ago, JorgeB said:

Not by default, but you can use the tail command:

tail -f /var/log/syslog

Since I don't have a keyboard attached to the console, I tried to initiate the tail command from an SSH session as a persistent, background process like this:

root@T440:~# nohup tail -f /var/log/syslog > /dev/tty1 2>&1 < /dev/null &

On the SSH terminal it displays the process ID as expected.

[1] 2090751

What happens is:

1) The console monitor (tty1) displays only this: "nohup: ignoring input and appending output to 'nohup.out'"

2) tail output goes into file /nohup.out, not the console display.

AI says "it should redirect everything to /dev/tty1, the behavior you're seeing suggests that Unraid's shell or nohup implementation may be overriding or interfering with the redirection — possibly due to how pseudo-terminals and device permissions are handled."

I'm learning to not trust AI advice regarding Unraid, so back to you to provide any insights on why this doesn't work as expected.

Edited October 28, 2025Oct 28 by timg11

with linux it can be had geting 0:0 for the display.. same for which tty line or consol line that unraid uses.

I can see a user script at first boot to do this but we need to tell quite a bit to get which line unraid is using at boot.
some of this can be done in the grub syslinux append option.

some of this can be done with the the unraid go script... I need to test as I never botherd needing to use a headless and running a command to do that at the host level.

May require 3rd party install of slackpackage program called screen

Unraid is slackware linux.
This may not be fesible without a keyboard as even teh Main console requires a username password... to login to the tty...

Edited October 28, 2025Oct 28 by bmartino1

run tty and get the monitors tty line it will be needed later!

Main > Flash > Syslinux Configurations... where we can add adational grub syslinux configuration...

we need to set the console first! This is to guarantee it to always be at /dev/tty1 (at least this is the debain grub command may or may not work in unraid!)

append initrd=/bzroot console=tty1

then with user script set to first array start to accomplish our goal...

unraid /boot/config/go is the script that launches the unraid web ui and runs before the array start.
user script plugin makes scripts on cron my go to is at first array start as its when the array is online.


example script:

#!/bin/bash
set -euo pipefail

# ===== FIXED SETTINGS (edit if you want a different TTY or log) =====
TTY_DEV="/dev/tty1"
TTY_BASENAME="tty1"
INIT_ID="c1"
LOG_FILE="/var/log/syslog"
WRAPPER="/usr/local/sbin/tty-console.sh"
# ====================================================================

echo "[*] Configure ${TTY_DEV} as a live syslog console (Ctrl+C -> root shell)"

[[ -e "$TTY_DEV" ]] || { echo "[-] ${TTY_DEV} not found"; exit 1; }

# 1) Install the wrapper process that *is* the console on TTY_DEV
mkdir -p "$(dirname "$WRAPPER")"
cat > "$WRAPPER" <<'EOS'
#!/bin/bash
# Bind to the console and make this our controlling TTY
exec </dev/tty1 >/dev/tty1 2>&1
stty sane >/dev/null 2>&1 || true
printf "\033[2J\033[H"  # clear screen

TTY_WANT="/dev/tty1"
LOG_WANT="/var/log/syslog"

echo
echo "=== Live syslog on ${TTY_WANT} ==="
echo "Press Ctrl+C to drop into a root shell on this console."
echo

# Ctrl+C -> switch to an interactive root login shell
trap 'exec /bin/bash -l' INT

# Show entire file then follow in foreground
tail -f -n +1 "$LOG_WANT"
EOS
chmod 755 "$WRAPPER"

# Bake your chosen TTY/log into the wrapper
sed -i \
  -e "s#^exec </dev/tty1 >/dev/tty1 2>&1#exec <${TTY_DEV} >${TTY_DEV} 2>\&1#" \
  -e "s#^TTY_WANT=.*#TTY_WANT=\"${TTY_DEV}\"#" \
  -e "s#^LOG_WANT=.*#LOG_WANT=\"${LOG_FILE}\"#" \
  "$WRAPPER"

# 2) Point c1 to our wrapper (no agetty, no autologin)
if grep -qE "^${INIT_ID}:" /etc/inittab ; then
  sed -i "s#^${INIT_ID}:.*#${INIT_ID}:12345:respawn:${WRAPPER}#" /etc/inittab
else
  echo "${INIT_ID}:12345:respawn:${WRAPPER}" >> /etc/inittab
fi

# 3) Apply now: make init reread, and kill any current agetty on that TTY so it respawns our wrapper
telinit q || true
pkill -f "agetty .*${TTY_BASENAME}" || true
sleep 0.5

# Debug
echo "[D] inittab ${INIT_ID}: $(grep "^${INIT_ID}:" /etc/inittab || echo 'missing')"
echo "[D] process bound to ${TTY_BASENAME}:"
ps ax | grep -E "(${WRAPPER}|agetty).*${TTY_BASENAME}" || echo "  (init will spawn it)"

echo "[✓] ${TTY_DEV} is now a live syslog console."
echo "    Ctrl+C -> root shell; 'exit' -> back to log view (init respawns)."

# -------- OPTIONAL: quick revert helper (comment out if you don't want it) --------
# To revert to standard login on tty1, run these two lines manually:
# sed -i 's#^c1:.*#c1:12345:respawn:/sbin/agetty 38400 tty1 linux#' /etc/inittab ; telinit q ; pkill -f "(/usr/local/sbin/tty-console\.sh|agetty .*tty1)" || true
# ---------------------------------------------------------------------------------

Example: Proof of concept. all headless:

Edited October 28, 2025Oct 28 by bmartino1
spelling

this does make a securty vul if accessable in person:

@bmartino1- Wow,  I was expecting a minor tweak to my one-liner, but it takes a complex 72 line script!  But I can see it is better that passively redirecting tail -f syslog to tty. 

It gives the syslog on the display, but then allows dropping to shell if I ever decide I need to hook up a keyboard to the server.  (I'm not worried about physical access - the server is physically secure.  I'm guessing the interactive shell after ^C is already logged in as root, rather than displaying the Login: prompt as it does now) 

I'll have to study this for a while. I don't yet understand the "wrapper" concept. I've never heard of c1, agetty, telinit, or "set -euo pipefail" before - will have to research. 

22 minutes ago, timg11 said:

@bmartino1- Wow,  I was expecting a minor tweak to my one-liner, but it takes a complex 72 line script!  But I can see it is better that passively redirecting tail -f syslog to tty. 

It gives the syslog on the display, but then allows dropping to shell if I ever decide I need to hook up a keyboard to the server.  (I'm not worried about physical access - the server is physically secure.  I'm guessing the interactive shell after ^C is already logged in as root, rather than displaying the Login: prompt as it does now) 

I'll have to study this for a while. I don't yet understand the "wrapper" concept. I've never heard of c1, agetty, telinit, or "set -euo pipefail" before - will have to research. 

alot of this is from over the years of messing with linux before systemd

unraid - slackware linux uses system int varables. for example a script exsits at boot to make and bring up the network...

SO I will try to break it down as I esenataly wnet searching and found how unraid was making there tty connections and settings...

Basically replacing the normal login “getty” on tty1 with a tiny program (“the wrapper”) that:

1. binds itself to the physical console,

2. prints/follows your syslog there, and

3. on a key combo, swaps into a root shell — then, when you exit, init respawns the wrapper so you’re back to the live log.

As this was the ship what works...
Quick review

Creates a dedicated “wrapper” at /usr/local/sbin/tty-console.sh that binds to a TTY and runs tail -f on a log file.

1. Updates /etc/inittab so the c1 console is no longer an agetty login but your wrapper, with respawn so it always comes back.

2. Signals init with telinit q to reload inittab, and kills the old agetty so init respawns immediately into the wrapper.

3. Templated: you can point at another TTY or another log by editing the variables at the top. (copy script use and set another tty line...
   

We can tighten the script up ...

One thing I’d tighten (Ctrl+C behavior)... only becaseu I don't want local unath access... (And could potental manipulate a relogin) more wanted a at idel esc if not at login screen as some modern linux will have syslg dmesg fall over into the concole tty line... IE you may see when docker start and the fall over syslog data aborut veth and other dockers networks being made...

So, Right now the wrapper sets trap 'exec /bin/bash -l' INT and then runs tail -f in the foreground. On most shells, Ctrl+C hits the foreground process (tail), not the parent shell, so the trap in the parent often won’t fire. Practically you’ll see tail just stop and init will respawn your wrapper again, instead of dropping you into a shell.

Line-by-line “what & why” for a newcomer
as this is some linux peral/bash scripting on linux...

#!/bin/bash – run with bash.

• set -euo pipefail – safer bash defaults:

  • -e: exit if any command fails (non-zero).

  • -u: treat unset variables as an error.

  • -o pipefail: make pipelines fail if any command fails, not just the last.

• Variables (TTY_DEV, INIT_ID, etc.) – the TTY we’re commandeering, which inittab slot to change, and what log to show.

Wrapper creation

• We write a small program (/usr/local/sbin/tty-console.sh) that becomes the process that owns the console and renders the log.

• Inside the wrapper:

  • exec </dev/tty1 >/dev/tty1 2>&1 – bind stdin/stdout/stderr to the console; the exec replaces the shell’s Full Displays so everything goes to the screen/keyboard.

  • stty sane – reset terminal modes in case the TTY was left in a weird state.

  • A banner and instructions.

  • trap ... INT – handle Ctrl+C; when bash receives SIGINT it runs the trap, which execs a login shell. (somethign we can change behavior...)

  • tail -F – follow the log and survive log rotations (-F vs -f).

  • With my tweak, tail runs in the background and the shell waits so it can catch SIGINT.

Inittab surgery

• /etc/inittab maps virtual consoles (like tty1) to what program init should spawn there.

• The c1:12345:respawn:COMMAND line means:

  • c1 – a label (your script variable INIT_ID).

  • 12345 – the runlevels it applies to (common catch-all).

  • respawn – if the process dies/exits, start it again.

  • COMMAND – normally /sbin/agetty ..., but you switch it to your wrapper.

• telinit q – tell init to re-read /etc/inittab (no reboot needed).

• pkill -f "agetty .*tty1" – kill the current login prompt process on that TTY so init immediately respawns using the new command (your wrapper).

• The debug print shows the live inittab line, and any process bound to that TTY.

Revert helper

• Your one-liner restores c1 to the standard agetty line, re-reads inittab, and kills any leftover wrapper/getty so the TTY flips back right away.

This is why at the bottom too turn it off you sed out the /etc/inittab we write...

# sed -i 's#^c1:.*#c1:12345:respawn:/sbin/agetty 38400 tty1 linux#' /etc/inittab ; telinit q ; pkill -f "(/usr/local/sbin/tty-console\.sh|agetty .*tty1)" || true

*restoring defaults...

Concepts you mentioned (short intros)

• Wrapper – just a tiny program that “wraps” some behavior. Here, instead of running agetty (login prompt), init runs your wrapper. The wrapper owns the console, shows the log, and can morph into a shell on demand.

• c1 – the label in /etc/inittab for the first console (traditionally /dev/tty1). Others are often c2 → tty2, etc. (cat /etc/inittab see for your self...)

• agetty – the login prompt program on text consoles/serial lines. It prints login: and launches /bin/login after you authenticate.

• telinit – command to talk to init (the PID 1 process) and, among other things, request it to reread inittab.

• set -euo pipefail – safer bash mode; explained above.

Compatibility notes

• This approach assumes SysV-style init with /etc/inittab (e.g., BusyBox init on Unraid, some embedded distros).
  On systemd systems, /etc/inittab is ignored; you’d instead ship a systemd unit that binds to a getty target or uses agetty --autologin root with an override. (If you want a systemd version later, I can drop one in.)

• Persistence on Unraid: edits to /etc/inittab may be in RAM. Typically you’d add your changes to the Unraid “go” file or a boot-time script so they reapply after reboot.

  • I prefer user script pluin as go file failures can lead to no unraid web ui. and some things are just to earlier inteh boot process...
    

Linux Man pages & references (good places to read)

• man 5 inittab — format and semantics of /etc/inittab.

• man 8 init and man 8 telinit — the init process and control interface.

• man 8 agetty — the console/serial login program.

• man 1 tail — following files, -f vs -F, -n.

• man 1 stty — terminal line settings (why stty sane helps).

• man 1 ps, man 1 grep, man 1 sed, man 1 pkill — the utilities used for process listing, search, editing, and signaling.

• man 1 bash — read the “Signals” and “INVOCATION” sections; also search for set -e, -u, pipefail, and trap.

https://linux.die.net/man/

Thanks again for the tutorial - extremely helpful! I'll study up on these.  I've only been using Linux for about 10 years (Raspian, Ubuntu, Debian, and now Unraid), so that makes me a beginner compared to true veterans like you. (I did use Solaris on a Sun workstation in the late 90s and early 2000s, but that was just for Verilog simulation, and I had a company sysadmin to take care of it) 

I already have the User Scripts plugin installed in Unraid so I can leverage that. 

I can see that things could go very badly if this type of script malfunctioned. Would the effects of the wrapper and "Inittab surgery" be limited to the tty/agetty that appear on the monitor?  I.E. would SSH access and the web GUI be completely independent and unaffected if it became necessary to revert these changes? Or would recovery mean restoring my Unraid boot USB flash from a backup? 

1 hour ago, timg11 said:

Thanks again for the tutorial - extremely helpful! I'll study up on these.  I've only been using Linux for about 10 years (Raspian, Ubuntu, Debian, and now Unraid), so that makes me a beginner compared to true veterans like you. (I did use Solaris on a Sun workstation in the late 90s and early 2000s, but that was just for Verilog simulation, and I had a company sysadmin to take care of it) 

I already have the User Scripts plugin installed in Unraid so I can leverage that. 

I can see that things could go very badly if this type of script malfunctioned. Would the effects of the wrapper and "Inittab surgery" be limited to the tty/agetty that appear on the monitor?  I.E. would SSH access and the web GUI be completely independent and unaffected if it became necessary to revert these changes? Or would recovery mean restoring my Unraid boot USB flash from a backup? 

Correct this doesn't affect ssh for security, only the /dev/tty1 line. ssh will not see nor interact with it unless you use ssh to connect and call that tty console line by implementing other configuration and another type of wrapper.... it is limited to the tty 1and the Getty wrapper for /dev/tty1 only the variable defined at the top. if recovery is needed its always recommened to make a flash backup and unplug the usb entering the config folder deleting the user plugin script from the folder and plug the unraid usb in to boot like normal. When unraid boot it mounts the flash drive at /boot the user script is stored in the plugin folder in the config folder on the flash drive.

so recovery:
root@The-Borg:/boot/config/plugins/user.scripts/scripts# ls

DNS-sharfhoffen/ Fix-Hosts/ brandon-tailscale/ show_broadcasts/ tailscale-Stop/

DockerUpdateAllRunning/ FixShareServers-NFS_and_Samba/ fix-vhost0/ smb_replace_fix/

Error-syslog-notify/ ZFS-snapshots/ rsync-appdata/ systemctl/

root@The-Borg:/boot/config/plugins/user.scripts/scripts#

Delete the folder holding the script so it doesn't run from the usb drive.

However, This script is fairly safe and kinda fool prof essential we make a script (the wrapper we want to run) and replace only the /dev/tty1 line in the /etc/inittab line. This is why I have a undo in the script at the bottom... to undo looks for our sed edit to remove. as you could edit the script and uncomment the text file so it will run at boot and remove itself leaving a wrapper script in /usr/local/sbin/tty-console.sh
??? I guess you cold ssh login and run the script... though its only affecting /dev/tty1 so ssh wouldn't gain root access...

On the physical console, you’ll see something like: /dev/tty1 (or tty2, etc.).
Over SSH you’ll see a pseudo-terminal like: /dev/pts/0.

since tty1 is not inside a shared tmux session... in order for this ttyl to be connected to the ssh you would have to run other lines to connect it... by editing the /etc/inittab line with a different wrapper line like...

# wrapper used by tty1 (e.g., /usr/local/sbin/tty1-wrapper)

#!/bin/bash

exec tmux new -A -s console /bin/bash

then once you have sshed into the system you would run something like:
tmux attach -t console

which would give you that consol tty line over ssh...

This would require setting it up beforehand... its also why i mentioned the screen application/command... for unraid we can install 3rd party application (like plugins) a Slackware extra package as with screen we could runn something in a screen disconnect from the screen connect to ssh reconnect the screen..

https://slackware.pkgs.org/15.0/slackware-x86_64/screen-4.9.0-x86_64-1.txz.html

you could put the binary package in /boot/extra to have this installed at boot for unraid 3rd party install:
https://slackware.uk/slackware/slackware64-15.0/slackware64/ap/screen-4.9.0-x86_64-1.txz
https://linux.die.net/man/1/screen

AS ssh makes a different virtual console, it is and will not affect on their console's tty terminal session.

Edited October 28, 2025Oct 28 by bmartino1
spelling - forum werdness with links