Welcome!
Forum users

Current releases
--MX-23 release info here
--Migration information to MX-23 here
--antiX-23.1 (Arditi del Popolo) release info here

Important information
--If in starting your system it boots to an unwanted Desktop, right click desktop, then select leave and logout. At the
login screen there is a session chooser at the top of the screen.

News
-- MX Linux on social media: here
-- New Forum Features, Marking Solved and Referencing a User: here

antiX-17 finally installed on P-III after a year!

Post Reply
Message
Author
User avatar
seaken64
Posts: 819
Joined: Wed Jan 02, 2019 2:43 pm

antiX-17 finally installed on P-III after a year!

#1 Post by seaken64 »

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
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

User avatar
seaken64
Posts: 819
Joined: Wed Jan 02, 2019 2:43 pm

Re: antiX-17 finally installed on P-III after a year!

#2 Post by seaken64 »

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
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

User avatar
BitJam
Developer
Posts: 2283
Joined: Sat Aug 22, 2009 11:36 pm

Re: antiX-17 finally installed on P-III after a year!

#3 Post by BitJam »

Thanks for the info Seaken64! Kudos for you success!
seaken64 wrote: Mon Jan 21, 2019 12:24 amSo, the answer turned out to be these cheat codes for the boot line and blacklisting the nvidiafb and rivafb modules.
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

User avatar
seaken64
Posts: 819
Joined: Wed Jan 02, 2019 2:43 pm

Re: antiX-17 finally installed on P-III after a year!

#4 Post by seaken64 »

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
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

User avatar
BitJam
Developer
Posts: 2283
Joined: Sat Aug 22, 2009 11:36 pm

Re: antiX-17 finally installed on P-III after a year!

#5 Post by BitJam »

seaken64 wrote: Mon Jan 21, 2019 1:04 am Thank you for your encouragement BitJam. I had nearly given up on ever getting this done. Thanks for your help.
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!
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?
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:

Code: Select all

grep -h "^\s*blacklist" /etc/modprobe.d/*.conf 
Where is this data coming from that the kernel uses?
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.

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
As part of the process of making a kernel package or installing a kernel the "depmod" program is run. Basically, this creates two files under /lib/modules/$KERNEL_VERSION/ called modules.alias and modules.dep. It also makes binary versions now but those first two files can be read by humans. The modules.dep file tells you additional modules need to be added if you want to install a given module. The "dep" stands for dependency. For example the user "ada" could not boot into their installed MX system recently because there was a bug in the kernel and the "vmd" module was needed to access their NVMe device that they installed on. The update-initramfs program correctly loaded the nvme module and "all" of its dependencies into the initramfs but did the kernel did not not include the "vmd" module as a dependency so ada could not boot their installed system! For now we will include this module "manually" so others don't have the same problem.

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
If I use 'wc" (word count) instead of "head" (print the first 10 lines) I see there are 134 such aliases on my system. Just like modules can be loaded by name, and dependencies can be automatically loaded (using the modules.dep file), modules can also be loaded by alias instead of name using the modules.alias file.

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
This basically says to find all the modalias files on your system and load the modules for them if those modules exist.

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

User avatar
seaken64
Posts: 819
Joined: Wed Jan 02, 2019 2:43 pm

Re: antiX-17 finally installed on P-III after a year!

#6 Post by seaken64 »

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
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

Post Reply

Return to “antiX”