Anton Aylward wrote:

On 04/17/2015 02:13 PM, don fisher wrote:

...

On 04/17/2015 09:56 AM, Anton Aylward wrote:

...

... From kernel_stable http://download.opensuse.org/repositories/Kernel:/stable/standard/

I'll report after running it for a few days.

If you have the time, would you please tell me the steps you went through to build and install your kernel.

All I did was

zypper up

as root, at the command line. The rebooted.

Why would I want to build the kernel myself? I don't understand this propensity you seem to have, Don, for making things difficult/rococo.

Heck, even if wanted to build it myself I'd use the Build Service.

Building the kernel yourself is 4-5 sequential steps, using the OBS for that is, well, silly. A while ago I was playing around with getting openSUSE to boot on a Minix Neo X7 - if I'd had to 'consult' with the OBS everytime I needed a new kernel built, it would have taken forever. Just my opnion, ymmv. -- Per Jessen, Zürich (12.1°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/17/2015 01:48 PM, David C. Rankin wrote:

On 04/17/2015 02:13 PM, Per Jessen wrote:

...

Anton Aylward wrote:

...

...

If you have the time, would you please tell me the steps you went through to build and install your kernel.

All I did was

zypper up

as root, at the command line. The rebooted.

Why would I want to build the kernel myself? I don't understand this propensity you seem to have, Don, for making things difficult/rococo.

Heck, even if wanted to build it myself I'd use the Build Service.

Building the kernel yourself is 4-5 sequential steps, using the OBS for that is, well, silly. A while ago I was playing around with getting openSUSE to boot on a Minix Neo X7 - if I'd had to 'consult' with the OBS everytime I needed a new kernel built, it would have taken forever. Just my opnion, ymmv.

Ahh,

The good old days of rolling your own:

cd /usr/src/linux make mrproper make cloneconfig > /dev/null 2>&1 ## on SuSE make modules_prepare make clean

You forgot some steps. Download source taking way more time than your dialup is likely to stay connected. Expand source into directory space you can barely afford to lose Configure, tossing out everything you have no need for (you think) Go to bed and hope the compile finishes by the morning. Get on the internet and ask why the compile failed in some obscure module with an equally obscure error message. Get several insulting messages and be called a moron in return. Start again. What ever you saved in kernel size you sacrificed in disk space and time wasted. Yeah, I did that for a couple years. Then I found Hubert Mantel's kernels and never looked back. Where is Mantel these days anyway? -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

On 04/17/2015 05:07 PM, John Andersen wrote:

...

...

...

The good old days of rolling your own:

cd /usr/src/linux make mrproper make cloneconfig > /dev/null 2>&1 ## on SuSE make modules_prepare make clean

You forgot some steps. Download source taking way more time than your dialup is likely to stay connected. Expand source into directory space you can barely afford to lose Configure, tossing out everything you have no need for (you think) Go to bed and hope the compile finishes by the morning. Get on the internet and ask why the compile failed in some obscure module with an equally obscure error message. Get several insulting messages and be called a moron in return. Start again.

What ever you saved in kernel size you sacrificed in disk space and time wasted.

The suse build engines have space, power and more. perhaps that's why so many (sensible) people use the service rather than go though the hassle you describe "-)

I read John's comments to refer to days long gone when the dial-up was 64K, the PC was a 500MHz Pentium and diskspace was measured in double-digit gigabytes. Today, virtually anyone with an only somewhat modern PC will have "space, power and more". The internet bandwidth will vary, the kernel-source package is about 80Mb, for the default config build you'll need about 10Gb of working space. On some elderly hardware, both some 6-7 years old, probably easily outclassed by any cheap laptop (or a smartphone) today: Timings for "make bzImage modules" (no other significant load): HP xw6400 (four cores @ 2GHz, 2GB RAM, a 500Gb SATA drive). Timing: 43m49s (make -j4) Intel SR1530AH (two cores @ 1.6GHz, 2GB RAM, 2 x 160Gb in RAID1 Timings: 134m18s (make -j2) The time needed for "make modules" can be reduced significantly by amending the kernel configuration to suit your hardware. In my experience, getting an optimal config usually takes longer than building the kernel+modules :-) -- Per Jessen, Zürich (7.8°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrei Borzenkov wrote:

В Sat, 18 Apr 2015 15:55:40 +0200 Per Jessen пишет:

...

The time needed for "make modules" can be reduced significantly by amending the kernel configuration to suit your hardware. In my experience, getting an optimal config usually takes longer than building the kernel+modules :-)

