3

I'm using a small display with a resolution of 480x800 pixel. When I boot my raspberry-pi-system, using Ubuntu server 20.04.2 LTS, the systemd-boot-messages are shortened and thus unreadable on my small display .

What I've also observed is the fact that the systemd-boot-messages are only written in one single line. Meaning, if the message is longer, no new-line is used. Another thing is, the systemd-boot-messages don't use the entire space of my display, even if they could do so.

My question, is it possible to enable some kind of verbose mode? So that the entire message is displayed, while booting, even with use of new-lines?

Here a picture: https://i.postimg.cc/9QNd9Hkw/20210421-114747.jpg

paladin
  • 506
  • I haven't tried this: https://wiki.ubuntu.com/DebuggingKernelBoot basically it says to edit grub boot command and use gfxmode text – WinEunuuchs2Unix Apr 26 '21 at 10:39
  • @WinEunuuchs2Unix My system doesn't use grub. If I only would know which subroutine/program is called for printing out the systemd-boot-messages, I would be able to modify it by myself. – paladin Apr 26 '21 at 13:13
  • The easiest solution could be plugging an HDMI tv into it. – WinEunuuchs2Unix Apr 26 '21 at 15:04
  • @WinEunuuchs2Unix I wouldn't call "Buy additional hardware to solve this problem." as the easiest solution for a text formatting problem ;-) PS the use of an HDMI display is not desired. – paladin Apr 27 '21 at 05:51
  • I think you asked the wrong question. The main problem was the 5 minute timeout, not the message truncation. The full message will be a start job is running for raise network interfaces. Therefore the question becomes why is there a network config problem similar to, but maybe not the same as https://askubuntu.com/questions/773973/ubuntu-16-04-system-boot-waits-saying-raise-network-interfaces or https://askubuntu.com/questions/862176/how-to-fix-a-start-job-is-running-for-the-raise-network-in-ubuntu-server-16. Can you log in by SSH a minute after that 5 minute timeout completes? – Martin Thornton Apr 27 '21 at 14:03
  • @MartinThornton No, my question is like I've already stated above. I created the error by myself to illustrate why it's important to see what error occurs. – paladin Apr 27 '21 at 21:36
  • A pending timeout is not yet an error, and it needs to be on one line to be easily continuously updated. Timeouts can be made quicker. What do you see after the timeout ends? Any [FAILED] message will have a second line which begins at column 1 with the message See 'systemctl status xxxxxx.service' for details.(there's no more detail than that). Is this line full-width like the pending timeout line, or as short as the rest? – Martin Thornton Apr 28 '21 at 12:16
  • @MartinThornton You don't understand, my only problem is that the boot messages of systemd are not shown in their full length, but they are shortened so much, because the display is too small, that they become unreadable. My only goal here is, that the systemd boot messages are shown in their full length, without any shortening/truncating. I'm really not interested in any kind of "Use command X to show logfile Y.". Thank you anyway ;-) – paladin Apr 28 '21 at 14:01

2 Answers2

1

EDIT 2

Perhaps LineMax= parameter in journal configuration can force line breaks that are reflected during the boot process itself (source). I did not try that. "Note that values below 79 are not accepted and will be bumped to 79." (I am not sure this suits you).


EDIT

By default, journalctl truncates lines longer than screen width, but in some cases, it may be better to enable wrapping instead of truncating. This can be controlled by the SYSTEMD_LESS environment variable, which contains options passed to less (the default pager) and defaults to FRSXMK (see less(1) and journalctl(1) for details).

By omitting the S option, the output will be wrapped instead of truncated. For example, start journalctl as follows:

$ SYSTEMD_LESS=FRXMK journalctl

To set this behaviour as default, export the variable from ~/.bashrc or ~/.zshrc.

(source).


With journalctl you can view system logs (albeit after, not during, boot).

Use journalctl --list-boots to see details on recorded boots, including hashes/boot ID (you should have enabled the persistent storage of log messages).

Then use journalctl /usr/lib/systemd/systemd -b <boot ID> to view system log for a specific boot process (or the current one if boot ID is omitted). You can also use -1 e.g. instead of the boot ID, to see the previous boot.

While viewing a log, you can use left and right arrows to view complete lines.

Also, sudo less -R /var/log/boot.log.1, or other log files.

Is that enough for you?

Related

  1. https://freedesktop.org/wiki/Software/systemd/Debugging/
  2. https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to-view-and-manipulate-systemd-logs
  3. https://unix.stackexchange.com/questions/229188/journalctl-how-to-prevent-text-from-truncating-in-terminal
  • Thanks for trying to help, but my problem is not created by a bug, but a "feature". ^^ Journalctl doesn't show any error/bug regarding this case. PS I'm just talking about the systemd-boot-messages not shown in full length. – paladin Apr 26 '21 at 10:16
  • @paladin - I know. I mean you to use journalctl not to report any error in the way messages are displayed, but to see the complete messages you want to see (albeit after, not during, boot). Please just try what I suggested. – sancho.s ReinstateMonicaCellio Apr 26 '21 at 10:21
  • But I need to see them during boot, not after, because, when an error occurs, I can't login via SSH and the user needs to report the error via telephone. – paladin Apr 26 '21 at 10:22
  • Here's a link for your blank #3 source: https://unix.stackexchange.com/questions/229188/journalctl-how-to-prevent-text-from-truncating-in-terminal – WinEunuuchs2Unix Apr 26 '21 at 10:28
  • 1
    @WinEunuuchs2Unix - Added... the 3. was a leftover of using Shift+Enter in numbered list ;-) – sancho.s ReinstateMonicaCellio Apr 26 '21 at 10:31
  • @paladin - One workaround is to setup a brief instructive for the users on how to access logs after boot. See also the two EDITs. – sancho.s ReinstateMonicaCellio Apr 26 '21 at 10:56
  • @sancho.sReinstateMonicaCellio For the application it's not desired to have the user to do any IT related stuff, besides maybe reading the last message of the boot-log shown on the attached display. This is because the user has no idea how to use a computer and thus it's generally not acceptable to let the user have any kind of "deep" system interaction. – paladin Apr 27 '21 at 05:56
  • @paladin - Ok. What about EDIT 2? I am not sure it can change anything at boot time though. You might need a wider display. – sancho.s ReinstateMonicaCellio Apr 27 '21 at 11:29
  • @sancho.sReinstateMonicaCellio Thank you for your help, but unfortunately all your answers are off topic. – paladin May 11 '21 at 09:13
1

Those shortened messages are just stock descriptions. You might want the opposite of a verbose mode. The documentation suggests a possibility.

StatusUnitFormat=

Takes either name or description as the value. If name, the system manager will use unit names in status messages, instead of the longer and more informative descriptions set with Description=, see systemd.unit(5).

Hopefully the unit names will be short enough to avoid truncation. And even if truncated, the partial name will be easier to match to a known list of units from /lib/systemd/system/ and /etc/systemd/system/.

To choose this, in the file /etc/systemd/system.conf, after the line

#StatusUnitFormat=description

which documents the default setting, add the line

StatusUnitFormat=name
  • Your idea was good, I implemented it onto my system. Unfortunately a pending timeout error (and probably every other serious error) like shown in my picture "A start job is running fo..." keeps being truncated, so that's mostly unreadable. Unfortunately it may not be possible to halt the system on an error. So I really dependent on that "pending timeout error", to allow the user to report the error via telephone. (Maybe I must rethink the system design, to enable an halt on all service errors, but this creates new problems.) – paladin Apr 27 '21 at 09:33