LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Closed Thread
  Search this Thread
Old 08-03-2016, 07:28 PM   #1456
cwizardone
LQ Guru
 
Registered: Feb 2007
Distribution: Slackware64-current with "True Multilib."
Posts: 5,051
Blog Entries: 1

Rep: Reputation: 2560Reputation: 2560Reputation: 2560Reputation: 2560Reputation: 2560Reputation: 2560Reputation: 2560Reputation: 2560Reputation: 2560Reputation: 2560Reputation: 2560

NetworkManager-1.2.4 has been released.

The change log,

https://cgit.freedesktop.org/Network...e/NEWS?h=1.2.4

Source,
http://ftp.gnome.org/pub/GNOME/sourc...r-1.2.4.tar.xz

Last edited by cwizardone; 08-04-2016 at 05:14 PM. Reason: Added change log link.
 
1 members found this post helpful.
Old 08-04-2016, 08:48 AM   #1457
EYo
Member
 
Registered: Jun 2009
Location: Cloverdale, northern california
Distribution: Slackware 14.2
Posts: 182

Rep: Reputation: 150Reputation: 150
Quote:
Originally Posted by Alien Bob View Post
plus a good initrd generator
Thanks a lot for helping write one, and writing docs people can learn from. Thanks.
Code:
#grep Copyright /usr/share/mkinitrd/mkinitrd_command_generator.sh

# /usr/share/mkinitrd/mkinitrd_command_generator.sh --longhelp
Cheers
 
Old 08-04-2016, 11:18 AM   #1458
aaazen
Member
 
Registered: Dec 2009
Posts: 357

Rep: Reputation: Disabled
Quote:
Originally Posted by atelszewski View Post
Hi,

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.

https://en.wikipedia.org/wiki/Fossil_(file_system)

https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs

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 would hate to see the huge kernel disappear just because of Plan 9.

https://www.youtube.com/watch?v=u2ukRYsYPmo

Huge makes kernel testing much easier than custom building an initrd for every kernel upgrade.

Last edited by aaazen; 08-04-2016 at 11:23 AM. Reason: CONFIG_9P_FS
 
2 members found this post helpful.
Old 08-04-2016, 12:56 PM   #1459
atelszewski
Member
 
Registered: Aug 2007
Distribution: Slackware
Posts: 890

Rep: Reputation: Disabled
Hi,

Quote:
Originally Posted by comet.berkeley View Post
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 View Post
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 View Post
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 View Post
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 View Post
Huge makes kernel testing much easier than custom building an initrd for every kernel upgrade.
What do you mean?

--
Best regards,
Andrzej Telszewski
 
Old 08-04-2016, 07:41 PM   #1460
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-Current
Posts: 6,449
Blog Entries: 15

Rep: Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021
I seriously doubt the huge kernel will ever disappear. Many people use it as their default kernel.

If you need support, just rebuild the kernel and modules with the enabled kernel module or built-in driver.
 
2 members found this post helpful.
Old 08-04-2016, 07:55 PM   #1461
atelszewski
Member
 
Registered: Aug 2007
Distribution: Slackware
Posts: 890

Rep: Reputation: Disabled
Hi,

Quote:
Originally Posted by ReaperX7 View Post
I seriously doubt the huge kernel will ever disappear. Many people use it as their default kernel.

If you need support, just rebuild the kernel and modules with the enabled kernel module or built-in driver.
I don't mind too much now. I learned the lesson the hard way, so I'm never gonna use the huge kernel again. (Never say never ;-)).

--
Best regards,
Andrzej Telszewski
 
Old 08-04-2016, 08:45 PM   #1462
atelszewski
Member
 
Registered: Aug 2007
Distribution: Slackware
Posts: 890

Rep: Reputation: Disabled
Hi,

Quote:
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.
--
Best regards,
Andrzej Telszewski
 
Old 08-04-2016, 10:35 PM   #1463
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 6,289