Unless you need to compile kernel very often; in this case it could be significant benefit. It is not even as much as optimal but simply removing all modules for hardware you do not have cuts down compile time tremendously.

Completely agree. -- Per Jessen, Zürich (8.1°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen wrote:

Timings for "make bzImage modules" (no other significant load):

HP xw6400 (four cores @ 2GHz, 2GB RAM, a 500Gb SATA drive). Timing: 43m49s (make -j4)

Intel SR1530AH (two cores @ 1.6GHz, 2GB RAM, 2 x 160Gb in RAID1 Timings: 134m18s (make -j2)

?!?!?! Why so long? 4.0 is a bit different from my normal scripted build: I type 'getlinuxrelease X.Y.Z', that downloads the patch to the previous mainline, creates a duplicate tree w/"cp -al", applies the patch then dups the new tree into a workspace. Usually it pulls the ".config" from the previous version, and does the standard "make oldconfig" -- I usually look through the config to see what's changed. 2 Intel Xeon chips at 1.60GHz - 2.80GHz w/6 cores each. "make -j16" takes about 3 minutes w/6 cores each. The config _is_ tailored to my machine, with modules needed for boot compiled into the kernel and over 500 "optional"/"loadable" modules. Wouldn't it be possible to modify something like Wicked to draw up a list of needed modules for a user's specific machine -- building in required HW (disks, file systems, etc) and making modules for "possible modules for your machine. After you have a list of your HW, for future builds, you can simply copy the previous config and do a "make oldconfig". I can't imagine kernel build times taking that long, but I don't compile modules for HW I don't have -- most of the modules are for software options. # modules per 'section':

du -s --inodes /lib/modules/3.19.3-Isht-Van/kernel/* 15 /lib/modules/3.19.3-Isht-Van/kernel/arch 24 /lib/modules/3.19.3-Isht-Van/kernel/crypto 288 /lib/modules/3.19.3-Isht-Van/kernel/drivers 44 /lib/modules/3.19.3-Isht-Van/kernel/fs 13 /lib/modules/3.19.3-Isht-Van/kernel/lib 278 /lib/modules/3.19.3-Isht-Van/kernel/net --- space:

du -sh /lib/modules/3.19.3-Isht-Van/kernel/* 11M /lib/modules/3.19.3-Isht-Van/kernel/arch 5.3M /lib/modules/3.19.3-Isht-Van/kernel/crypto 181M /lib/modules/3.19.3-Isht-Van/kernel/drivers 63M /lib/modules/3.19.3-Isht-Van/kernel/fs 3.2M /lib/modules/3.19.3-Isht-Van/kernel/lib 128M /lib/modules/3.19.3-Isht-Van/kernel/net

The time needed for "make modules" can be reduced significantly by amending the kernel configuration to suit your hardware. In my experience, getting an optimal config usually takes longer than building the kernel+modules :-)

?!? --- Once you've configued the kernel for your HW, you can reuse the prior-version ".config" with "make oldconfig" Given your build times, you might want to consider it? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/19/2015 04:16 PM, Linda Walsh wrote:

Wouldn't it be possible to modify something like Wicked to draw up a list of needed modules for a user's specific machine -- building in required HW (disks, file systems, etc) and making modules for "possible modules for your machine.

After you have a list of your HW, for future builds, you can simply copy the previous config and do a "make oldconfig". I can't imagine kernel build times taking that long, but I don't compile modules for HW I don't have -- most of the modules are for software options. # modules per 'section':

Never mind the "build"! I can understand the install medium needing every possible module since at install time the installer has to probe for hardware. I can understand the USB means many more possible devices. But ... There are a lot of "Buts..." There are probably mnore for a laptop than a desltop. Laptops don't have the open chassis that many desktops have :-) I can understand a generic build for a distribution, yes. But ... Lets face it: ... Better than 99% of Linux users aren't "doing" the specialized kernel builds that Linda does. ... Better than 95% of Linux users aren't as technically sophisticated as the regular contributors here, not do that want to be. The just want their applications to work. Think "Android". When I get a new kernel from Kernel_Stable I still have ... ... To run a mkinitrd or equivalent. And OUCH, that hits all four cores and for a few seconds I'm not getting much work done! Well! At this point we get back to a situation like Linda describes. I've downloaded ALL the modules, even those for hardware I can't imagine using (or affording!). This is not the debugging kernel, so like most of the application binaries, it is 'stripped". (See 'man 1 strip') So why not 'strip' out the modules that aren't needed/wanted? Or make them a load on demand? We are already doing a load-on-demand for kernel modules. If you run a ATI or a Nvida GPU then you have to load the driver. Is it too much to ask to extend the /etc/modules/d/ tree to 'strip' or ever load "blacklisted" modules? Oh, right, "HERESY!" perhaps not quite as controversial as KDE4 or systemd.... -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/20/2015 01:06 PM, Per Jessen wrote:

...

...

We are already doing a load-on-demand for kernel modules. If you run a ATI or a Nvida GPU then you have to load the driver. Is it too much to ask to extend the /etc/modules/d/ tree to 'strip' or ever load "blacklisted" modules?

No, it's not too much, but what would you gain? What's the business-case and how does the installer pick the right sets of modules?

The Installer? I'm the one that edited the blacklist. I'm the one that has tor rebuild -- or used to before I adopted Intel -- the nvida driver. That happens when I do things like a mkinitrd. And every time I download a new kernel the old one(s) get purged, according the policy I set in zypp.conf. I see no reason additional purging of blacklisted modules shouldn’t be possible at that point. Because downloading a new kernel from kernel_Stable results in the mkinitrd ... Yes, the initial installer probes the hardware and sets the list of modules to be loaded at boot time for the hardware it sees. And yes, autoyast can be edited to do many things. And yes there is an issue of portability. But I'm talking about a more mature system. heck, any system gets heavily customized after the initial install, even by those of us who aren't Linda! -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/21/2015 02:02 AM, Per Jessen wrote:

I agree it would be nice to reduce the number of times the initrd is being rebuilt - you only have to update mdadm, and voila, a new initrd.

Apart from that, I don't really get what it is you're suggesting. Purging unneeded/unwanted modules would only save disk-space, I think.

Its not just about reducing the amount of disk space. When I download a whole new kernel from -stable I expect a mkinitrd. To build a new initrd. What don't expect is that when I run a 'zypper up' and I get 4 or 5 updates, each one of them triggers a mkinitrd. Surely just one, at the end when all the deltas/whatever have been done. As it happens. What's under /lib/modules comes along in a package with a new kernel. As I said, I can understand a complete set when installing or making a portable system,. Others have pointed out the issue of if you are actually building you can be specific about what you include, but this way I pay for bandwidth for stuff I don't want and never use. Why? If this is Thunderbird or Firefox, for example, I can download a new core, and the core sees what plugin modules I & extensions I have, checks to see if they are compatible (I think I pointed out that the 2.19.X modules were binary compatible between minor revisions) and if not requests the updates for the specific ones that need updating. I know which kernel modules I use - lsmod tells me. I can see what I've explicitly or automagically blacklisted. Why can't I get a automatic kernel module update on demand only as necessary in much the same way? To some degree I'm not sure why I need a complete mkinitrd. I can see why I need a update to the grub menu. As far as I can tell the bundling of a complete minisystem in the initrd is ether belt&braces or simple paranoia. I'm sure at this point Linda has something to offer on how initrd is not needed, but I'm not sure the path she has chosen is what I'm envisioning here, the 'load on demand' aspect of dealing with modules being extended to "download the specific and only the specific new version only on on demand". -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/22/2015 12:49 PM, Andrei Borzenkov wrote:

It should become better post-13.2.

Yes, "There'll be pie in the sky by-and-by". -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

On 04/21/2015 02:02 AM, Per Jessen wrote:

...

I agree it would be nice to reduce the number of times the initrd is being rebuilt - you only have to update mdadm, and voila, a new initrd.

Apart from that, I don't really get what it is you're suggesting. Purging unneeded/unwanted modules would only save disk-space, I think.

Its not just about reducing the amount of disk space.

When I download a whole new kernel from -stable I expect a mkinitrd. To build a new initrd.

What don't expect is that when I run a 'zypper up' and I get 4 or 5 updates, each one of them triggers a mkinitrd. Surely just one, at the end when all the deltas/whatever have been done.

(sorry about the late reply, I was away for a few days.) I agree it would be nice if we could have the initrd rebuilt just once, that would certainly save some time.

As it happens. What's under /lib/modules comes along in a package with a new kernel. As I said, I can understand a complete set when installing or making a portable system,. Others have pointed out the issue of if you are actually building you can be specific about what you include, but this way I pay for bandwidth for stuff I don't want and never use.

Why?

I think I said it earlier - because the kernel package is only 50Mb, it's a mere drop in the ocean. There is simply no business case for splitting it up.

I know which kernel modules I use - lsmod tells me. I can see what I've explicitly or automagically blacklisted.

You can't see what has yet to be loaded :-) As an aside, do you actually blacklist many modules? I don't recall when I last had to resort to that.

To some degree I'm not sure why I need a complete mkinitrd. I can see why I need a update to the grub menu. As far as I can tell the bundling of a complete minisystem in the initrd is ether belt&braces or simple paranoia.

None of that. Something has to mount your root filesystem. openSUSE supports having the root filesystem on a plethora of devices - iSCSI, USB, NFS etc etc. You can certainly build a monolithic kernel with everything needed built in, but that'll only fit your system. -- Per Jessen, Zürich (14.6°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

On 04/27/2015 03:27 AM, Per Jessen wrote:

...

None of that. Something has to mount your root filesystem. openSUSE supports having the root filesystem on a plethora of devices - iSCSI, USB, NFS etc etc. You can certainly build a monolithic kernel with everything needed built in, but that'll only fit your system.

I'm not arguing that the distribution system should not be capable of running on a plethora of co figurations.

I'm arguing that once it it tied down to a specific system there are many constraints.

Anton, I can't really follow you - which problem are you trying to solve/identify? if this is about bandwidth, I don't see how much can be saved when the kernel package is only 50Mb. if you want to run a system without an initrd, that is certainly possible, but not within the openSUSE scope. avoiding multiple mkinitrds/dracut during an update would be nice, I agree. -- Per Jessen, Zürich (20.1°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, Apr 17, 2015 at 4:53 PM, don fisher wrote:

On 04/17/2015 11:46 AM, Anton Aylward wrote:

...

All I did was

zypper up

as root, at the command line. The rebooted.

Why would I want to build the kernel myself? I don't understand this propensity you seem to have, Don, for making things difficult/rococo.

Heck, even if wanted to build it myself I'd use the Build Service.

Which, but the way, is more than adequately documented on the web site.

Anton,

Sorry if I offended. The last time I was involved one built their own kernels by default, just to get all of the devices running. I assumed you had done that also, until I clicked on your link and saw the prebuilt RPMs. I was really trying to get an update on writing device drivers. In the past building the kernel was fundamental to that, though I see now that a new capability may allow a simpler path. The new version of Linux Device Drivers, 4th Edition is due out in October. I can wait.

Don

Don, You likely want to join kernelnewbies http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

don fisher wrote:

On 04/17/2015 09:56 AM, Anton Aylward wrote:

...

... From kernel_stable http://download.opensuse.org/repositories/Kernel:/stable/standard/

I'll report after running it for a few days.

If you have the time, would you please tell me the steps you went through to build and install your kernel. Or reference any documentation pointers. When I was doing this a lot lilo was the boot loader and things were really simple.

FYI, you can still use lilo today, I do. If you google "building the linux kernel", you'll get lots of useful pointers.

All you had to do was rename the new kernel. But there are a lot of opensuse patches, some of which probably should be retained.

And I never did anything where systemd loaded the modules.

systemd did not, afaik, change any of that.

If this is pain forget it. If you have notes in a convenient form maybe you could email them to me. I used to build kernels all the time when I wrote drivers for our telescope control systems. But that was way back in 2006.

Building the kernel has not changed that much since then, Don. Get the source, configure to your liking, build, build modules, install modules, amend bootloader, done. If you want the openSUSE patches etc, it's probably easiest just getting a ready-built kernel package from http://software.opensuse.org. -- Per Jessen, Zürich (12.4°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, Apr 17, 2015 at 2:13 PM, don fisher wrote:

On 04/17/2015 09:56 AM, Anton Aylward wrote:

...

... From kernel_stable http://download.opensuse.org/repositories/Kernel:/stable/standard/

I'll report after running it for a few days.

If you have the time, would you please tell me the steps you went through to build and install your kernel. Or reference any documentation pointers. When I was doing this a lot lilo was the boot loader and things were really simple. All you had to do was rename the new kernel. But there are a lot of opensuse patches, some of which probably should be retained. And I never did anything where systemd loaded the modules. I have not even figured out where the config files that say what modules to load are, and how that decision is made. I tried to join the kernel list to watch the emails and see what they were doing, but I have not been able to because of Comcast email restrictions. The documentation I found using Google is either really old or references just replacing one RPM with another.

If this is pain forget it. If you have notes in a convenient form maybe you could email them to me. I used to build kernels all the time when I wrote drivers for our telescope control systems. But that was way back in 2006.

Don

Don, FYI only: The openSUSE team maintains current stable kernels for recent openSUSE releases: https://build.opensuse.org/project/show/Kernel:stable You can see lots of packages there, but lets assume you want the standard openSUSE desktop variant of the kernel. That takes you to: https://build.opensuse.org/package/show/Kernel:stable/kernel-desktop You can see all the patches that are applied etc. There are various links available on the page. Spend 5 minutes moving your mouse around and exploring. In particular click on "standard" and see the list of RPMs built by the package. I also always like to look at the "changes" file. In this case kernel-desktop.changes has === ------------------------------------------------------------------- Tue Apr 14 15:36:11 CEST 2015 - mmarek@suse.cz - rpm/kernel-obs-qa.spec.in: Do not fail if the kernel versions do not match - commit 28e9e74 ------------------------------------------------------------------- Tue Apr 14 08:32:12 CEST 2015 - jlee@suse.com - Update config files. (boo#925479) Do not set CONFIG_SYSTEM_TRUSTED_KEYRING until we need it in future openSUSE version: e.g. MODULE_SIG, IMA, PKCS7(new), KEXEC_BZIMAGE_VERIFY_SIG(new) - commit 5c4d917 ------------------------------------------------------------------- Tue Apr 14 06:39:50 CEST 2015 - jlee@suse.com - Update config files. (boo#925479) Do not set CONFIG_SYSTEM_TRUSTED_KEYRING until we need it in future openSUSE version: e.g. MODULE_SIG, IMA, PKCS7(new), KEXEC_BZIMAGE_VERIFY_SIG(new) - commit 74c332b ------------------------------------------------------------------- Mon Apr 13 16:11:20 CEST 2015 - jeffm@suse.com - Update to 4.0-final. - commit 6dbc1a6 === So you know the source was update to 4.0 on Monday and since then there have been 2 changes to the config files and one change to the spec file. When you're ready to install a kernel from that package, click on download package in the upper right hand corner and it leads you through doing the upgrade. Hope that helps Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, Apr 17, 2015 at 6:08 PM, Anton Aylward wrote:

On 04/17/2015 04:08 PM, Greg Freemyer wrote:

...

So you know the source was update to 4.0 on Monday and since then there have been 2 changes to the config files and one change to the spec file.

I'm not THAT obsessive about updating my kernel!

I will say that so far the 4.0 has proven to be snappy. Scheduling is good, FF isn't bogging down so far. Of course something like metaploit is a killer ..

Just a habit I have. If I'm pulling software straight from OBS, I like to look at the changes file. Let's you know how actively maintained it is. For the stable kernel it is very actively maintained. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org