[SOLVED] how to prevent Xorg from clearing boot messages in scrollback

bdantas · 2014-07-22 14:55:32

I have an updated Arch install with MATE and LightDM. LightDM autologin is enabled, so I normally boot directly to my desktop. I like seeing the messages that flash by during boot, so I deleted the word "quiet" from the linux line in my grub.cfg. Because I want all the messages to still be there after flashing by (in case I want to scroll through them later), I followed the advice here https://wiki.archlinux.org/index.php/Di … t_messages and I also increased the scrollback buffer and enabled early KMS start.

Despite all the above, I can only scroll back to the beginning of the boot messages if I boot into non-graphical mode (e.g., by adding "systemd.unit=multi-user.target" to GRUB command line). If I allow a normal boot to my destkop and THEN go to non-graphical mode with "sudo systemctl isolate multi-user.target" to look at the boot messages, I notice that I cannot scroll back very far at all--most of the messages that flashed by during boot are gone. Therefore, it seems to me that either lightDM or Xorg is resetting the scrollback buffer and erasing all but the last few boot messages.

So, how do I tell LightDM or Xorg (whichever one is the culprit) *not* to clear the scrollback buffer, so that when I get out of graphical mode and into non-graphical mode the boot messages are all still there?

Last edited by bdantas (2014-08-01 14:19:06)

bdantas · 2014-07-22 18:16:08

Update: I think Xorg is the culprit here:

1. I boot to non-graphical mode and log in. All boot messages are there and I can scroll through them.
2. I start X directly with "startx" (thereby completely bypassing LightDM)
3. Once X is started, I kill it with "pkill X" to get back to non-graphic mode
4. Back in non-graphic mode the boot messages are gone

So now I can rephrase the question: How to prevent Xorg from resetting the framebuffer so that boot messages are not lost? I will rename the thread accordingly.

Last edited by bdantas (2014-07-22 18:21:04)

ooo · 2014-07-22 18:48:42

there should be a '-background none' command line option for Xorg, that prevents it from clearing the background on startup. I'm not sure whether it would help in this case but may be worth a shot.
For some reason I couldn't find any documentation for that option anywhere, but I know it should be there.

bdantas · 2014-07-22 18:57:56

Thanks for the suggestion, but I am not sure how to test it. I tried "startx -background none" and no joy. Ideally the fix would be an X setting that I could specify somewhere in LightDM's config files.

Last edited by bdantas (2014-07-22 18:58:23)

ukhippo · 2014-07-22 19:12:59

Are the messages you want to see not in the journal?

ooo · 2014-07-22 19:26:00

bdantas wrote:

Thanks for the suggestion, but I am not sure how to test it. I tried "startx -background none" and no joy. Ideally the fix would be an X setting that I could specify somewhere in LightDM's config files.

startx -- -background none

basically this feature was meant to be used with boot splash screens like plymouth, and it prevents X from clearing the boot splash which would otherwise cause short period of black screen. It should be implemented in gdm, not sure about lightdm.
again, it's kind of a long shot but should be easy enough to test.

bdantas · 2014-07-22 20:21:52

Thanks, ooo. I tested "startx -- -background none" but when I quit X the boot messages were gone. That doesn't seem to prevent X from flushing the framebuffer and erasing the boot messages.

ukhippo, I do use the journal and I guess I could always look through it when I see a "Failed" flash by during boot, but the problem is that I wouldn't know which message in the journal would correspond to the "Failed." For that reason, it is nice to be able to refer directly to the boot messages.

Last edited by bdantas (2014-07-22 20:27:46)

Slithery · 2014-07-22 20:35:11

bdantas wrote:

but the problem is that I wouldn't know which message in the journal would correspond to the "Failed." For that reason, it is nice to be able to refer directly to the boot messages.

systemctl --failed

bdantas · 2014-07-22 21:36:18

Thanks, slithery. That is a great workaround and easier than changing boot to non-graphical to scroll through the messages. It would stll be nice to find a way to prevent X from wiping the messages, though.

bdantas · 2014-07-23 03:20:00

It seems that this is not an easy fix, as the fbcon scrollback buffer resets when switching from one tty to another or from X to a tty. See here: http://unix.stackexchange.com/questions … ole-switch

I'm stumped (for now). I'll post any leads here. If anyone can point me in the right direction, I'd appreciate it.

bdantas · 2014-07-23 13:33:31

If I can figure out how to restore the old /var/log/boot, I'd be perfectly happy. Using syslog-ng or rsyslog would be fine if the service could be configured to only log the boot status messages but otherwise stay out of systemd journal's way.

Another option would be to dump the contents of the fbcon scrollback buffer to a file just before starting X. My eyeballs are about to fall out of their sockets from all the googling I've done trying to figure this out, but still no luck.

