Just now booted with splash (after a full shutdown rather than a reboot) and still everything's fine. Logged in manually on tty1, navigated between all ttys either with Ctrl+Alt+ F keys and Alt+ arrow keys (right/left) .. All fine..
Then... yes, it may be something due to Bios/Uefi ... Or at least we can say it doesn't affect the classic Bios machines, no matter it's splash or not :)
@Charlie BrownCould you test something for us. Enable splash and boot to sys-v and let us know if the tty's respond or if you also get a black screen.
Your system is the only one we know of that uses BIOS and not UEFI as the boot mode.
Just saw your post. So it does seems to be a UEFI issue. I wonder if the same thing happens to those running the latest 6.6.x kernels in MX-21 and UEFI?
This is my Fluxbox . There are many others like it, but this one is mine. My Fluxbox is my best friend. It is my life.
I must master it as I must master my life. Without me, my Fluxbox is useless. Without my Fluxbox, I am useless.
siamhie wrote: Mon Jan 01, 2024 12:18 pm
@Charlie Brown Could you test something for us. Enable splash and boot to sys-v and let us know if the tty's respond or if you also get a black screen.
Your system is the only one we know of that uses BIOS and not UEFI as the boot mode.
Just saw your post. So it does seems to be a UEFI issue. I wonder if the same thing happens to those running the latest 6.6.x kernels in MX-21 and UEFI?
Post #9
mx21 and 6.6.7 liquorix ( UEFI ) yes it happens
*QSI = Quick System Info from menu (Copy for Forum) *MXPI = MX Package Installer *Please check the solved checkbox on the post that solved it. *Linux -This is the way!
and mx21 and 6.6.7 liquorix ( MBR ) Does NOT happen
*QSI = Quick System Info from menu (Copy for Forum) *MXPI = MX Package Installer *Please check the solved checkbox on the post that solved it. *Linux -This is the way!
siamhie wrote: Mon Jan 01, 2024 12:18 pm
@Charlie Brown Could you test something for us. Enable splash and boot to sys-v and let us know if the tty's respond or if you also get a black screen.
Your system is the only one we know of that uses BIOS and not UEFI as the boot mode.
Just saw your post. So it does seems to be a UEFI issue. I wonder if the same thing happens to those running the latest 6.6.x kernels in MX-21 and UEFI?
Post #9
mx21 and 6.6.7 liquorix ( UEFI ) yes it happens
and mx21 and 6.6.7 liquorix ( MBR ) Does NOT happen
I suppose we can rule out plymouth as a possible culprit? I wonder what has changed since kernel 6.6.5 then?
The current (semi) fix is if you are using UEFI and encounter the black screen, just press enter and wait for the tty to show.
Last edited by siamhie on Mon Jan 01, 2024 6:56 pm, edited 2 times in total.
This is my Fluxbox . There are many others like it, but this one is mine. My Fluxbox is my best friend. It is my life.
I must master it as I must master my life. Without me, my Fluxbox is useless. Without my Fluxbox, I am useless.
Eadwine Rose wrote: Mon Jan 01, 2024 3:34 pm
Can you adjust that color please, it is barely readable. Thanks.
@Eadwine Rose Is that better?
(I should remember that I'm using the Dark Reader extension and have my background set to jet black)
This is my Fluxbox . There are many others like it, but this one is mine. My Fluxbox is my best friend. It is my life.
I must master it as I must master my life. Without me, my Fluxbox is useless. Without my Fluxbox, I am useless.
3.08:
Enable kexec, fix halt in some situations Latest
This release focuses on three changes which are basically imports of patches from Gentoo. Special thanks to floppym for supplying these.
Applied a patch from floppm which adds kexec option to the halt command. This can be used as "halt -k".
floppym provided patch which causes the halt command to call "shutdown -h -H" instead of "shutdown -h" when halt is invoked without parameters.
This forces the shutdown command to set the INIT_HALT variable and assume, unless other conditions apply, that the "halt" call really wants to
halt the machine and INIT_HALT should be set. In other words we assume halt wants to halt unless told otherwise.
Addresses downstream Gentoo bug ID 911257.
Updated halt documentation and help output to display parameters in alphabetical order.
3.07:
Fixes for killall5 and pidof
The 3.07 release of SysV init mostly introduces fixes and improvements for the killall5 and pidof programs. (These are actually the same program,
but are invoked with two different names, which result in different behaviour. The main highlights in this release are:
Fixed killall5 so that processes in the omit list are not sent any signals, including SIGSTOP.
Fixed usage message for killall5 to be more accurate.
pidof was not returning PIDs of programs which were launched using a symbolic link. This has been fixed so programs run from a symbolic link show up in process lists.
)