Rep: Reputation: 4037Reputation: 4037Reputation: 4037Reputation: 4037Reputation: 4037Reputation: 4037Reputation: 4037Reputation: 4037Reputation: 4037Reputation: 4037Reputation: 4037
Quote:
Originally Posted by ReaperX7 View Post
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 View Post
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.
 
Old 08-04-2016, 11:00 PM   #1464
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-Current
Posts: 6,449
Blog Entries: 15

Rep: Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021
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?

Last edited by ReaperX7; 08-04-2016 at 11:01 PM.
 
1 members found this post helpful.
Old 08-05-2016, 01:05 AM   #1465
aaazen
Member
 
Registered: Dec 2009
Posts: 357

Rep: Reputation: Disabled
Quote:
Originally Posted by atelszewski View Post
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 View Post
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 View Post
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.
 
2 members found this post helpful.
Old 08-05-2016, 02:09 AM   #1466
gmgf
Senior Member
 
Registered: Jun 2012
Location: Bergerac, France
Distribution: Slackware
Posts: 1,712

Rep: Reputation: 668Reputation: 668Reputation: 668Reputation: 668Reputation: 668Reputation: 668
ModemManager-1.6.0:

https://www.freedesktop.org/software...r-1.6.0.tar.xz

need new libmbim-1.14.0:

https://www.freedesktop.org/software...-1.14.0.tar.xz
 
Old 08-05-2016, 05:43 AM   #1467
atelszewski
Member
 
Registered: Aug 2007
Distribution: Slackware
Posts: 890

Rep: Reputation: Disabled
Hi,

Quote:
Originally Posted by comet.berkeley View Post
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 View Post
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:
Code:
[..]
KERNEL_VERSION="$( readlink /boot/vmlinuz-generic | rev | cut -f1 -d- | rev )"
[..]
and then:

Code:
$ mkinitrd -F
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:
Code:
[..]
OUTPUT_IMAGE="/boot/initrd-generic-4.4.x.gz"
KERNEL_VERSION="$( readlink /boot/vmlinuz-generic-4.4.x | rev | cut -f1 -d- | rev )"
[..]

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:
Code:
$ mkinitrd -F -k 4.6.7 -o /boot/initrd-generic-4.6.x.gz
but it would be much more convenient to do something like:
Code:
$ mkinitrd -F /etc/mkinitrd.conf.4.6.x
--
Best regards,
Andrzej Telszewski
 
Old 08-05-2016, 06:03 AM   #1468
elcore
Member
 
Registered: Sep 2014
Distribution: Slackware
Posts: 608

Rep: Reputation: Disabled
Quote:
Originally Posted by atelszewski View Post
Hi,



You know what I meant.

--
Best regards,
Andrzej Telszewski
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.
 
1 members found this post helpful.
Old 08-05-2016, 06:24 AM   #1469
atelszewski
Member
 
Registered: Aug 2007
Distribution: Slackware
Posts: 890

Rep: Reputation: Disabled
Hi,

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

--
Best regards,
Andrzej Telszewski
 
Old 08-05-2016, 06:45 AM   #1470
atelszewski
Member
 
Registered: Aug 2007
Distribution: Slackware
Posts: 890

Rep: Reputation: Disabled
Hi,

Excerpt from CHANGES_AND_HINTS.TXT:
Code:
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.
--
Best regards,
Andrzej Telszewski
 
1 members found this post helpful.
  


Closed Thread


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] how to show the current time at the top in the current shell Always ? rohitchauhan Linux - General 5 04-09-2014 04:05 PM
Slackware ARM (current) epic mistake: the current Android kernels are kicked out! Darth Vader Slackware 16 08-25-2013 05:36 PM
[SOLVED] setup fails on most current Slackware-current March 26, 2012 AlleyTrotter Slackware 15 04-09-2012 07:05 AM
Observation of Feb -current vs March -current Hangaber Slackware 14 03-12-2010 09:26 AM
cvs diff the most current and second last current version powah Linux - Software 1 03-30-2006 02:02 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 06:56 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration