Screen clear during the boot process (openrc)

apurkrt

Hi, I like to see the boot process in its "full glory", so I added "--noclear" after agetty on tty1 in /etc/inittab (and I do not use login manager). But something still clears the screen roughly half way through the boot. "/run/lock: correcting owner" is the first message after the clear. Anybody knows what is causing the clear? "grep clear *" in /etc/init.d came up dry.

eccerr0r · Posted: Wed Nov 13, 2019 2:55 pm Post subject:

Depending on how your kernel is set up, it could be when boot changes video modes?
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

apurkrt · Posted: Wed Nov 13, 2019 6:34 pm Post subject:

No, definitely not video mode change. I see all the kernel messages, then about half of the messages of rc init scripts, then clear screen, then the other half.

NeddySeagoon · Posted: Wed Nov 13, 2019 7:01 pm Post subject:

apurkrt,

It could be the kernel changing console drivers.
Even at the same mode, the driver change would clear the screen.
The two drivers may not even use the same memory region for the pixel buffers.

Care to share your dmesg and kernel .config via pastebin?
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

apurkrt · Posted: Thu Nov 14, 2019 6:53 am Post subject:

It might be caused by the i915 module; I booted the kernel with "init=/bin/bash", tried "modprobe i915" and it scrolled half the screen and the scrollback buffer is lost (which is actually what I am after - to be able to easily see all the boot messages).

eccerr0r · Posted: Thu Nov 14, 2019 12:16 pm Post subject:

...which is exactly that, a video mode change.

Even if you mark the i915 kms driver as 'Y' (builtin) the mode change during boot when the driver kicks in will still happen but earlier during boot, so you should get more of the scrollback before it gets lost. You will not get everything back until initial boot unless if it's possible to go back to usermode setting and the kernel never mucks with the mode and hence loses scrollback, like Linux more than a decade ago...

setting no graphics driver at all is one way to emulate what it was like in the past, but then X won't work anymore.

Is there a specific goal here or just reminiscing of the past?
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

NeddySeagoon · Posted: Thu Nov 14, 2019 7:29 pm Post subject:

apurkrt,

If its just for debug, you could try simplefb and turn off i915.
Xorg will be slow, you need fbdev, so switch back once your debug is complete.
This way, the CPU plots every pixel, as with the original Hercules graphics card.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

mvaterlaus · Posted: Fri Nov 15, 2019 3:52 pm Post subject:

apurkrt,

you could also enable rc logging in /etc/rc.conf. You have the messages of init in /var/log/rc.log and the kernel messages in /var/log/dmesg

apurkrt · Posted: Sat Nov 16, 2019 5:33 pm Post subject:

mvaterlaus: Thank you. I knew about rc logger, yet somehow I do not want to start extra daemon just for logging - I would prefer to be simply able to scrollback the console.
NeddySeagoon: Thank you as well.
eccerr0r: The goal is the easy reading of the (error) messages during the boot.

Here's what I did before I found "--noclear" option of agetty (which at least enables to show half of the bootup message) - I recorded the bootup process with my mobile phone, then reexamined frame-by-frame what went wrong. Then, after I found the --noclear, I thought - let's have the boot process scrollback-able as much as possible. But I can understand that the video mode change may make this (alas) impossible.

apurkrt · Posted: Sat Nov 16, 2019 5:41 pm Post subject:

Now I compiled the i915 (and drm) into the kernel (not as a module), and I can scrollback all the messages of rc scripts (yay!). Most of the kernel messages is lost, but I can read those with dmesg. Thank you all!