I have an old Pentium-III that I nurse along to see if I can keep it working with a modern OS and software, as a hobby project. About a year ago I tried to install antiX-17 on this P-III but I could not get the installer to work correctly without choosing failsafe mode and I could not figure out how to properly install the correct video drivers. I had a couple of threads on the antiX forum and was getting some help and encouragement from several antiX forum members. But I was not smart enough yet about how linux works to find a solution. Those threads can be found here:
https://www.antixforum.com/forums/topic ... -on-fstab/
https://www.antixforum.com/forums/topic ... an-in-v17/
But I finally had a breakthrough after getting some additional tips here in the MX forum. Thank you to everyone at antiX forum and the MX forum who helped with suggestions and tips. Here's what worked for me to get antiX-17 on this old P-III:
The P-III does not boot from USB so I used a Live DVD. I loaded the Live DVD and at the live boot screen I selected F7 and made sure it was set to "default". Then I entered two "cheat codes" on the boot line as follows:
xorg=nouveau bp=b9
Then I hit enter to continue the boot. After awhile I got a bash shell and I entered "modprobe nouveau" and hit enter. The I used "ctrl-d" to continue the boot process.
Eventually the live desktop came on screen. I checked inxi and lsmod and the nouveau module was loaded correctly. I proceeded to run the Install program and installed antiX-17 to the hard drive.
[I noted that these cheat codes seemed to allow the live system to boot and the install routine to run normally, whereas on previous attempts the boot from DVD stalled and I could not get the install routine to work]
After I booted into the newly installed system the X did not start. I got a text login prompt. I logged in and looked at inxi and lsmod. The nouveau driver was installed but so was nvidiafb and rivafb. I chose to blacklist nvidiafb and rivafb in the /etc/modprobe.d/ directory. Then I rebooted. Upon reboot the X desktop came up normally.
I again checked inxi, lsmod and xorg. Everything looked good for the nouveau drivers. I tested a YouTube video and it ran fine at 360p, not choppy or out of sync like before. It works!
So, the answer turned out to be these cheat codes for the boot line and blacklisting the nvidiafb and rivafb modules.
I'm amazed at how well antiX-17 runs on this old kit. Here we are in 2019 and I can still watch YouTube on an Pentium-III with 512 MB RAM. Thank you antiX!
Seaken64
antiX-17 finally installed on P-III after a year!
antiX-17 finally installed on P-III after a year!
MX21-64 XFCE & W11 on Lenovo 330S LT. MX21-KDE & MX21-XFCE on Live USB.
MX18-64 & W7, Fedora on HP Core2 DT
MX21-32 XFCE w/ MX-Fluxbox on P4HT DT w/ antiX21, SUSE Tumbleweed, Q4OS, WXP
antiX21 on Compaq PIII 1 Ghz DT, w/ Debian, MX18FB, W2K
MX18-64 & W7, Fedora on HP Core2 DT
MX21-32 XFCE w/ MX-Fluxbox on P4HT DT w/ antiX21, SUSE Tumbleweed, Q4OS, WXP
antiX21 on Compaq PIII 1 Ghz DT, w/ Debian, MX18FB, W2K
Re: antiX-17 finally installed on P-III after a year!
Here's a question for the guru's here on this subject of cheat codes -
How will a newbie to Linux, such as myself, know about such a device as cheat codes to help overcome boot failures and install failures? The general advice I see all the time on other sites is to try some other distro. If it doesn't work try some other distro and keep trying until you find a distro that works for your hardware.
Is there a book of these cheat codes? Or is this unique to each distribution and the developers who set things up? Were these cheat codes that BitJam shared with me only for MX? or is there a general database of these types of things in use in Linux in general?
Just wondering how this works as I try to learn the in's and outs of installing linux on old computers.
Thanks,
Seaken64
How will a newbie to Linux, such as myself, know about such a device as cheat codes to help overcome boot failures and install failures? The general advice I see all the time on other sites is to try some other distro. If it doesn't work try some other distro and keep trying until you find a distro that works for your hardware.
Is there a book of these cheat codes? Or is this unique to each distribution and the developers who set things up? Were these cheat codes that BitJam shared with me only for MX? or is there a general database of these types of things in use in Linux in general?
Just wondering how this works as I try to learn the in's and outs of installing linux on old computers.
Thanks,
Seaken64
MX21-64 XFCE & W11 on Lenovo 330S LT. MX21-KDE & MX21-XFCE on Live USB.
MX18-64 & W7, Fedora on HP Core2 DT
MX21-32 XFCE w/ MX-Fluxbox on P4HT DT w/ antiX21, SUSE Tumbleweed, Q4OS, WXP
antiX21 on Compaq PIII 1 Ghz DT, w/ Debian, MX18FB, W2K
MX18-64 & W7, Fedora on HP Core2 DT
MX21-32 XFCE w/ MX-Fluxbox on P4HT DT w/ antiX21, SUSE Tumbleweed, Q4OS, WXP
antiX21 on Compaq PIII 1 Ghz DT, w/ Debian, MX18FB, W2K
Re: antiX-17 finally installed on P-III after a year!
Thanks for the info Seaken64! Kudos for you success!
For antiX kernels we used to disable all the hardware specific *fb modules in the kernel config. IMO we should at least blacklist them all by default. Including those modules and not blacklisting them caused needless confusion and difficulty.
"The first principle is that you must not fool yourself -- and you are the easiest person to fool."
-- Richard Feynman
-- Richard Feynman
Re: antiX-17 finally installed on P-III after a year!
Thank you for your encouragement BitJam. I had nearly given up on ever getting this done. Thanks for your help.
So what is exactly happening when we blacklist something? Is it that the kernel wants to use a particular driver by default and we want to force the kernel to choose something else? Where is this data coming from that the kernel uses? Is it compiled into the kernel by the developer? So you, as the developer can choose the drivers for each piece of hardware by default at time of compiling? So the blacklist allows us to override the defaults? I've only got a cloudy picture of how drivers are integrated into the kernel.
Seaken64
So what is exactly happening when we blacklist something? Is it that the kernel wants to use a particular driver by default and we want to force the kernel to choose something else? Where is this data coming from that the kernel uses? Is it compiled into the kernel by the developer? So you, as the developer can choose the drivers for each piece of hardware by default at time of compiling? So the blacklist allows us to override the defaults? I've only got a cloudy picture of how drivers are integrated into the kernel.
Seaken64
MX21-64 XFCE & W11 on Lenovo 330S LT. MX21-KDE & MX21-XFCE on Live USB.
MX18-64 & W7, Fedora on HP Core2 DT
MX21-32 XFCE w/ MX-Fluxbox on P4HT DT w/ antiX21, SUSE Tumbleweed, Q4OS, WXP
antiX21 on Compaq PIII 1 Ghz DT, w/ Debian, MX18FB, W2K
MX18-64 & W7, Fedora on HP Core2 DT
MX21-32 XFCE w/ MX-Fluxbox on P4HT DT w/ antiX21, SUSE Tumbleweed, Q4OS, WXP
antiX21 on Compaq PIII 1 Ghz DT, w/ Debian, MX18FB, W2K
Re: antiX-17 finally installed on P-III after a year!
You are very welcome! I'm sorry it was so difficult but users like you who persevere help us improve the system. Thank you for you help!
Yes. You normally load modules with the modprobe command. This command has a "-b" option which tells it to respect blacklisting and not load a module if it is blacklisted. You can see the modules that are blacklisted on your system with:So what is exactly happening when we blacklist something? Is it that the kernel wants to use a particular driver by default and we want to force the kernel to choose something else?
Code: Select all
grep -h "^\s*blacklist" /etc/modprobe.d/*.conf
This is a very good question. The information comes from two places: the modules themselves and the /sys/devices/ directory which is magically created and updated by the kernel to interface with hardware. This is a virtual filesystem. It doesn't really exist in a sense. It is just a way for the kernel to both answer questions and tell you which questions to ask.Where is this data coming from that the kernel uses?
The person who compiles the kernel decides which modules are compiled in, which are compiled as a separate modules (this is what we are talking about), and which are simply not included. This is done with the kernel config file. A copy of it is available at /boot/config-*. All of the loadable modules for a given kernel are under the directory /lib/modules/$KERNEL_VERSION. You can see some of them and count them with these commands:
Code: Select all
find /lib/modules -name "*.ko" -printf "%f\n" | head
find /lib/modules -name "*.ko" | wc -l
The mod.alias file does the same thing but with hardware. When hardware is detected at boot time or is added to the system, information about that hardware magically shows up under the /sys/devices directory. The information to find the needed module is in a "modalias" file. You can see the content of some of these with the command:
Code: Select all
find /sys/devices/ -name modalias -print0 | xargs -0 cat | head
I've already shown you how to print all of the hardware aliases for your system. For simple systems, you just need to send all of those aliases to the modprobe command to load all of the modules that are needed for your hardware (that are available). Since the modules.dep and modules.alias files are created from the existing modules, they will only try to look for and load existing modules. So for simple systems, this command (don't try this at home) will load all of the hardware related modules for you system:
Code: Select all
find /sys/devices -name modalias -print0 | xargs -0 sort -u | xargs modprobe -a -q -b 2>/dev/null
If the modprobe command above did not have "-b" then it would not respect blacklisting.
But things are a little more complicated than this so now we have udev and that led to systemd. I remember a few years back when udev would not respect blacklisting for certain modules. That was not fun. That was way too Microsofty for me.
If you want homework you could use the "man" command to look up the commands used above and find out what the options I used do and then try to figure out why I used them. You can explore experimentally by piping commands to "head" or "less" to see what is going on without endlessly scrolling text. As long as you do it as a normal user and don't use "sudo" then you should be safe. If you want to be really safe then do it on a live system.
I think all of these commands are available in the live initrd so you could boot live with "bp=3" and in a second or less have a simple system to play around with. Try space-evaders (it has many options). Or tao. There are usually fewer options in the initrd version of commands and no "man" command. But you can find out briefly about options with the --help option.
"The first principle is that you must not fool yourself -- and you are the easiest person to fool."
-- Richard Feynman
-- Richard Feynman
Re: antiX-17 finally installed on P-III after a year!
Thank you BitJam, that was fantastic information. I learned more about the kernel in this one post than I knew in years of using Linux.
Thanks again,
Seaken64
Thanks again,
Seaken64
MX21-64 XFCE & W11 on Lenovo 330S LT. MX21-KDE & MX21-XFCE on Live USB.
MX18-64 & W7, Fedora on HP Core2 DT
MX21-32 XFCE w/ MX-Fluxbox on P4HT DT w/ antiX21, SUSE Tumbleweed, Q4OS, WXP
antiX21 on Compaq PIII 1 Ghz DT, w/ Debian, MX18FB, W2K
MX18-64 & W7, Fedora on HP Core2 DT
MX21-32 XFCE w/ MX-Fluxbox on P4HT DT w/ antiX21, SUSE Tumbleweed, Q4OS, WXP
antiX21 on Compaq PIII 1 Ghz DT, w/ Debian, MX18FB, W2K