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.
Not surprisingly, what I described above, applies also to the Slackware OS itself, not only the installer.
That is, with the huge kernel it's not possible to modprobe 9p.ko, insmod still works.
It's not a great deal for me, because I'm using generic kernel with initrd, but it might be something to watch for.
Should it be considered kernel bug, or has it always been like that?
--
Best regards,
Andrzej Telszewski
This sounds like a kernel bug to me, but it probably will not be fixed.
Plan 9 ("Fossil") is an ancient file system created before Unix was invented.
It is probably not tested/cared for very well because very few people are using it.
This sounds like a kernel bug to me, but it probably will not be fixed.
Pat blames Slackware, we, naturally, blame the kernel ;-) I wonder if somebody could provide the definitive answer? The problem here is that, when loading 9p.ko, it fails, because it tries to load its dependency module, namely 9pnet.ko. But 9pnet.ko can't be loaded, since 9pnet is also built-in into the kernel, so the loading fails because of duplicated symbols. But why 9p.ko cannot use the symbols from the kernel image then? It's probably because of modules.dep, which is generated for generic kernel.
Quote:
Originally Posted by comet.berkeley
It is probably not tested/cared for very well because very few people are using it.
I don't know the numbers, but my feeling is that, 9p has a bigger user base. It allows for easy folder sharing within QEMU, having virtio drivers. Looking at the git, it sees changes here and there.
Quote:
Originally Posted by comet.berkeley
Slackware 14.1 did not include these 9P modules in the huge kernel, but set CONFIG_9P_FS=m and CONFIG_NET_9P=m. Maybe current should do this too?
I wouldn't mind. Or set CONFIG_NET_9P=y both in huge and generic kernels.
Quote:
Originally Posted by comet.berkeley
I would hate to see the huge kernel disappear just because of Plan 9.
It won't disappear because of Plan 9. It might disappear for different reasons.
Quote:
Originally Posted by comet.berkeley
Huge makes kernel testing much easier than custom building an initrd for every kernel upgrade.
The 2.24 version of the GNU C Library (glibc) has been released. It comes with lots of bug fixes, including five for security vulnerabilities (four stack overflows and a memory leak). Some deprecated features have been removed, as well as deprecating the readdir_r() and readdir64_r() functions in favor of readdir() and readdir64(). There are also additions to the math library (nextup*() and nextdown*()) to return the next representable value toward either positive or negative infinity.
I seriously doubt the huge kernel will ever disappear. Many people use it as their default kernel.
That's pretty big words considering Pat already said that he's considering it (emphasis mine). Obviously, if it went away, people would be using a generic kernel as their default kernel.
Quote:
Originally Posted by volkerdi
It's a Slackware bug, and given the creeping dependency tangle with the kernel modules I think the only solution will be to do away with the huge kernel and require an initrd.
Yes, but you do realize that some people do not like to maintain an initrd with each and every kernel update and rebuild. Personally, I don't mind having modules in my system, but I dislike the fact that to get a system useable with an initrd it has to be rebuilt each time you need to load certain hardware at boot. I wouldn't mind if things like filesystem drivers and disk controller drivers stayed in the kernel. It's less work overall in my opinion to have to bother tinkering with filesystem and ide/scsi/sata drivers than audio, video, input, and network stuff. Isn't that what udev is for?
Pat blames Slackware, we, naturally, blame the kernel ;-)
Patrick has the right approach. The kernel is probably not to blame here and blaming the kernel, even if it is wrong, will still not fix the problem.
Quote:
Originally Posted by atelszewski
I wonder if somebody could provide the definitive answer? The problem here is that, when loading 9p.ko, it fails, because it tries to load its dependency module, namely 9pnet.ko. But 9pnet.ko can't be loaded, since 9pnet is also built-in into the kernel, so the loading fails because of duplicated symbols.
But why 9p.ko cannot use the symbols from the kernel image then? It's probably because of modules.dep, which is generated for generic kernel.
I think you hit it on the head when you pointed out that there are two different version of the modules.dep, one for the small kernel using initrd.img and one for the huge kernel.
I examined the current installation disk initrd.img (of July 28) and it does have a huge modules.dep file not the generic modules.dep. So when loading 9p.ko it should not try to load 9pnet.ko.
Maybe a separate thread can be created to try and explore different ways to fix the problem?
Quote:
Originally Posted by atelszewski
What do you mean?
I like the huge kernel. I used to use the generic kernels more but then I started testing newer kernels/file systems and changed them frequently.
It became a chore to create an initrd for each new kernel tested and so I stopped using generic kernels.
If I ran a stable environment where the kernel never changes and the filesystem never changes, then a generic kernel with an initrd.img makes more sense.
I examined the current installation disk initrd.img (of July 28) and it does have a huge modules.dep file not the generic modules.dep. So when loading 9p.ko it should not try to load 9pnet.ko.
9p.ko is not included in the installer's initrd.img by default. When I tried to add it the first time, I also added 9pnet.ko and this caused me the headaches. 9pnet.ko collided with CONFIG_NET_9P=y in the huge kernel. Then, I added 9p.ko only and everything was fine.
Quote:
Originally Posted by comet.berkeley
I like the huge kernel. I used to use the generic kernels more but then I started testing newer kernels/file systems and changed them frequently.
It became a chore to create an initrd for each new kernel tested and so I stopped using generic kernels.
If I ran a stable environment where the kernel never changes and the filesystem never changes, then a generic kernel with an initrd.img makes more sense.
This is true, sort of ;-) /etc/mkinitrd.conf to the rescue:
This configuration allows you to quickly and easily update /boot/initrd.gz after you have updated kernel image. Of course, it's one more command to be typed ;-) But, if you use syslinux or grub, then at least you don't have to run lilo :-) BTW, I wanted to read the kernel version directly from the kernel image, but in the end I decided that symlinking would save me couple of hours of my life ;-)
I used to use similar approach when I used to update the kernel as soon as a newer release was released. I was installing it under /boot, in the same manner as it is now, e.g. /boot/vmlinuz-generic-4.4.55, and then I was symlinking it, with something like /boot/vmlinuz-generic-4.4.x. And my /etc/mkinitrd.conf read something like this:
REQUEST:
I think that, possibility of specifying alternative mkinitrd configuration file, would allow the users that want to test kernels often, to test them more easily. I know you can do something like:
Honestly, I can't read minds so I don't know what you meant, I just see what you wrote and disagree with your fairly obvious agenda to force kernel-generic upon everyone.
I see your problem is with config-huge, but instead of writing config-huge-custom that supports your qemu or whatever virtual machine you happen to be using, you'd rather have various features and drivers required for booting metal, traditionally built in huge kernel, removed from distribution, while the rest of us non-virtual machine users will have to cope with that, chroot from installer and make initrd for metal or risk a panic with no timeout due to excluded controller or filesystem driver.
So instead of just booting kernel-huge to make our kernels, in the future we'll have to make initrd before the build, just to remove initrd after the build, well thanks a lot atelszewski, really needed that extra configuration step, I don't know how I ever managed to live without it, and I dare not imagine how bad it must've been for you, having an evil huge kernel in your /boot.
No offense, but I think this was very inconsiderate of you, especially the rc.d comment that you made in a futile attempt to enforce optional kernel feature as requirement for all.
While I respect whatever decision the boss will make on this, it doesn't mean I must agree with it, and it certainly doesn't mean I'm forbidden to patch the installer iso.
@elcore I think you went far too much with your comment. I'm not enforcing anything on anyone. I found a problem and I described it here. I even commented, that my Plan 9 problem won't probably be a reason to drop the huge kernel. I solved the problem myself and shared the info here.
And to remind you, what we request here, reads like that: "Pat, would be kind enough to consider talking into account my proposal"?
Don't blame me for my proposals, because I can propose whatever I see fit.
I don't want to read through the thread again, but most certainly I haven't requested removal of the huge kernel.
Quote:
I just see what you wrote and disagree with your fairly obvious agenda to force kernel-generic upon everyone.
I have no fucking interest in that, boot the way you like.
Use one of the provided generic kernels for daily use. Do not report
bugs until/unless you have reproduced them using one of the stock
generic kernels. You will need to create an initrd in order to boot
the generic kernels - see /boot/README.initrd for instructions.
The huge kernels are primarily intended as "installer" and "emergency"
kernels in case you forget to make an initrd.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
