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.
It's certainly nothing to do with lilo. This has to be a kernel issue. I looked up GMBUS and found this. You seem to have a rather unusual video bus. And it looks like the kernel drm driver doesn't like it.
Would you think there is a kernel mod to fix this? I wonder if when I installed the new kernel, it unloaded the mods being used?
Would you think there is a kernel mod to fix this? I wonder if when I installed the new kernel, it unloaded the mods being used?
This is one of those occasions whereby uploading your computer info to https://linux-hardware.org/ would probably be a big help, since it would tell you where the incompatibilities were with all your hardware and it will offer fixes where available.
You could do all this at the command line [i.e. downloading hw-probe and its depends, making the package, installing it and uploading your info], as long as you are able to get to work in the command line once your computer has booted and you can connect to your network.
To make it easier, I've uploaded my own Slackware-compatible binary, so all you would have to do would be
I do not think it is a kernel issue.
I looked up "[drm] GMBUS [i915 gmbus dpd] timed out, falling back to bit banging" and found this.
Quote:
[ 29.862689] NET: Registered protocol family 10
[ 36.586965] wlan0: authenticate with 60:38:e0:db:ad:7a
[ 36.623144] wlan0: send auth to 60:38:e0:db:ad:7a (try 1/3)
[ 36.646214] wlan0: authenticated
[ 36.647322] wlan0: associate with 60:38:e0:db:ad:7a (try 1/3)
[ 36.676289] wlan0: RX AssocResp from 60:38:e0:db:ad:7a (capab=0x411 status=0 aid=7)
[ 36.676460] wlan0: associated`
This shows that your wireless device has been connected. This suggests that /etc/rc.d/rc.M is running. After networking is started, /etc/rc.d/rc.inet2 is run, which tries to start NFS. The OP mentions a main machine. Perhaps there is an issue with NFS. If you can SSH in, and /etc/rc.nfsd and /etc/rc.d/rc.rpc are executable, then I suggest chmod -x both those files and rebooting.
I do not think it is a kernel issue.
I looked up "[drm] GMBUS [i915 gmbus dpd] timed out, falling back to bit banging" and found this.
This shows that your wireless device has been connected. This suggests that /etc/rc.d/rc.M is running. After networking is started, /etc/rc.d/rc.inet2 is run, which tries to start NFS. The OP mentions a main machine. Perhaps there is an issue with NFS. If you can SSH in, and /etc/rc.nfsd and /etc/rc.d/rc.rpc are executable, then I suggest chmod -x both those files and rebooting.
Okay, so would it be bad if there is no `/etc/rc.nfsd` file?
If you can SSH in, then the sshd daemon has been started. The nfsd daemon is started after that. If you have been using NFS with NFS mounts specified in /etc/fstab, but there is no /etc/rc.nfsd script, then yes, bad.
Is there any chance your machine is booting into runlevel 4 and X is hanging there with a black screen? Maybe do a quick check of /etc/inittab for the line:
Code:
# Default runlevel. (Do not set to 0 or 6)
id:3:initdefault:
If its set to 4, you could change it back to 3 and try a reboot. Not sure if this was suggested yet.
This is one of those occasions whereby uploading your computer info to https://linux-hardware.org/ would probably be a big help, since it would tell you where the incompatibilities were with all your hardware and it will offer fixes where available.
You could do all this at the command line [i.e. downloading hw-probe and its depends, making the package, installing it and uploading your info], as long as you are able to get to work in the command line once your computer has booted and you can connect to your network.
To make it easier, I've uploaded my own Slackware-compatible binary, so all you would have to do would be
to get it, and then just install it and run the commands as given on the website.
EDIT: You may need hwinfo/libx86emu from SBo too.
I get "File format not recognized" and "corrupt archive" errors from that file you linked. I just got it from the github source instead and can confirm you need the hwinfo/libx86emu deps to make it work.
Nothing extraordinary in your kernel log and I believe it's worth trying to disable the framebuffer console.
Either try what enorbet suggested in #7:
- in /etc/lilo.conf modify the append line and add nomodeset:
Code:
append="vt.default_utf8=0 nomodeset"
- then, as root, run /sbin/lilo to update the bootloader
- & restart the system
Or, provide the i915 driver the modeset=0 parameter:
- create /etc/modprobe.d/i915.conf with the following content:
Code:
options i915 modeset=0
- & restart the system
So I tried both options here and it didn't change anything. I really want to fix this before I decide to just reinstall from the USB drive I have. I'm installing hw-probe and all that, just in case.
One thing though... when I run /sbin/lilo it returns saying there was one warning. Do you know where those warnings are stored? Maybe that is a clue?
Sorry to hear that the nomodeset workaround didn't work.
AFAIK, lilo warnings are only displayed and not stored, you should pay attention to them. You can reissue /sbin/lilo any times you like and focus on the warning.
If you want the older Slackware 14.2 kernel, the one you said it worked before, you don't need to reinstall the whole system. Just grab the kernel and the kernel modules from here (get the kernel-huge-smp-* and kernel-modules-smp-*): https://mirror.de.leaseweb.net/slack...2/slackware/a/
(or any other mirror you prefer)
Install them and modify your lilo.conf to point to the old kernel.
FWIW Lilo is pretty picky. It will generally fail even on fairly non serious errors. Warnings like "LBA32 is assumed" are generally inconsequential but easily solved. AFAIK they are not stored so just run /sbin/lilo again if you miss any for any reason.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.