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.
Of course, you do realise that the Slackware installer is nothing more than a big initrd? This means that you're using an initrd before you even start using Slackware!
Using an initrd during installation makes totally sense. This is the way it has been since the days the installation was started using a kernel floppy and a root image floppy.
Speaking about installation... It might also be worth noting that there are only huge kernels to choose from during installation.
In my experience, booting the installation media you will need to wait longer to load the compressed initrd than to load the compressed huge kernel. This makes sense considering that the installation compressed initrd is about 5 times as big as the compressed huge kernel.
To avoid some complexity and to get portable installations I am one of those who use a huge kernel on the installed system without any initrd.
Using an initrd during installation makes totally sense. This is the way it has been since the days the installation was started using a kernel floppy and a root image floppy.
Speaking about installation... It might also be worth noting that there are only huge kernels to choose from during installation.
In my experience, booting the installation media you will need to wait longer to load the compressed initrd than to load the compressed huge kernel. This makes sense considering that the installation compressed initrd is about 5 times as big as the compressed huge kernel.
Would you be kind enough to give me a single reason why a generic kernel can't be used for the Slackware installer?
All other big Linux distributions use a generic kernel and their installers are graphical. So they are much more complicated.
In fact, the huge kernels are needed for only one purpose. To be a "rescue" for some of Slackware's traditional boot failures. Which are specific to Slackware, because it insists on using boot management in questionable ways, such as introducing the human factor in a kernel upgrade.
Just as well, for these rescue boot purposes, the Slackware ISO can use a second initrd similar to the one generated in the system, which contains all modules for filesystems. The result would be equal.
Quote:
Originally Posted by henca
To avoid some complexity and to get portable installations I am one of those who use a huge kernel on the installed system without any initrd.
regards Henrik
If one wants to use a "portable install" then using initrd is a must. To use UUIDs, which allow the system to boot into any computer, it doesn't matter how many hard drives are present. I speak from my own experience, because for several years I've been using an SD-card mounted in a USB 3.0 adapter, and it still works.
In fact, this "necessity" of huge kernel is a result of some questionable practices in boot management in Slackware.
What these questionable practices are is known, the solutions to eliminate them are also known, but unfortunately it seems that in this forum there are people who do not accept that Slackware can make mistakes. It's like the Bible for them.
And look like this, those who dare to show what these questionable practices of Slackware are, they are invited to leave. Even if people leave, Slackware's problems will not be fixed. They have never been fixed in this way even for countries.
Once Slackware was famous for "legendary stability", today it is famous for "legendary boot failures". If that's what you want, it's your business.
Last edited by ZhaoLin1457; 09-08-2023 at 01:56 AM.
Once Slackware was famous for "legendary stability", today it is famous for "legendary boot failures". If that's what you want, it's your business.
Are you actually running the Slackware 15.0? and are you actually experiencing ANY boot failures? I have experienced rare boot failures on systemd distros but I don't even recall the last boot failure on any version of Slackware that I didn't cause by toying around.
Are you actually running the Slackware 15.0? and are you actually experiencing ANY boot failures? I have experienced rare boot failures on systemd distros but I don't even recall the last boot failure on any version of Slackware that I didn't cause by toying around.
No, I personally did not have any boot failure in Slackware 15.0 because I already learned to use a script that installs the newest generic kernel, generates the associated initrd and updates the GRUB2 config. I should note that neither lilo nor elilo work in my mini-PC? Anyway, I build my own generic kernels, now I'm in 6.5.2 and all I have to do is to execute "make install" because the kernel installation work is done by a proper ~/bin/installkernel script.
And let's not confuse boot failures with init system failures. I know some very simple methods to make systemd fail, without touching the kernels and bootloader or even the Linux system. For example, reinstall Windows with NTFS partition formatting, which partition is mounted during boot in /etc./fstab by UUID.
But I know people who had boot failures in Slackware 15.0 , even in this forum there are weekly threads like this. Of course "it was their fault" because "they forgot" something. Let's blame the users, right?
And yes, even I had boot failures in the previous Slackware -current, because I forgot to generate my initrd or update the bootloader. And this was not because it is a development tree, but because Slackware introduces the human factor in the upgrade of kernel packages.
I think that this introduction of the human factor in the upgrade of kernels is not necessary, even as an excuse for the freedom to do what you want with the kernel or the bootloader, and it is the main cause of boot failures.
From my own experience, it is very simple for Slackware itself to have a robust method of managing its own kernels, initrd(s) and bootloader for the general public, without affecting anyone's freedom to customize their kernels, initrd(s) and bootloader as they wish. The only thing missing is the desire to do it and the mentality "if it works for me, I don't care about others" does not help anything.
Last edited by ZhaoLin1457; 09-08-2023 at 02:56 AM.
But I know people who had boot failures in Slackware 15.0 even in this forum. Of course "it was their fault" because "they forgot" something. Let's blame the users, right?
To be fair, Slackware has always been this way. The responsibility is on the user to get it right, and I'm not sure that's such a bad thing. Sharp tools cut. You can't blame the knife for slicing your finger.
With that said, it looks like there are interesting times ahead, with Patrick looking like he'll be adopting GRUB as the main boot loader soon... and not just on the installation iso (where it has been for ~10 years). If Patrick's implementation of GRUB is as level-headed as the rest of the distribution, it should prevent certain complaints from some of the users who are incapable of reading instructions.
I never thought initrd? would be such a hot topic. Interesting read this thread is.
By default using the encouraged "full installation" will make kernel-huge the boot kernel. This simply due to order of installation kernel-generic is installed first, kernel-huge is installed last. Last place wins. Pretty sure this is by design.
I use kernel-generic (kernel-huge not installed) and initrd on this computer, my main computer. All of the rest including virtual machines with the exception of one I am using to test and play with grub, use kernel-huge. The reason is simple. The only thing I have to do when the kernel is upgraded with kernel-huge is run 'lilo' or in the future run 'grub-mkconfig -o /boot/grub/grub.cfg' That's it.
I use kernel-generic on this computer because I want too and these two snips from RELEASE_NOTES and Slackware-HOWTO respectively.
Code:
As usual, the kernel is provided in two flavors, generic and huge. The huge
kernel contains enough built-in drivers that in most cases an initrd is not
needed to boot the system. The generic kernels require the use of an initrd to
load the kernel modules needed to mount the root filesystem. Using a generic
kernel will save some memory and possibly avoid a few boot time warnings.
I'd strongly recommend using a generic kernel for the best kernel module
compatibility as well. It's easier to do that than in previous releases - the
installer now makes an initrd for you, and the new geninitrd utility will
rebuild the initrd automatically for the latest kernel packages you've
installed on the system.
Code:
hugesmp.s This is the default installation kernel. If possible,
you can save a bit of RAM later (and some ugly warnings at
boot time or when trying to load modules when the driver is
already built-in) by switching to a generic kernel. In this
case that would be gensmp.s, which is a similar kernel but
without filesystems and many of the less common drive
controllers built in. To support these (at the very least
your root filesystem), an initrd (actually an initramfs)
is required when a generic kernel is used. Previous
versions of Slackware used an ext2 filesystem for this, but
now a filesystem-less dynamic kernel-based directory
structure is used. A big advantage of this is that the size
usable by the initrd is only limited by the amount of RAM in
the machine. A disadvantage is that the generic kernels no
longer include *any* filesystems besides romfs, so old
initrd.gz files are not usable (they would have needed new
modules anyway), and it is trickier to get a custom binaries
or modules or whatever into the installer for guru-install
purposes. It's not impossible though -- think tar to/from a
device such as a USB stick, or leveraging ROMFS.
With kernel-generic it would as simple as running 'mkinitrd -F', then 'lilo'. Now on this computer, kernel-generic, kernel-huge, kernel-modules and kernel-source are blacklisted. So that is modified to this.
Why delete from "/var/cache/packages/slackware64/*/*"? I use a local slackware64-current mirror, slackpkg symlinks to the packages. When the local mirror is updated (daily cron job), those links become broken.
I'd like kernel-huge to stay. I also am in favor of kernel symlinks. This is part of my /boot directory.
Distribution: VM Host: Slackware-current, VM Guests: Artix, Venom, antiX, Gentoo, FreeBSD, OpenBSD, OpenIndiana
Posts: 1,011
Rep:
Personally, I never thought that pushing someone to do something makes any sense. If Slackware moves from lilo/elilo to grub that is fine if not that is ok too. Same goes for initrd as an only option.
I always considered Slackware as a distro that does not limit users in any sense. In fact user should customize installed Slackware or face the consequences . There are "complete" distros out there and if one does not want to modify OS, use one of these.
In my case this means installation of heavily modified custom kernel without initrd just after first system boot. I never had any issues with boot failure. I don't need initrd because this is a laptop with single disk and gpt (gpt handles 128 primary partitions so if planed well resizing partitions later is not required). No need for lvm then. RAID on single disk does not make sense either. Ross Ulbricht is good example why encrypting everything may not protect data as expected plus issues with system RAM unless Slackware kernel is modified. My encrypted partition does not require initrd then. These are reasons why I don't need initrd.
I installed Slackware only three times between 1998 and 200x (went back to FreeBSD and tried Arch and Gentoo), in 2017 first time on the laptop and in 2021 on a new laptop because my old one died. I consider Slackware extremely stable.. and real time saver as OS is not getting in my way.
If initrd is helping to get the same or better results that is fantastic. Whatever command to make initrd work..
In a pinch, you can boot your system from here with a command like:
boot: huge.s root=/dev/sda1 initrd= ro
regards Henrik
In practice, there is no need for a huge kernel even for this.
You can very well specify the root= parameter in the kernel command line, so it could just as well be a generic kernel, together with an initrd loaded with filesystem modules, to simulate the huge kernel behavior.
So, the only reason is that our BDFL does not want us to have this:
Code:
In a pinch, you can boot your system from here with a command like:
boot: sysboot.s root=/dev/sda1 ro
Believe it or not, you can boot very well in this mode and I checked practically many times.
Last edited by ZhaoLin1457; 09-08-2023 at 04:44 PM.
To be fair, Slackware has always been this way. The responsibility is on the user to get it right, and I'm not sure that's such a bad thing. Sharp tools cut. You can't blame the knife for slicing your finger.
Even if a questionable practice exists since Slackware 1.0, that does not make it something legit.
Want an example of a questionable practice that exists starting with Slackware 1.0? Here's one:
I think it is extremely bad that Slackware allows pkgtools to delete the active kernel files both as binaries and as modules. Most boot failures are generated by deleting these files.
With the hope you don't want to play "our Dear Leader said so" with a Chinese, I try to appeal to your common sense. It's a blatantly bad practice, and it's been around since Slackware 1.0
And yes, it's not really that complicated to fix this. Several solutions have already been described in this forum.
Quote:
Originally Posted by rkelsen
With that said, it looks like there are interesting times ahead, with Patrick looking like he'll be adopting GRUB as the main boot loader soon... and not just on the installation iso (where it has been for ~10 years). If Patrick's implementation of GRUB is as level-headed as the rest of the distribution, it should prevent certain complaints from some of the users who are incapable of reading instructions.
What could be interesting in the near future? After all, I have been using GRUB2 for many years. The GRUB2 from Slackware.
Thrilling, what? That he will write a grubconfig that I have wondered for many years why it was not written yet?
Last edited by ZhaoLin1457; 09-08-2023 at 05:13 PM.
I think it is extremely bad that Slackware allows pkgtools to delete the active kernel files both as binaries and as modules.
Do you not understand what this level of simplicity brings with it?
Quote:
Originally Posted by ZhaoLin1457
And yes, it's not really that complicated to fix this. Several solutions have already been described in this forum.
This is a slippery slope. What other powers should be removed from the hands of the 'dumb' users?
What are the limits, and how should they be decided?
Quote:
Originally Posted by ZhaoLin1457
Thrilling, what? That he will write a grubconfig that I have wondered for many years why it was not written yet?
There is a Latin phrase attributed to the Roman emperor Augustus which was claimed by Cosimo de Medici (the elder) in the early 15th century for use as the family motto, which I would say seems to fit Slackware's development philosophy quite well: Festina lente[1]. The literal translation of this phrase is, "hasten slowly."
[1]"In an era in where stress and anxiety are our two travel companions, 'festina lente' becomes a guiding light, an inspiration, a timely reminder that if we want to achieve success we must learn to 'hasten slowly.'" (loosely translated quote from the linked article)
This is enorbet's fault. He started with the Latin phrases.
[1]"In an era in where stress and anxiety are our two travel companions, 'festina lente' becomes a guiding light, an inspiration, a timely reminder that if we want to achieve success we must learn to 'hasten slowly.'" (loosely translated quote from the linked article)
This is enorbet's fault. He started with the Latin phrases.
It is indeed!, and most of them I came by in a totally underhanded,nerdy manner from misspent youthful hours reading hardcore Sci Fi. Robert Heinlein, for just one, not only tossed around quite a bit of Latin (while referring to Spanish as "Bastardized Latin") but even created his own, sometimes as colossal acronyms like "Tanstaafl". I always loved that one... pretty much applies here, too.
Then again, I'm so Old School I never use "Trash", I just Rename, Check, and then Delete.
In practice, there is no need for a huge kernel even for this.
No, it would be fully possible to implement with a huge initrd instead. But to what benefit?
Quote:
Originally Posted by ZhaoLin1457
You can very well specify the root= parameter in the kernel command line, so it could just as well be a generic kernel, together with an initrd loaded with filesystem modules, to simulate the huge kernel behavior.
So, the only reason is that our BDFL does not want us to have this:
Code:
In a pinch, you can boot your system from here with a command like:
boot: sysboot.s root=/dev/sda1 ro
Believe it or not, you can boot very well in this mode and I checked practically many times.
The above would require an ever bigger initrd.img than the one on the installation media today and most likely, it would require an extra initrd for only that purpose. With the huge kernel you get all that for "free".
I do realize that a generic kernel together with an initrd is necessary in some cases like when using an encrypted root file system. I also realize that it would be fully possible to build an installation media using a generic kernel. I also realize that even with an installation media with only a generic kernel it would still be possible to allow the choice of using a huge kernel on the installed system.
However, I don't understand the point in doing so. Would the installation media boot faster with a generic kernel? I doubt that as most of the time waiting for the installation to boot is spent waiting for the initrd.img to load. Would the installation media be easier to maintin? I doubt that as it would require more modules in initrd.img and probably also some extra initrd for "system boot".
So I guess that the main reason for sticking with the huge kernel for the installation media is that it works well and is easy to maintain.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
. There are "complete" distros out there and if one does not want to modify OS, use one of these.