Edit: I found

cat /dev/vcs1 > /var/log/boot

and

setterm -dump 1 -file /var/log/boot

but these only work for what is actually on the screen when the command is run (i.e., lines in scrollback buffer do not get written to the file).

Last edited by bdantas (2014-07-23 18:26:01)

bdantas · 2014-07-24 11:39:36

Since the answer to my original question seems to be "it is not possible," I will make this my last post to prevent the thread from going off-topic.

I came up with a simple workaround that (almost) recreates the old /var/boot/log:

1) put "quiet" on grub2's kernel command line so that only* [FAIL] messages show up, so that I don't have to deal with the scrollback buffer
2) create a startup script with the following contents (script or at least the setterm command must run as root because the setterm command needs to be able to read from /dev/vcs1):

#!/bin/bash
# this script will dump the text of tty1 to /var/log/boot, with same formatting as on the screen
export TERM=xterm
setterm -dump 1 -file /var/log/boot
exit 0

* Unfortunately, even in quiet mode grub2 starts printing all the boot status messages to screen once it encounters a [FAIL]. Therefore, if the [FAIL] occurs early enough in the boot process, the beginning of the messages will scroll off the screen and the workaround won't work. I spun off my two questions related to this nuisance into their own threads:

a) How to make grub2 actually only print [FAIL] messages during boot? https://bbs.archlinux.org/viewtopic.php?id=184702
b) How to print the contents of console's scrollback buffer to a file? https://bbs.archlinux.org/viewtopic.php … 9#p1439359

I hope I can figure out how to do one of the above, because then the workaround would be perfect.

Thanks for the help, guys!

Last edited by bdantas (2014-08-15 02:16:38)

amanual · 2014-08-01 03:06:06

Hi. I'm currently using 2 patches to:
1. increase my scrollback buffer size from the max 1 mega to 4 megabytes (yep, I needed that for boot messages)
2. keep scrollback buffer persistent across console switches (even if X is started automatically, obviously)

applied & tested (so far) on kernel 3.16-rc7

1. https://github.com/emanueLczirai/coosto … size.patch
2. https://github.com/emanueLczirai/coosto … ffer.patch

Cheers,

EDIT: updated both links ~~looks like 1 hunk fails in Kconfig when both patches are applied, I'll update the above link(1) when I'm done fixing it~~

Last edited by amanual (2014-08-01 03:44:50)

bdantas · 2014-08-01 14:18:26

keep scrollback buffer persistent across console switches (even if X is started automatically, obviously)
https://github.com/emanueLczirai/coosto … ffer.patch

@amanual - I didn't realize that this feature would require such a low-level fix, but this is brilliant--exactly what I was looking for. It seems I would have to recompile the kernel with this patch, which I'm not sure I could do without mucking it up. If the patched kernel kernel is available precompiled for x86-64, I would love to get my hands on it.

Arch Linux

#1 2014-07-22 14:55:32

[SOLVED] how to prevent Xorg from clearing boot messages in scrollback

#2 2014-07-22 18:16:08

Re: [SOLVED] how to prevent Xorg from clearing boot messages in scrollback

#3 2014-07-22 18:48:42

Re: [SOLVED] how to prevent Xorg from clearing boot messages in scrollback

#4 2014-07-22 18:57:56

Re: [SOLVED] how to prevent Xorg from clearing boot messages in scrollback

#5 2014-07-22 19:12:59

Re: [SOLVED] how to prevent Xorg from clearing boot messages in scrollback

#6 2014-07-22 19:26:00

Re: [SOLVED] how to prevent Xorg from clearing boot messages in scrollback

#7 2014-07-22 20:21:52

Re: [SOLVED] how to prevent Xorg from clearing boot messages in scrollback

#8 2014-07-22 20:35:11

Re: [SOLVED] how to prevent Xorg from clearing boot messages in scrollback

#9 2014-07-22 21:36:18

Re: [SOLVED] how to prevent Xorg from clearing boot messages in scrollback

#10 2014-07-23 03:20:00

Re: [SOLVED] how to prevent Xorg from clearing boot messages in scrollback

#11 2014-07-23 13:33:31

Re: [SOLVED] how to prevent Xorg from clearing boot messages in scrollback

#12 2014-07-24 11:39:36

Re: [SOLVED] how to prevent Xorg from clearing boot messages in scrollback

#13 2014-08-01 03:06:06

Re: [SOLVED] how to prevent Xorg from clearing boot messages in scrollback

#14 2014-08-01 14:18:26

Re: [SOLVED] how to prevent Xorg from clearing boot messages in scrollback

Board footer