SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,168
Original Poster
Rep:
Year 2024, Round 02
Another batch of updates has been scheduled for release on Friday, 05 January 2024, at approximately 16:00, GMT. If no problems are found while testing the release candidates, they might be available sometime on Thursday (depending on your time zone).
The resolution of the boot screen going blank during boot up of 6.6.X kernels
was relatively simple to implement, once the cause was found.
Apparently the newer 6.6.X kernels did not recognize the following line in this
computer's /etc/lilo.conf
vga=normal
Changing to a video mode recognized by this computer resolved the issue.
vga=795
As it turns out, the screen apparently was going blank but the computer
continued to boot. This was noticed using bootlogd (see details below)
Steps to resolve this issue included determining the available video modes for this
computer.
This was done using hwinfo, which is not installed by default.
hwinfo and the libx86emu dependency was installed using sbopkg
Running
sudo hwinfo --framebuffer
listed the available modes, of which x31b was selected
Mode designations in lilo.conf are in decimal form, not hex
So x31b was converted to decimal using:
printf "%d\n" 0x31b
returning:
795
Which provided the mode designation in /etc/lilo.conf
vga=795
The original mode entry was commented out.
# vga=normal
This worked regardless of whether the kernel append had a video assignment.
For example, either:
append=" mds=full,nosmt video=1024x768@60 vt.default_utf8=0 resume=/dev/cryptvg001/swap"
or
append=" mds=full,nosmt vt.default_utf8=0 resume=/dev/cryptvg001/swap"
worked as long as the vga=795 (or other available mode) was present.
Using bootlogd to capture screen output during system boot(Thanks rworkman):
sudo touch /root/bootlog
To the beginnig of rc.S add:
/sbin/bootlogd -l /var/log/bootlog
To the end of rc.local add:
ps -ef | awk '/[b]ootlogd/{print $2}' | xargs kill
The rc.local entry is necessary to prevent capturing any further sensitive info.
Screen output of subsequent boots are appended to /var/log/bootlog.
ref: https://www.linuxquestions.org/quest...olling-642050/
There are no doubt other ways to resolve this issue, this is the most salient
for me at the moment.
I have find the same solution for an analog problem but with Slackware 15.0 and kernel 5.15 in a new install on a laptop.
With vga=normal in lilo.conf the boot sequence was flashing (go black then wake up and so on).
vga=795 resolv the problem.
So maybe the vga=normal parameter is not supported well since more time than the 6.6 kernels.
So maybe the vga=normal parameter is not supported well since more time than the 6.6 kernels.
This would be a limitation of lilo (maybe with relatively recent kernels) as the kernel documentation states:
Code:
vga= [BOOT,X86-32] Select a particular video mode
See Documentation/arch/x86/boot.rst and
Documentation/admin-guide/svga.rst.
Use vga=ask for menu.
This is actually a boot loader parameter; the value is
passed to the kernel using a special protocol
If the command line provided by the boot loader is entered by the user, the user may expect the following command line options to work. They should normally not be deleted from the kernel command line even though not all of them are actually meaningful to the kernel. Boot loader authors who need additional command line options for the boot loader itself should get them registered in The kernel's command-line parameters to make sure they will not conflict with actual kernel options now or in the future.
vga=<mode>
<mode> here is either an integer (in C notation, either decimal, octal, or hexadecimal) or one of the strings "normal" (meaning 0xFFFF), "ext" (meaning 0xFFFE) or "ask" (meaning 0xFFFD). This value should be entered into the vid_mode field, as it is used by the kernel before the command line is parsed.
Last edited by Didier Spaier; 01-05-2024 at 11:50 AM.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,168
Original Poster
Rep:
Year 2024, Round 03
Another batch of updates has been scheduled for release on Sunday, 07 January 2024, at approximately 14:00, GMT. If no problems are found while testing the release candidates, they might be available sometime on Saturday (depending on your time zone).
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,168
Original Poster
Rep:
IIRC, they have done it before, that is, a kernel released at the end of the year or very early in the following year, has been designated LTS.
The new 6.7.0 kernel has been installed on this box and only has been running for a few minutes, but so far, so good.
Last edited by cwizardone; 01-07-2024 at 04:32 PM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
