[opensuse] Just installed kernel 4.0
... From kernel_stable http://download.opensuse.org/repositories/Kernel:/stable/standard/ I'll report after running it for a few days. -- 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/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 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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. Which, but the way, is more than adequately documented on the web site. -- 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/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 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 -- David C. Rankin, J.D.,P.E. -- 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
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 "-) -- 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/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
В Sat, 18 Apr 2015 15:55:40 +0200 Per Jessen <per@computer.org> пишет:
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. -- 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 <per@computer.org> пишет:
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
Am Sonntag, 19. April 2015, 08:34:57 schrieb Andrei Borzenkov:
В Sat, 18 Apr 2015 15:55:40 +0200
Per Jessen <per@computer.org> пишет:
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. If you use the same options for compiling as the distribution kernel, you will get kernel and modules with debugging symbols included. These kernels are huge and probably slower than the packaged kernels. Kernel packaging extracts the debugging info, packages it into an extra -debuginfo package and then strips it from the distributed kernels. -- 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
Linda Walsh wrote:
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.
Okay, you've got a bigger smartphone :-)
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.
Thinking out loud - I think people who have a desire ("because I can!") to build their own kernel will probably not want too many helpers and scripts. Well, I know I wouldn't. Also, it's not too difficult - check out lsusb and lspci, and add the modules for operating those devices. In practice it's not always easy to pick the right bits, but that's part of the job. I have more than once been too aggressive in deselecting stuff and ended up with a non-working kernel. No big deal, rinse, repeat - but which bit caused the problem ...
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"
Linda, you're preaching to the choir. If I had a need or a desire to build my own kernels (more than once), the first thing I would do is obviously adapt the config. I only demonstrated the build times to show that even an elderly PC with a rather meagre config will have sufficient "space, power and more" to build the kernel in less time than it would take someone to do it with the OBS. -- Per Jessen, Zürich (6.4°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- 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
Anton Aylward wrote:
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?
Because the typical kernel is still only 45-50Mb to download, a bit more to install. I do appreciate that there is probably still someone in Australian outback or in Belgian Congo on 2400baud dial-up, but those 50Mb are a mere drop in the ocean.
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? -- Per Jessen, Zürich (18.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 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
Anton Aylward wrote:
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.
Ah, I thought you were talking about reducing the number of modules at install time, sorry.
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 ...
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. -- Per Jessen, Zürich (8.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- 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
В Wed, 22 Apr 2015 09:34:08 -0400 Anton Aylward <opensuse@antonaylward.com> пишет:
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.
It should become better post-13.2. -- 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 composed on 2015-04-22 09:34 (UTC-0400):
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.
In TW this problem should be gone: https://bugzilla.opensuse.org/show_bug.cgi?id=881780 In the mean time I reduce the annoyance of repeats by, prior to a normal updates run, doing a zypper in on the installed packages that trigger the rebuilds in this 'zypstart' mini-script: zypper -v in zypper libzypp libsolv-tools rpm openSUSE-release zypper -v in device-mapper dmraid glibc lvm2 multipath-tools mdadm systemd udev -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- 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
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. -- 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/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 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 -- 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 <hdf3@comcast.net> 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
On 04/17/2015 04:53 PM, don fisher wrote:
Sorry if I offended.
Indeed. What "offends" me is that this and all you subsequently say is available for a little effort researching, not just the suse site but any number of background articles, heck, even at CNET!
The last time I was involved one built their own kernels by default, just to get all of the devices running.
When was that? Ver 0.98? We've had pre-built for ... What, since the beginning of the century? Loadable kernel modules since ... Well for more than a decade. See "The Linux Kernel Module Programming Guide" http://www.tldp.org/LDP/lkmpg/2.6/html/ though google shows me version of articles on LKM that going back as far as 1991.
I assumed you had done that also, until I clicked on your link and saw the prebuilt RPMs.
Right. But you're supposed to install that, and other such, as repertoires so that Yast and Zypper work properly. As it happens, kernels are pretty much stand alone; dependencies, other than macros, are not an issue. Bit its a case of just because you can load the rpm directly) doesn't mean you should. If you start doing yes-but exceptions to good practices you'll get in the habit.
I was really trying to get an update on writing device drivers. In the past building the kernel was fundamental to that,
What past are you talking about? Something before 1990? As many vendors have found, you don't need to recompile the LKM device driver for every minor revision of the kernel. For example: I just did a director diff between the 3.19.3-1 and 3.19.4-1 kernel drivers for USB storage. (As an illustration. I'll leave a more comprehensive examination of whole trees to others). For many, the only difference is in the date stamps.
I see now that a new capability may allow a simpler path.
Which many of us have enjoyed for (at the very least) this century. -- 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
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
Per Jessen wrote:
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.
Forgot - install the kernel, rebuild the initrd, then update boot-loader. -- 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 Fri, Apr 17, 2015 at 2:13 PM, don fisher <hdf3@comcast.net> 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 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 .. -- 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 Fri, Apr 17, 2015 at 6:08 PM, Anton Aylward <opensuse@antonaylward.com> 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
On 04/17/2015 06:56 PM, Greg Freemyer wrote:
On Fri, Apr 17, 2015 at 6:08 PM, Anton Aylward <opensuse@antonaylward.com> 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.
Indeed. I meant that I wasn't obsessive about updating for the slightest change. many of the changes either don't affect me, or, as I see in the BtrFS list, are so slight and 'fringe-case' to my work-flow that if I updated (and with BtrFS I'd have to rebuild) for every one I'd never get regular work done. At least with kernel:stable I can limit my updates to one a week or less :-) -- Dear Lord: Please make my words sweet and tender, for tomorrow I may have to eat them. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, I have a minor issue (probably a bug) with kernel 4.0.0-3 installed two days ago from the kernel repo. The problem is that ping to an unreachable host shows a warning for kernel upgrade. # ping 172.24.24.8 PING 172.24.24.8 (172.24.24.8) 56(84) bytes of data. WARNING: kernel is not very fresh, upgrade is recommended. - From 172.24.24.121: icmp_seq=2 Destination Host Unreachable Can someone else to confirm the same ? Googling about this warning shows that the same error has been reported back in 2002 on the RedHat bugzilla. The ticket however is closed as the error cannot be reproduced with more recent kernels and indeed ping to the same host with 3.11 or 3.12 shows only destination host unreachable starting from icmp_seq=1. Regards, I. Petrov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVPrZEAAoJEH8sJoKRFRU57xsQAIdVBWeb54ABpbS7mfIoFkFb DmDbGP7RnNrtpG4Nr7U5lvBtEA4WQ6iYTUmWyumKxsHwKEZbl8SfetqWjDDF3RZU fTJ0pNrIOgvmyoCybClBl1AKEhTRc4MniBc1Wg1SlwXf/Doju27QRHPDHcXF3fVv 56OnZiWQO1hfaj6zCTQEE6765MjIrcJxelCI+HVxp1G9MhBw8/rHlfrrq4Khs9N0 k2R5cLwj88zOHP2OSFY9TXGy1CnmzPrmanB0mWBrB9sNhnRhEokBFWlHhD0k4Wnx CoQHkyGdIQfEMmU0hQMQXs6XgmuW7iITI3zY8+bYZFjWcENLphRjAgEKDrvtbROc yYlwdbKeNBlkCWGfOCwaVqD4AL6OhvZO+dmT93MuoU5tSypsQYmt0tyI82d/+aPj FfjZc+oFJon6+IESbTATajLnXpMuq4XEaYK0ASXBVUzvTE+3MHWEuZg43/goCEQk gApetla37cGdQhfyYROZowqf136eBxaHVglcUEuArJkR2sJuHIjZAZMBT/B1qz7k w9MxitPFZf9Rywrta2/+YR4zDA7iYIQrCTcSgtqckuOj1kZGrLXsOptNPiLdwv6/ klRcXCdjMqJjFMILaJCvH3TWRwxGs17y9/UpzwPSrlwMGV/y1bXwsHHF6zm2SB1C O49kyNmnIXAoitjbR/EN =ejOc -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (11)
-
Andrei Borzenkov -
Anton Aylward -
David C. Rankin -
don fisher -
Felix Miata -
Greg Freemyer -
I.Petrov -
John Andersen -
Linda Walsh -
Markus Koßmann -
Per Jessen