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.
This patch fixes a warning:
Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\${ <-- HERE [^\}]*}/ at /usr/bin/autoscan line 361.
OpenSSH 7.3 is out. This release fixes a number of security issues (mostly related to timing attacks) and adds a handful of new minor features. The developers also warn that RSA keys less than 1024 bits will be refused in a near-future release.
In #1438 I asked you to add some Plan 9 modules to initrd.img for having Plan 9 file system support in the installer.
But there's a problem, and I have lost many of my hairs nailing it down
I'm mostly interested in 9p.ko module, since it seems to be sufficient to have the file system working.
But I went ahead and recreated the initrd.img with all the 9p* modules, that is:
and I had really hard times modprobing 9p.ko, but insmoding worked fine.
It turned out that, the huge.s kernel has the following set to yes:
Code:
CONFIG_NET_9P=y
which basically prevents modprobing of 9p.ko, because 9pnet.ko is dependency for 9p.ko and that is what happens:
Code:
$ modprobe 9p
modprobe: ERROR: could not insert '9p': Exec format error
$ dmesg | grep 9pnet
9pnet: exports duplicate symbol p9_client_attach (owned by kernel)
Recreating the initrd.img without 9pnet.ko included allows for correct operation.
BTW, for 9pnet_virtio.ko the situation might be similar, but I cannot be sure about that:
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?
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?
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.
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.
That's likely a good idea. IMO two kernels is one too many. Though, if you do decide to go that way, it may be worth considering re-inlining some of the modules that 99.9% of users are going to need anyway (such as the various *hci modules required for usb keyboards). 'generic' currently seems to follow a 'modulise anything that can be' approach, and I'm not sure that's the best way to go. Maybe something in-between 'huge' and 'generic' but closer to the generic end of the scale is the answer.
That's likely a good idea. IMO two kernels is one too many. Though, if you do decide to go that way, it may be worth considering re-inlining some of the modules that 99.9% of users are going to need anyway (such as the various *hci modules required for usb keyboards). 'generic' currently seems to follow a 'modulise anything that can be' approach, and I'm not sure that's the best way to go. Maybe something in-between 'huge' and 'generic' but closer to the generic end of the scale is the answer.
I do not think that is such a good idea to inline modules and create a kernel model somewhere inbetween huge and generic - it will lead to the same issues being described in this thread in the long run. What modules do you inline and which not? And once inlined, you lose configuration options. Fully generic kernel plus a good initrd generator is what you need.
I wasn't suggesting going mad and including lots of stuff, I was thinking more along the lines of the o/u/h/xhci modules that pretty much everyone are likely to need and which don't take any configuration parameters. But yes, it's a judgement call as to where the line is drawn, and I take your point in general.
I do not think that is such a good idea to inline modules and create a kernel model somewhere inbetween huge and generic - it will lead to the same issues being described in this thread in the long run.
Not, if we had only one type of kernel. The problem here is that some modules do not load because of symbols duplication between the huge kernel and the generic kernel's modules.
Quote:
Originally Posted by Alien Bob
What modules do you inline and which not?
Fortunately, that's Pat's problem ;->
Quote:
Originally Posted by Alien Bob
And once inlined, you lose configuration options. Fully generic kernel plus a good initrd generator is what you need.
Good point. I wonder if modularize 'em all would work. There surely would have to be some changes to the init scripts, since some kernel modules are now being configured in the kernel proper, for example 'Default I/O scheduler'.
I support the idea of moving to generic kernel only. That would finally force all the people to use it and exclude another point of failure.
I wasn't suggesting going mad and including lots of stuff, I was thinking more along the lines of the o/u/h/xhci modules that pretty much everyone are likely to need and which don't take any configuration parameters. But yes, it's a judgement call as to where the line is drawn, and I take your point in general.
I guess, where the line is drown, depends of how reliably can you detect the hardware.
As Alien said, you need a good initrd generator. It would detect what modules are needed for the disk controller and ask you if you want to add them. That would allow you to boot.
Naturally, it's not that easy. There are people requiring all kinds of different stuff in initrd, e.g. keyboard for entering password, etc.
EDIT:
But that could be made configurable, say, you want USB support, then set USB=1 in /etc/mkinitrd.conf, and so on.
--
Best regards,
Andrzej Telszewski
Last edited by atelszewski; 08-03-2016 at 04:11 PM.
Happy Birthday SWIG-3.0.7!! One year old today. But in software years that's more than 1 year. Having SWIG-3.0.10 in current wouldn't be a bad thing as far as I can tell it fixes a lot of stuff, adds some more features for some languages and there's probably a security fix or two in there.
Firefox 48 is out, and with it the Electrolysis process separation mechanism that's been in development since 2011 (Chrome, Safari and even IE have had this architecture for years, so Firefox is really lagging behind). There's a good summary of what Electrolysis provides in this Ars Technica article.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
