I have a machine running Fedora 41 which has stopped providing video for its console. Of course, the problem could be hardware, but there is no clear evidence of that. I am able to access the machine with SSH so I know it is working. I don't find any indication of a problem in log files. To help diagnose the issue, I'd like to access its console through its serial interface. (The machine does have a DB9 serial connector and I have verified that it works properly.)
I have connected a serial to USB adapter to the machine's serial port and connected the other end of the USB cable to a laptop (also running Fedora 41). On the laptop, I've started putty and selected a serial connection to ttyUSB0 at speed 38400. On the problem machine, I've run the following commands as root with no errors reported.
# grubby \ --args="systemd.journald.forward_to_console=1 \ console=ttyS0,38400 console=tty1" --update-kernel=ALL # # The line continuation above is only for readability. # # The actual command was all one line. # grubby --set-default=/boot/vmlinuz-6.13.9-200.fc41.x86_64 # grub2-mkconfig -o /boot/grub2/grub.cfg # grub2-install /dev/sda # reboot
I then SSH into the problem machine and check for agetty.
# ps -ef | grep [g]etty root 1429 1 0 21:55 tty1 00:00:00 /sbin/agetty -o -p -- \u --noclear - linux root 1430 1 0 21:55 ttyS0 00:00:00 /sbin/agetty -o -p -- \u --keep-baud 115200,57600,38400,9600 - vt220 # Again, lines are split and condensed here only for readability.
After all this, I get no output on the putty connection and no response when attempting any entry. I've also tried the other listed baud rates.
Is there any obvious step I've missed? Is there a better way to do this?
If the machine does not crash then the serial console is not going to have any information that dmesg from ssh does not have.
The use-case for the serial console(or kdump) is when the machine stops and you can no longer see dmesg output from that boot.
Likely you will need to find the log file for the Wayland/X session and look at it.
I have had my display disappear and not come back when turning on/off a monitor/tv. Sometimes on/off again works, sometimes moving the hdmi cable to another monitor port works, and sometimes I have to reboot. And in these cases the machine is still working via ssh, it seems to be some sort of issue in the video driver.
My graphics card is a a Renoir/Radeon Vega Mobile series graphics card built into the cpu.
On Wed, Apr 2, 2025 at 12:31 AM Dave Close dave@compata.com wrote:
I have a machine running Fedora 41 which has stopped providing video for its console. Of course, the problem could be hardware, but there is no clear evidence of that. I am able to access the machine with SSH so I know it is working. I don't find any indication of a problem in log files. To help diagnose the issue, I'd like to access its console through its serial interface. (The machine does have a DB9 serial connector and I have verified that it works properly.)
I have connected a serial to USB adapter to the machine's serial port and connected the other end of the USB cable to a laptop (also running Fedora 41). On the laptop, I've started putty and selected a serial connection to ttyUSB0 at speed 38400. On the problem machine, I've run the following commands as root with no errors reported.
# grubby \ --args="systemd.journald.forward_to_console=1 \ console=ttyS0,38400 console=tty1" --update-kernel=ALL # # The line continuation above is only for readability. # # The actual command was all one line. # grubby --set-default=/boot/vmlinuz-6.13.9-200.fc41.x86_64 # grub2-mkconfig -o /boot/grub2/grub.cfg # grub2-install /dev/sda # reboot
I then SSH into the problem machine and check for agetty.
# ps -ef | grep [g]etty root 1429 1 0 21:55 tty1 00:00:00 /sbin/agetty -o -p -- \u --noclear - linux root 1430 1 0 21:55 ttyS0 00:00:00 /sbin/agetty -o -p -- \u --keep-baud 115200,57600,38400,9600 - vt220 # Again, lines are split and condensed here only for readability.
After all this, I get no output on the putty connection and no response when attempting any entry. I've also tried the other listed baud rates.
Is there any obvious step I've missed? Is there a better way to do this?
Dave Close, Compata, Irvine CA +1 714 434 7359 dave@compata.com dhclose@alumni.caltech.edu"Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them." -- Laurence Peter
If you are having trouble reading this message, you should upgrade to an email client that can understand plain text messages. This message is not written in HTML. If you are reading it as such (eg, proportional font), the presentation is dishonest and not what the author intended.
HTML email is *inherently* insecure and should not be used, PERIOD. For example see https://lutrasecurity.com/en/articles/kobold-letters/.
-- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Wed, 2025-04-02 at 07:17 -0500, Roger Heflin wrote:
I have had my display disappear and not come back when turning on/off a monitor/tv. Sometimes on/off again works, sometimes moving the hdmi cable to another monitor port works, and sometimes I have to reboot. And in these cases the machine is still working via ssh, it seems to be some sort of issue in the video driver.
Just wondering if that's related to a problem mine had:
If my monitor loses its signal (such as because the computer going into a power save mode), the monitor would hunt between its various inputs looking for a signal, eventually giving up and going to sleep itself. It would end up parked on an un-used input, and when the computer comes back to life, never notice it.
Also, trying to get the monitor to come on with no signal present so that I could select another input was a battle of wills (my will, versus its won't).
Sodding menu-driven system with automatics designed by someone who had not thought through what they were doing!!! I miss monitors with just one input, or selector switches that directly go to the input you pick, not some stupid push once to change inputs, push the same button again to change inputs, push it again to change inputs again, with a stupidly slow update speed.
Fortunately I could turn off the input hunting feature. Now the monitor always stays on whatever input I select, and sleeps and wakes up fine.
I've had two different monitors with that annoyance.
I wrote:
I have a machine running Fedora 41 which has stopped providing video for its console. Of course, the problem could be hardware, but there is no clear evidence of that. I am able to access the machine with SSH so I know it is working. I don't find any indication of a problem in log files. To help diagnose the issue, I'd like to access its console through its serial interface. (The machine does have a DB9 serial connector and I have verified that it works properly.)
I have connected a serial to USB adapter to the machine's serial port and connected the other end of the USB cable to a laptop (also running Fedora 41). On the laptop, I've started putty and selected a serial connection to ttyUSB0 at speed 38400. On the problem machine, I've run the following commands as root with no errors reported.
# grubby \ --args="systemd.journald.forward_to_console=1 \ console=ttyS0,38400 console=tty1" --update-kernel=ALL # # The line continuation above is only for readability. # # The actual command was all one line. # grubby --set-default=/boot/vmlinuz-6.13.9-200.fc41.x86_64 # grub2-mkconfig -o /boot/grub2/grub.cfg # grub2-install /dev/sda # reboot
I then SSH into the problem machine and check for agetty.
# ps -ef | grep [g]etty root 1429 1 0 21:55 tty1 00:00:00 /sbin/agetty -o -p -- \u --noclear - linux root 1430 1 0 21:55 ttyS0 00:00:00 /sbin/agetty -o -p -- \u --keep-baud 115200,57600,38400,9600 - vt220 # Again, lines are split and condensed here only for readability.
After all this, I get no output on the putty connection and no response when attempting any entry. I've also tried the other listed baud rates.
Is there any obvious step I've missed? Is there a better way to do this?
Roger Heflin wrote:
If the machine does not crash then the serial console is not going to have any information that dmesg from ssh does not have.
The use-case for the serial console(or kdump) is when the machine stops and you can no longer see dmesg output from that boot.
Likely you will need to find the log file for the Wayland/X session and look at it.
Well, neither X nor Wayland has been started since the problem. Without a display, neither would be of much help. I realize I could try starting through SSH but haven't felt the need nor can I see the point. I can start an X application with port forwarding. Note, I do not use the "graphical" boot and start KDE from the command line.
Trying to start X through the SSH (-X) connection, I'm told, "Only console users are allowed to run the X server". Trying to start Wayland doesn't work either but produces voluminous output. If the serial connection worked, it would be a console, so maybe Wayland or X could at least try to start.
Looking through the dmesg output on the problem machine and on another machine (also Fedora 41) with the same monitor attached, I don't find any references to the monitor at all. It appears that monitor detection doesn't happen until the normal syslog process is running. I do find a reference to it in /var/log/messages, but only on the working machine. I don't find any messages indicating failure to find the monitor on the problem machine.
Of course, the motivation for trying to get the serial console working is not really the reason for my post. My reason is, why doesn't the serial console seem to work? What am I missing in the process?
I might be focusing on the serial console for Fedora when what I really need is serial console access to the BIOS boot process. That is the only way I see to boot from a USB drive (with a different system), just to see if the problem is a configuration error in Fedora. I now realize that by the time Fedora starts, that process is done. Maybe I should be asking if there is a way to get serial access before Fedora.
On 4/2/25 12:48 PM, Dave Close wrote:
Looking through the dmesg output on the problem machine and on another machine (also Fedora 41) with the same monitor attached, I don't find any references to the monitor at all. It appears that monitor detection doesn't happen until the normal syslog process is running. I do find a reference to it in /var/log/messages, but only on the working machine. I don't find any messages indicating failure to find the monitor on the problem machine.
What is the video device? "lspci" output Check "journalctl -b" for lines with "drm" or "modesetting".
Of course, the motivation for trying to get the serial console working is not really the reason for my post. My reason is, why doesn't the serial console seem to work? What am I missing in the process?
Do you see the options in /proc/cmdline after it has booted?
I might be focusing on the serial console for Fedora when what I really need is serial console access to the BIOS boot process. That is the only way I see to boot from a USB drive (with a different system), just to see if the problem is a configuration error in Fedora. I now realize that by the time Fedora starts, that process is done. Maybe I should be asking if there is a way to get serial access before Fedora.
If you aren't getting a display for the BIOS boot then your hardware is broken. Only expensive enterprise systems give you serial access to the BIOS.
Samuel Sieb wrote:
What is the video device? "lspci" output
The display does not appear in that output.
Check "journalctl -b" for lines with "drm" or "modesetting".
kernel: ACPI: bus type drm_connector registered kernel: [drm] radeon kernel modesetting enabled. kernel: [drm] initializing kernel modesetting (RV620 0x1002:0x95C5 0x1028:0x0342 0x00). kernel: [drm] Detected VRAM RAM=256M, BAR=256M kernel: [drm] RAM width 64bits DDR kernel: [drm] radeon: 256M of VRAM memory ready kernel: [drm] radeon: 512M of GTT memory ready. kernel: [drm] Loading RV620 Microcode kernel: [drm] Internal thermal controller with fan control kernel: [drm] radeon: power management initialized kernel: [drm] GART: num cpu pages 131072, num gpu pages 131072 kernel: [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 kernel: [drm] PCIE GART of 512M enabled (table at 0x0000000000142000). kernel: [drm] radeon: irq initialized. kernel: [drm] ring test on 0 succeeded in 1 usecs kernel: [drm] ring test on 5 succeeded in 1 usecs kernel: [drm] UVD initialized successfully. kernel: [drm] ib test on ring 0 succeeded in 0 usecs kernel: [drm] ib test on ring 5 succeeded kernel: [drm] Radeon Display Connectors kernel: [drm] Connector 0: kernel: [drm] DIN-1 kernel: [drm] Encoders: kernel: [drm] TV1: INTERNAL_KLDSCP_DAC2 kernel: [drm] Connector 1: kernel: [drm] DVI-I-1 kernel: [drm] HPD1 kernel: [drm] DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c kernel: [drm] Encoders: kernel: [drm] CRT1: INTERNAL_KLDSCP_DAC1 kernel: [drm] DFP2: INTERNAL_KLDSCP_LVTMA kernel: [drm] Connector 2: kernel: [drm] DVI-I-2 kernel: [drm] HPD2 kernel: [drm] DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c 0x7e2c kernel: [drm] Encoders: kernel: [drm] CRT2: INTERNAL_KLDSCP_DAC2 kernel: [drm] DFP1: INTERNAL_UNIPHY kernel: [drm] Initialized radeon 2.50.0 for 0000:01:00.0 on minor 0 kernel: radeon 0000:01:00.0: [drm] Cannot find any crtc or sizes kernel: radeon 0000:01:00.0: [drm] Cannot find any crtc or sizes kernel: radeon 0000:01:00.0: [drm] Cannot find any crtc or sizes kernel: [drm] amdgpu kernel modesetting enabled. systemd[1]: Starting modprobe@drm.service - Load Kernel Module drm... kernel: audit: type=1130 audit(1743569685.459:9): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=modprobe@drm comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=modprobe@drm comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=modprobe@drm comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' kernel: audit: type=1131 audit(1743569685.459:10): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=modprobe@drm comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' systemd[1]: modprobe@drm.service: Deactivated successfully. systemd[1]: Finished modprobe@drm.service - Load Kernel Module drm. sddm-helper-start-wayland[99236]: "No backend specified, automatically choosing drm\n" sddm-helper-start-wayland[99236]: "kwin_wayland_drm: drmSetClientCap for Atomic Mode Setting failed. Using legacy mode on GPU "/dev/dri/card0"\n"
Do you see the options in /proc/cmdline after it has booted?
Yes.
On 4/2/25 3:12 PM, Dave Close wrote:
Samuel Sieb wrote:
What is the video device? "lspci" output
The display does not appear in that output.
It must. Probably as something like "VGA compatible controller".
Check "journalctl -b" for lines with "drm" or "modesetting".
kernel: [drm] radeon kernel modesetting enabled. kernel: [drm] initializing kernel modesetting (RV620 0x1002:0x95C5 0x1028:0x0342 0x00). kernel: [drm] Detected VRAM RAM=256M, BAR=256M kernel: [drm] RAM width 64bits DDR kernel: [drm] radeon: 256M of VRAM memory ready kernel: [drm] radeon: 512M of GTT memory ready. kernel: [drm] Loading RV620 Microcode
Looks like an older AMD Radeon card.
kernel: [drm] Radeon Display Connectors kernel: [drm] Connector 0: kernel: [drm] DIN-1 kernel: [drm] Encoders: kernel: [drm] TV1: INTERNAL_KLDSCP_DAC2 kernel: [drm] Connector 1: kernel: [drm] DVI-I-1 kernel: [drm] HPD1 kernel: [drm] DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c kernel: [drm] Encoders: kernel: [drm] CRT1: INTERNAL_KLDSCP_DAC1 kernel: [drm] DFP2: INTERNAL_KLDSCP_LVTMA kernel: [drm] Connector 2: kernel: [drm] DVI-I-2 kernel: [drm] HPD2 kernel: [drm] DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c 0x7e2c kernel: [drm] Encoders: kernel: [drm] CRT2: INTERNAL_KLDSCP_DAC2 kernel: [drm] DFP1: INTERNAL_UNIPHY
Which plug is the monitor connected to?
kernel: [drm] Initialized radeon 2.50.0 for 0000:01:00.0 on minor 0 kernel: radeon 0000:01:00.0: [drm] Cannot find any crtc or sizes kernel: radeon 0000:01:00.0: [drm] Cannot find any crtc or sizes kernel: radeon 0000:01:00.0: [drm] Cannot find any crtc or sizes
This is concerning. Try re-plugging the monitor. Can you test the monitor on another computer? Do you have another monitor you can test on this computer?
sddm-helper-start-wayland[99236]: "No backend specified, automatically choosing drm\n" sddm-helper-start-wayland[99236]: "kwin_wayland_drm: drmSetClientCap for Atomic Mode Setting failed. Using legacy mode on GPU "/dev/dri/card0"\n"
Do you see sddm running?
you might try adding setterm --blank 0 --powersave no --powerdown=0
I think i have had luck with that making sure when I turn a monitor back on that the session/screen/output is there and still showing.
I think I have put this sort of stuff in rc.local before to be run at boot.
On Wed, Apr 2, 2025 at 2:48 PM Dave Close dave@compata.com wrote:
I wrote:
I have a machine running Fedora 41 which has stopped providing video for its console. Of course, the problem could be hardware, but there is no clear evidence of that. I am able to access the machine with SSH so I know it is working. I don't find any indication of a problem in log files. To help diagnose the issue, I'd like to access its console through its serial interface. (The machine does have a DB9 serial connector and I have verified that it works properly.)
I have connected a serial to USB adapter to the machine's serial port and connected the other end of the USB cable to a laptop (also running Fedora 41). On the laptop, I've started putty and selected a serial connection to ttyUSB0 at speed 38400. On the problem machine, I've run the following commands as root with no errors reported.
# grubby \ --args="systemd.journald.forward_to_console=1 \ console=ttyS0,38400 console=tty1" --update-kernel=ALL # # The line continuation above is only for readability. # # The actual command was all one line. # grubby --set-default=/boot/vmlinuz-6.13.9-200.fc41.x86_64 # grub2-mkconfig -o /boot/grub2/grub.cfg # grub2-install /dev/sda # reboot
I then SSH into the problem machine and check for agetty.
# ps -ef | grep [g]etty root 1429 1 0 21:55 tty1 00:00:00 /sbin/agetty -o -p -- \u --noclear - linux root 1430 1 0 21:55 ttyS0 00:00:00 /sbin/agetty -o -p -- \u --keep-baud 115200,57600,38400,9600 - vt220 # Again, lines are split and condensed here only for readability.
After all this, I get no output on the putty connection and no response when attempting any entry. I've also tried the other listed baud rates.
Is there any obvious step I've missed? Is there a better way to do this?
Roger Heflin wrote:
If the machine does not crash then the serial console is not going to have any information that dmesg from ssh does not have.
The use-case for the serial console(or kdump) is when the machine stops and you can no longer see dmesg output from that boot.
Likely you will need to find the log file for the Wayland/X session and look at it.
Well, neither X nor Wayland has been started since the problem. Without a display, neither would be of much help. I realize I could try starting through SSH but haven't felt the need nor can I see the point. I can start an X application with port forwarding. Note, I do not use the "graphical" boot and start KDE from the command line.
Trying to start X through the SSH (-X) connection, I'm told, "Only console users are allowed to run the X server". Trying to start Wayland doesn't work either but produces voluminous output. If the serial connection worked, it would be a console, so maybe Wayland or X could at least try to start.
Looking through the dmesg output on the problem machine and on another machine (also Fedora 41) with the same monitor attached, I don't find any references to the monitor at all. It appears that monitor detection doesn't happen until the normal syslog process is running. I do find a reference to it in /var/log/messages, but only on the working machine. I don't find any messages indicating failure to find the monitor on the problem machine.
Of course, the motivation for trying to get the serial console working is not really the reason for my post. My reason is, why doesn't the serial console seem to work? What am I missing in the process?
I might be focusing on the serial console for Fedora when what I really need is serial console access to the BIOS boot process. That is the only way I see to boot from a USB drive (with a different system), just to see if the problem is a configuration error in Fedora. I now realize that by the time Fedora starts, that process is done. Maybe I should be asking if there is a way to get serial access before Fedora. -- Dave Close, Compata, Irvine CA +1 714 434 7359 dave@compata.com dhclose@alumni.caltech.edu "A man who says, 'I have learned enough and will learn no further,' should be considered as knowing nothing at all." --Haile Selassie
-- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
And you are using ttyS0 for the serial port and that is the first real hardware serial port, not the first USB serial port and at boot the first usb serial port may not even actually exist yet...
On Wed, Apr 2, 2025 at 3:39 PM Roger Heflin rogerheflin@gmail.com wrote:
you might try adding setterm --blank 0 --powersave no --powerdown=0
I think i have had luck with that making sure when I turn a monitor back on that the session/screen/output is there and still showing.
I think I have put this sort of stuff in rc.local before to be run at boot.
On Wed, Apr 2, 2025 at 2:48 PM Dave Close dave@compata.com wrote:
I wrote:
I have a machine running Fedora 41 which has stopped providing video for its console. Of course, the problem could be hardware, but there is no clear evidence of that. I am able to access the machine with SSH so I know it is working. I don't find any indication of a problem in log files. To help diagnose the issue, I'd like to access its console through its serial interface. (The machine does have a DB9 serial connector and I have verified that it works properly.)
I have connected a serial to USB adapter to the machine's serial port and connected the other end of the USB cable to a laptop (also running Fedora 41). On the laptop, I've started putty and selected a serial connection to ttyUSB0 at speed 38400. On the problem machine, I've run the following commands as root with no errors reported.
# grubby \ --args="systemd.journald.forward_to_console=1 \ console=ttyS0,38400 console=tty1" --update-kernel=ALL # # The line continuation above is only for readability. # # The actual command was all one line. # grubby --set-default=/boot/vmlinuz-6.13.9-200.fc41.x86_64 # grub2-mkconfig -o /boot/grub2/grub.cfg # grub2-install /dev/sda # reboot
I then SSH into the problem machine and check for agetty.
# ps -ef | grep [g]etty root 1429 1 0 21:55 tty1 00:00:00 /sbin/agetty -o -p -- \u --noclear - linux root 1430 1 0 21:55 ttyS0 00:00:00 /sbin/agetty -o -p -- \u --keep-baud 115200,57600,38400,9600 - vt220 # Again, lines are split and condensed here only for readability.
After all this, I get no output on the putty connection and no response when attempting any entry. I've also tried the other listed baud rates.
Is there any obvious step I've missed? Is there a better way to do this?
Roger Heflin wrote:
If the machine does not crash then the serial console is not going to have any information that dmesg from ssh does not have.
The use-case for the serial console(or kdump) is when the machine stops and you can no longer see dmesg output from that boot.
Likely you will need to find the log file for the Wayland/X session and look at it.
Well, neither X nor Wayland has been started since the problem. Without a display, neither would be of much help. I realize I could try starting through SSH but haven't felt the need nor can I see the point. I can start an X application with port forwarding. Note, I do not use the "graphical" boot and start KDE from the command line.
Trying to start X through the SSH (-X) connection, I'm told, "Only console users are allowed to run the X server". Trying to start Wayland doesn't work either but produces voluminous output. If the serial connection worked, it would be a console, so maybe Wayland or X could at least try to start.
Looking through the dmesg output on the problem machine and on another machine (also Fedora 41) with the same monitor attached, I don't find any references to the monitor at all. It appears that monitor detection doesn't happen until the normal syslog process is running. I do find a reference to it in /var/log/messages, but only on the working machine. I don't find any messages indicating failure to find the monitor on the problem machine.
Of course, the motivation for trying to get the serial console working is not really the reason for my post. My reason is, why doesn't the serial console seem to work? What am I missing in the process?
I might be focusing on the serial console for Fedora when what I really need is serial console access to the BIOS boot process. That is the only way I see to boot from a USB drive (with a different system), just to see if the problem is a configuration error in Fedora. I now realize that by the time Fedora starts, that process is done. Maybe I should be asking if there is a way to get serial access before Fedora. -- Dave Close, Compata, Irvine CA +1 714 434 7359 dave@compata.com dhclose@alumni.caltech.edu "A man who says, 'I have learned enough and will learn no further,' should be considered as knowing nothing at all." --Haile Selassie
-- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Roger Heflin wrote:
And you are using ttyS0 for the serial port and that is the first real hardware serial port, not the first USB serial port and at boot the first usb serial port may not even actually exist yet...
The serial-to-USB adapter is attached to ttyS0 on the problem machine. The USB end of the cable is attached to ttyUSB0 on the laptop. I have tested ttyS0 by connection elsewhere using straight serial and it works as it should.
On 4/2/25 3:14 PM, Dave Close wrote:
Roger Heflin wrote:
And you are using ttyS0 for the serial port and that is the first real hardware serial port, not the first USB serial port and at boot the first usb serial port may not even actually exist yet...
The serial-to-USB adapter is attached to ttyS0 on the problem machine. The USB end of the cable is attached to ttyUSB0 on the laptop. I have tested ttyS0 by connection elsewhere using straight serial and it works as it should.
You will need a null-modem cable or adapter to connect to another computer.
Samuel Sieb wrote:
You will need a null-modem cable or adapter to connect to another computer.
Indeed. I've been working with RS232 for decades, though not much for the most recent decade. I finally cobbled together a set of DB9-DB25, gender benders, and DB25 null modem adapter to check this. As you can guess, Samuel was right. Sorry for wasting everyone's time.
On Apr 2, 2025, at 15:48, Dave Close dave@compata.com wrote:
Trying to start X through the SSH (-X) connection, I'm told, "Only console users are allowed to run the X server". Trying to start Wayland doesn't work either but produces voluminous output. If the serial connection worked, it would be a console, so maybe Wayland or X could at least try to start.
If this is the only reason why you’re trying to set up a serial console, then it won’t help. Neither X11 nor Wayland can use a serial console either. You’re better off restarting services like GDM to figure out why it isn’t able to talk to a monitor.
Wayland doesn’t have as many useful tools for querying things like monitor settings, so logs are the best place to look.
I wrote:
Trying to start X through the SSH (-X) connection, I'm told, "Only console users are allowed to run the X server". Trying to start Wayland doesn't work either but produces voluminous output. If the serial connection worked, it would be a console, so maybe Wayland or X could at least try to start.
Jonathan Billings wrote:
If this is the only reason why you’re trying to set up a serial console, then it won’t help. Neither X11 nor Wayland can use a serial console either. You’ re better off restarting services like GDM to figure out why it isn’t able to talk to a monitor.
Yes, I realized that I wouldn't get any graphic output through the serial connection. I was hoping I might see some useful error message.
The problem machine is using SDDM and GDM is not installed. I was able to start SDDM (systemctl start sddm) and no errors were reported. I don't see anything useful in the log except the service start.
On Wed, Apr 2, 2025 at 2:31 AM Dave Close dave@compata.com wrote:
I have a machine running Fedora 41 which has stopped providing video for its console. Of course, the problem could be hardware, but there is no clear evidence of that. I am able to access the machine with SSH so I know it is working. I don't find any indication of a problem in log files. To help diagnose the issue, I'd like to access its console through its serial interface. (The machine does have a DB9 serial connector and I have verified that it works properly.)
Try booting a Live USB -- if that gives graphics you know the hardware is working.
You can also run journalctl on a Live USB to view the journal on the problem system.
I'm not sure what a serial connection will provide that isn't available with ssh or using the Live USB.
-- George N. White III
"George N. White III" wrote:
Try booting a Live USB -- if that gives graphics you know the hardware is working.
Tried that. It doesn't boot. I think the BIOS on this machine requires some keyboard entry to select the USB boot. Hard to do without video.
I'm beginning to think adding a video card would be the right answer. (The current connector is on the motherboard.)
On Wed, Apr 2, 2025 at 8:24 PM Dave Close dave@compata.com wrote:
"George N. White III" wrote:
Try booting a Live USB -- if that gives graphics you know the hardware is working.
Tried that. It doesn't boot. I think the BIOS on this machine requires some keyboard entry to select the USB boot. Hard to do without video.
I'm beginning to think adding a video card would be the right answer. (The current connector is on the motherboard.)
Headless server management moved from serial terminals to ssh to web-based tools like cockpit. Here there are systems in a couple outbuildings that I manage using cockpit.
-- Dave Close, Compata, Irvine CA +1 714 434 7359 dave@compata.com dhclose@alumni.caltech.edu "Country music is just folk music for righties and folk music is country music for lefties." -- J.D. Tuccille
-- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 4/2/25 4:24 PM, Dave Close wrote:
"George N. White III" wrote:
Try booting a Live USB -- if that gives graphics you know the hardware is working.
Tried that. It doesn't boot. I think the BIOS on this machine requires some keyboard entry to select the USB boot. Hard to do without video.
If the screen doesn't come up for the BIOS, then you have a hardware problem. You didn't answer that question earlier. This serial console thing is just a pointless side track.
On Wed, Apr 2, 2025 at 7:24 PM Dave Close dave@compata.com wrote:
"George N. White III" wrote:
Try booting a Live USB -- if that gives graphics you know the hardware is working.
Tried that. It doesn't boot. I think the BIOS on this machine requires some keyboard entry to select the USB boot. Hard to do without video.
I'm beginning to think adding a video card would be the right answer. (The current connector is on the motherboard.)
Replace the coin battery on the motherboard.
My mother once had a machine running Mint Linux. It stopped booting because the battery was dead.
Jeff
On 4/2/25 8:35 PM, Jeffrey Walton wrote:
On Wed, Apr 2, 2025 at 7:24 PM Dave Close dave@compata.com wrote:
"George N. White III" wrote:
Try booting a Live USB -- if that gives graphics you know the hardware is working.
Tried that. It doesn't boot. I think the BIOS on this machine requires some keyboard entry to select the USB boot. Hard to do without video.
I'm beginning to think adding a video card would be the right answer. (The current connector is on the motherboard.)
Replace the coin battery on the motherboard.
My mother once had a machine running Mint Linux. It stopped booting because the battery was dead.
And replacing that battery normally means Bios setting back to manufacture defaults, so make sure to go through ALL the setup options.
Of course, you will have no record of what the settings were before...
Jeffrey Walton wrote:
Replace the coin battery on the motherboard.
Robert Moskowitz:
And replacing that battery normally means Bios setting back to manufacture defaults, so make sure to go through ALL the setup options.
Of course, you will have no record of what the settings were before...
If the battery has died, there's a good chance that those settings were gone a while ago, or even badly scrambled as it went flat.
I haven't found any need to change crucial settings beyond the default and automatic for a long time. Just the things that matter to me, not the PC. e.g. Boot menus and ordering. (I'll have the black ones with elastic sides.)
People go mad trying to set optimum speeds for overclocking, making their machines unstable for an attempt to get 5% faster (which is never really noticeable unless you're doing extreme number-crunching over a prolonged period).
I wrote:
I have a machine running Fedora 41 which has stopped providing video for its console. Of course, the problem could be hardware, but there is no clear evidence of that.
Well, now there is clear evidence. I followed up by putting a DVI card in the machine and, using an adapter, connecting it to the same monitor that showed nothing with the built-in VGA connection. On this connection I see video. So the machine is working, just not the VGA. I can adapt to using the DVI but I may just replace the machine anyway.
My desire for the serial connection was only to help diagnose this problem. Of course, even after getting it to work, all I learned is that the machine is fine, just not the VGA. At least, I learned a lot about serial consoles.
-
Dave Close -
George N. White III -
Jeffrey Walton -
Jonathan Billings -
Robert Moskowitz -
Roger Heflin -
Samuel Sieb -
Tim