Re: building 2.6.35
On Sun, Aug 15 2010, Stephen Powell wrote: On Sun, 15 Aug 2010 13:53:41 -0400 (EDT), Manoj Srivastava wrote: With the new versions of kernel-package in Squeeze, running make-kpkg clean should almost never be required (if the upstream Makefiles are not borked, as they rarely are). The new make-kpkg starts by removing and re-creating ./debian almost always, so the explicit clean is redundant. That would imply that things like --append-to-version and --revision must be specified on every invocation, correct? One cannot, for example, specify --append-to-version and --revision with the kernel_image target and then leave them off with a subsequent invocation for the modules_image target. Yes, that is one unfortunate consequence of the change. However, I just hit up arrow, since I usually build my kernel and modules pretty much at the same time, so it is usually not that onerous (I also use a shell script that uses the same VERSION AND REVISION VALUES, WHICH MAKES IT EVEN LESS OF AN HEADACHE) MANOJ -- Either I'm dead or my watch has stopped. Groucho Marx's last words Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ocd3j9jf@anzu.internal.golden-gryphon.com
Re: building 2.6.35
On Jo, 12 aug 10, 11:10:16, Arthur Machlas wrote: Isn't there a risk in granting user access to src, adm, and such if ever your user account is compromised? My uninformed opinion is that it's a question of relative risk; the 'risk' involved in building kernels as root, versus the risk involved in giving access to these dirs and tools should your account become compromised. If that user account is used to gain root privileges then it doesn't really matter, it's not very difficult to trick the user to give out the root password (something like a fake 'su' or 'sudo' prompt). Regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: building 2.6.35
Hey. On Sun, Aug 15, 2010 at 1:29 AM, Stephen Powell zlinux...@wowway.com wrote: snippy I don't think that this is a bug. I think you're trying to mix and match two different ways of doing things. There are two basic ways of creating an out-of-kernel-source-tree module from source: (1) install the kernel headers and compile the out-of-kernel-source-tree module from source using the kernel headers, and (2) if you have the whole kernel source tree installed, compile using the kernel source. What you're doing is creating a kernel header package from the kernel source and then using method (1), when you should be using method (2). I spent the better part of the day today playing around with this. Perhaps the results of my experiment will prove instructive in some way. That makes scene I suppose, shouldn’t need headers if you have the whole source, I shall have to-do some research into how to build out of source tree modules against the main source. But at the same time, with the kernel headers installed, it should build against them, shouldn’t it? And without fixing that symlink I cant build the vbox modules via DKMS and the blobs installer fails :/ snippy The moral of the story is that you don't need (or shouldn't need) kernel header packages if you have the whole kernel source code installed. Note that I didn't use module-assistant or kernel headers. -- .''`. Stephen Powell : :' : `. `'` `- Cheers! Angus. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimwah3fsrwsqygfn1aeppyw8k=sqfjlcszzd...@mail.gmail.com
Re: building 2.6.35
Hey, Sorry for the double, but forgot something! On Sun, Aug 15, 2010 at 1:29 AM, Stephen Powell zlinux...@wowway.com wrote: snippy $ make-kpkg --append-to-version -custom5-686 --revision 2.6.32-18 \ --initrd --rootcmd fakeroot kernel_image modules_image Quick question, is there an advantage to building a modules_image .deb rather than having it build into the kernel? snippy -- .''`. Stephen Powell : :' : `. `'` `- Regards, Angus -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=6puwpbzgwtocfg_nuibmkujgnklvgwwkvb...@mail.gmail.com
Re: building 2.6.35
On Sun, 15 Aug 2010 05:27:12 -0400 (EDT), Angus Hedger wrote: On Sun, Aug 15, 2010 at 1:29 AM, Stephen Powell wrote: ... $ make-kpkg --append-to-version -custom5-686 --revision 2.6.32-18 \ --initrd --rootcmd fakeroot kernel_image modules_image ... Quick question, is there an advantage to building a modules_image .deb rather than having it build into the kernel? If you copy your module directly into the source tree, then you need to download a new kernel source tree and unpack it due to kernel maintenance, you lose your modifications. By keeping the out-of-kernel- source-tree modules in a separate directory, /usr/src/modules/..., you don't lose your modifications. You download and unpack the new kernel source, rebuild both packages, and install both packages. Simple. P.S. Angus: sorry for the inadvertent private e-mail earlier. I accidentally clicked on the wrong button. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1095580591.103338.1281876010970.javamail.r...@md01.wow.synacor.com
Re: building 2.6.35
On Sun, Aug 15, 2010 at 1:40 PM, Stephen Powell zlinux...@wowway.com wrote: On Sun, 15 Aug 2010 05:27:12 -0400 (EDT), Angus Hedger wrote: On Sun, Aug 15, 2010 at 1:29 AM, Stephen Powell wrote: ... $ make-kpkg --append-to-version -custom5-686 --revision 2.6.32-18 \ --initrd --rootcmd fakeroot kernel_image modules_image ... Quick question, is there an advantage to building a modules_image .deb rather than having it build into the kernel? If you copy your module directly into the source tree, then you need to download a new kernel source tree and unpack it due to kernel maintenance, you lose your modifications. By keeping the out-of-kernel- source-tree modules in a separate directory, /usr/src/modules/..., you don't lose your modifications. You download and unpack the new kernel source, rebuild both packages, and install both packages. Simple. P.S. Angus: sorry for the inadvertent private e-mail earlier. I accidentally clicked on the wrong button. -- .''`. Stephen Powell : :' : `. `'` `- Hey, That makes a lot of sense, thanks for that! Regards, Angus ps, Dont worry about it! (I keep almost doing the same thing due to the daft way gmail handles replying to mailing lists via the web ui) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=wmqte_lh=le4xyjhf=vpc2ni0wthczthgu...@mail.gmail.com
Re: building 2.6.35
On Sun, 15 Aug 2010 09:11:21 -0400 (EDT), Angus Hedger wrote: Stephen Powell wrote: If you copy your module directly into the source tree, then you need to download a new kernel source tree and unpack it due to kernel maintenance, you lose your modifications. By keeping the out-of-kernel- source-tree modules in a separate directory, /usr/src/modules/..., you don't lose your modifications. You download and unpack the new kernel source, rebuild both packages, and install both packages. Simple. That makes a lot of sense, thanks for that! Official Debian packages designed to be compiled as source and used as out-of-kernel-source-tree kernel modules are generally packaged in such a way that they can be installed and used either way, either by installing kernel headers and compiling using just the headers, or compiled using a kernel source package. For example, see the /usr/share/doc/nvidia-kernel-*source/README.Debian file in the various nvidia kernel source module packages. This file documents both compilation and installation methods and you can choose the one that suits your particular environment best. On the other hand, if you are downloading upstream source directly from the upstream site and following their installation procedure, they may give you a one size fits all installation procedure that requires kernel headers. That's one reason why it is best to use official Debian packages whenever possible. The Debian packages have been customized by the Debian package maintainer to do things the Debian way. As I say in my kernel- building web page, there are three ways to do everything: the right way, the wrong way, and the Debian way! -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1371450646.109819.1281894198479.javamail.r...@md01.wow.synacor.com
Re: building 2.6.35
On Sat, Aug 14 2010, Stephen Powell wrote: Oops! I forgot to show the make-kpkg clean step after make menuconfig. I'm not sure if this is still needed anymore, but it's good practice. In real life, I did issue it; but when I composed the e-mail, I forgot to document it. With the new versions of kernel-package in Squeeze, running make-kpkg clean should almost never be required (if the upstream Makefiles are not borked, as they rarely are). The new make-kpkg starts by removing and re-creating ./debian almost always, so the explicit clean is redundant. manoj -- A kid'll eat the middle of an Oreo, eventually. Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87eidzlq3e@anzu.internal.golden-gryphon.com
Re: building 2.6.35
On Sun, 15 Aug 2010 13:53:41 -0400 (EDT), Manoj Srivastava wrote: With the new versions of kernel-package in Squeeze, running make-kpkg clean should almost never be required (if the upstream Makefiles are not borked, as they rarely are). The new make-kpkg starts by removing and re-creating ./debian almost always, so the explicit clean is redundant. That would imply that things like --append-to-version and --revision must be specified on every invocation, correct? One cannot, for example, specify --append-to-version and --revision with the kernel_image target and then leave them off with a subsequent invocation for the modules_image target. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1972237850.112409.1281903895526.javamail.r...@md01.wow.synacor.com
Re: building 2.6.35
On Fri, 13 Aug 2010 15:12:02 -0400 (EDT), Angus Hedger wrote: The two things that i use k-headers for myself are the nvidia blob, and the virtual-box km's The only issues I ran into when building headers via make-kpkg where as follows, Make sure you use the same -append-to-version -stuff-here line as you do when building your kernel, or they wont match up and it wont find the k-headers. And, I have found that the packages made by make-kpkg are setting the wrong /lib/modules/kernel version/build symlink, pointing it to my the dir where i build the kernel rather than the correct /usr/src/kernel headers dir. (I think i need to bug report the 2nd, but I don't know if its something I am doing wrong). I don't think that this is a bug. I think you're trying to mix and match two different ways of doing things. There are two basic ways of creating an out-of-kernel-source-tree module from source: (1) install the kernel headers and compile the out-of-kernel-source-tree module from source using the kernel headers, and (2) if you have the whole kernel source tree installed, compile using the kernel source. What you're doing is creating a kernel header package from the kernel source and then using method (1), when you should be using method (2). I spent the better part of the day today playing around with this. Perhaps the results of my experiment will prove instructive in some way. I have a computer, i386 architecture, which runs Debian Squeeze. It has an Nvidia video card with a RIVA TNT2 chipset. It currently runs a stock Debian kernel (linux-image-2.6.32-5-686, version 2.6.32-18) and it uses the nv driver for X (xserver-xorg-video-nv, version 1:2.1.17-3). I can't use the nouveau driver, unfortunately, because interlaced video modes do not work with the nouveau driver and my CRT monitor requires interlaced video modes to operate at its maximum resolution due to its low maximum pixel clock rate.) I decided to build a custom kernel and at the same time attempt to activate the proprietary nvidia driver. I really didn't need or want to do either one, but for the sake of making my kernel-building web page more useful, I decided to do this exercise. Here is what I did. The first step was to figure out which kernel source packages I needed. For the kernel source code, that was easy: linux-source-2.6.32. But for the nvidia kernel module source package, that took a little research. It turns out that for a video card with the RIVA TNT2 chipset, the correct answer is nvidia-kernel-legacy-71xx-source. I looked at the bug reports for the corresponding Debian source package, nvidia-graphics-drivers-legacy-71xx, and was disheartened. Bug number 543248 looked like it was going to be a show stopper. But for the sake of the academic exercise, I pressed on. The first problem is that nvidia-kernel-legacy-71xx-source exists only in Sid. And I run Squeeze. So I had to update some apt files. First, I edited /etc/apt/sources.list. -- $ cd /etc/apt $ su # cat sources.list deb ftp://ftp.uwsg.indiana.edu/linux/debian squeeze main non-free contrib deb-src ftp://ftp.uwsg.indiana.edu/linux/debian squeeze main non-free contrib deb http://security.debian.org/ squeeze/updates main non-free contrib deb-src http://security.debian.org/ squeeze/updates main non-free contrib # vi sources.list [editing commands not shown] # cat sources.list deb ftp://ftp.uwsg.indiana.edu/linux/debian squeeze main non-free contrib deb-src ftp://ftp.uwsg.indiana.edu/linux/debian squeeze main non-free contrib deb http://security.debian.org/ squeeze/updates main non-free contrib deb-src http://security.debian.org/ squeeze/updates main non-free contrib deb ftp://ftp.uwsg.indiana.edu/linux/debian sid main non-free contrib deb-src ftp://ftp.uwsg.indiana.edu/linux/debian sid main non-free contrib # -- As you can see, I added two lines to the end to define the sid release. But I only wanted packages from sid that I explicitly ask for. I didn't want a massive update. So I created a couple of extra files. I will simply show you their contents. -- # cat apt.conf APT::Default-Release squeeze; # cat preferences Package: * Pin: release a=sid Pin-Priority: 1 # -- Note: I've heard that synaptic does not respect these files, but I have no independent verification of that. aptitude and apt-get do honor it, however. Anyway, moving on ... -- # aptitude update [since sources.list, et al, were changed] # aptitude install linux-source-2.6.32 # aptitude -t sid -R install nvidia-kernel-legacy-71xx-source # aptitude install kernel-package fakeroot libncurses5-dev # exit $ cd /usr/src $ tar -xjf linux-source-2.6.32.tar.bz2 $ rm linux-source-2.6.32.tar.bz2 $ tar -xzf nvidia-kernel-legacy-71xx-source.tar.gz $ rm nvidia-kernel-legacy-71xx-source.tar.gz -- Note: the rm commands both give the following warning message: rm: remove write-protected regular file file name? That's
Re: building 2.6.35
On Sat, 14 Aug 2010 20:29:11 -0400 (EDT), Stephen Powell wrote: -- $ cd linux-source-2.6.32 $ cp /boot/config-2.6.32-5-686 .config $ make menuconfig $ make-kpkg --append-to-version -custom5-686 --revision 2.6.32-18 \ --initrd --rootcmd fakeroot kernel_image modules_image $ cd .. $ su # dpkg -i linux-image-2.6.32-custom5-686_2.6.32-18_i386.deb # aptitude install nvidia-kernel-common # dpkg -i nvidia-kernel-legacy-71xx-2.6.32-custom5-686_71.86.13-1+2.6.32-18_i386.deb # dpkg-reconfigure linux-image-2.6.32-custom5-686 [not sure if needed, but ...] # shutdown -r now;exit -- Oops! I forgot to show the make-kpkg clean step after make menuconfig. I'm not sure if this is still needed anymore, but it's good practice. In real life, I did issue it; but when I composed the e-mail, I forgot to document it. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2111864047.99860.1281833674443.javamail.r...@md01.wow.synacor.com
Re: building 2.6.35
On Fri, Aug 13, 2010 at 1:29 AM, Alexander Samad a...@samad.com.au wrote: Hi Well its still doesn't work. I am trying to build the VB kernel modules and well it fails. I need to build the linux-kbuild-2.6.35, working with linux-source just doesn't work ... (I don't want to build a new linux-image) Alex On Wed, Aug 11, 2010 at 6:19 PM, Alexander Samad a...@samad.com.au wrote: [snip] What do I need to do :) Maybe this will help... The make headers_install command exports the kernel's header files in a form suitable for use by userspace programs. The kernel header files can be generated from the kernel sources. Define INSTALL_HDR_PATH= for output location. http://www.mjmwired.net/kernel/Documentation/make/headers_install.txt so for clarity install linux-image-2.6.35-trunk-amd64 linux-source-2.6.35 tar jxf /usr/src/linux-source-2.6.35.tar.bz2 cp /boot/config-2.6.35-trunk-amd64 /usr/src/linux-source-2.6.35/.config make oldconfig make headers_install should have me done :) A Debian source package for 2.6.35 is also available in experimental: linux-source-2.6.35. Hey If you are having problems with the VB modules, check the /lib/modules/kernel version/build Symlink, I have found that for some reason it keeps pointing to the src dir that i built the kernel from rather than the header files. Regards, Angus. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikog+9af9-xcfwcmj6x=wu=evajqd1begm_e...@mail.gmail.com
Re: building 2.6.35
On Thu, 12 Aug 2010 13:25:50 -0400 (EDT), Bob Proulx wrote: Stephen Powell wrote: Still, I should have noticed that the /usr/src directory was owned by user root and by group src. For some reason, I never made that connection. That's a great tip, thanks. I will have to play around with this. If I can get everything to work, then the next revision of my kernel building web page will be revised accordingly. Don't berate yourself. There is too much information in the universe to know all of it! Only by working together can we manage to get a handle on even a small fraction of it. How true! I have revised my kernel building web page based on your recommendations (http://www.wowway.com/~zlinuxman/Kernel.htm) to recommend building the kernel as a non-root user. Let me know what you think. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/160880533.67630.1281705950445.javamail.r...@md01.wow.synacor.com
Re: building 2.6.35
On Thu, 12 Aug 2010 13:55:40 -0400 (EDT), Sven Joachim wrote: Stephen Powell wrote: I do know about groups, but I don't necessarily know the intended purpose of all of the pre-defined groups in a Linux system. Where can I find documentation for that? For Debian, there is some information in the /usr/share/doc/base-passwd/ directory. Thanks, Sven! That's exactly the kind of information I was looking for! -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2134936844.67856.1281706339189.javamail.r...@md01.wow.synacor.com
Re: building 2.6.35
On Thu, 12 Aug 2010 12:34:34 -0400 (EDT) Stephen Powell zlinux...@wowway.com wrote: ... says! I suppose the most secure method would be to create an id just for kernel building which is a member of group src and its login group, and that's it. How about copying the source to an unprivileged location, assuming you have the space? Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100813101133.c12c6401.cele...@gmail.com
Re: building 2.6.35
On Fri, 13 Aug 2010 10:11:33 -0400 (EDT), Celejar wrote: On Thu, 12 Aug 2010 12:34:34 -0400 (EDT), Stephen Powell wrote: ... I suppose the most secure method would be to create an id just for kernel building which is a member of group src and its login group, and that's it. How about copying the source to an unprivileged location, assuming you have the space? Yes, that is an option also; but it too has drawbacks, especially if you are building out-of-kernel-source-tree module packages in addition to your kernel package. Here's an excerpt from one of my previous posts on this thread: (3) If I am using out-of-kernel-source-tree module source packages, I have to copy them too. By default, the source code installs to /usr/src/modules, I think. All the same issues arise here. And then I have to use the $MODULE_LOC environment variable to tell make-kpkg where to find the module source code. More overrides. It's just simpler to be root and do everything in its default location. Then of course there are disk space requirements, if the source is copied instead of moved. Every solution breeds more problems. (author unknown) The latest version of my kernel building web page, revised yesterday (http://www.wowway.com/~zlinuxman/Kernel.htm), recommends unpacking, configuring, and compiling the kernel from its default location as a non-root user which is a member of group src. It can be the system administrator's non-superuser self or an id created specifically for kernel building that is enrolled in group src, at the administrator's discretion. I have tested the procedure, and it works. That's my current recommendation. Obviously, you are entitled to disagree if you like. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/486864869.70489.1281712665351.javamail.r...@md01.wow.synacor.com
Re: building 2.6.35
The latest version of my kernel building web page, revised yesterday (http://www.wowway.com/~zlinuxman/Kernel.htm), recommends unpacking, configuring, and compiling the kernel from its default location as a non-root user which is a member of group src. It can be the system administrator's non-superuser self or an id created specifically for kernel building that is enrolled in group src, at the administrator's discretion. I have tested the procedure, and it works. That's my current recommendation. Obviously, you are entitled to disagree if you like. It's a pretty great document Stephen, and I don't think I mentioned earlier that it was my first and authoritative reference when first starting to build kernels, for exactly the reason you noted, much documentation is out-of-date or not debian specific. So thanks for that, belatedly. One thing I think is missing, that I had to discover myself, and perhaps is related to the OPs question, is that sometimes you need the headers and even the source for the custom kernels, e.g., Virtualbox from upstream. In which case, adding kernel_headers and/or kernel_source to the make-kpkg build line is a noteworthy item, since it will build debs' and take care of installing them correctly without linking back to the build directory when searching for source. Best, AM -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikefal 6oacqw9j_pe03fqr6wgyeymmkru...@mail.gmail.com
Re: building 2.6.35
On Fri, 13 Aug 2010 13:27:50 -0400 (EDT), Arthur Machlas wrote: Stephen Powell wrote: The latest version of my kernel building web page, revised yesterday (http://www.wowway.com/~zlinuxman/Kernel.htm), recommends unpacking, configuring, and compiling the kernel from its default location as a non-root user which is a member of group src. It can be the system administrator's non-superuser self or an id created specifically for kernel building that is enrolled in group src, at the administrator's discretion. I have tested the procedure, and it works. That's my current recommendation. Obviously, you are entitled to disagree if you like. It's a pretty great document Stephen, and I don't think I mentioned earlier that it was my first and authoritative reference when first starting to build kernels, for exactly the reason you noted, much documentation is out-of-date or not debian specific. So thanks for that, belatedly. One thing I think is missing, that I had to discover myself, and perhaps is related to the OPs question, is that sometimes you need the headers and even the source for the custom kernels, e.g., Virtualbox from upstream. In which case, adding kernel_headers and/or kernel_source to the make-kpkg build line is a noteworthy item, since it will build debs' and take care of installing them correctly without linking back to the build directory when searching for source. That is valuable real-world feedback from a real-world user, Arthur. I will see what I can do to improve the document in this respect. I haven't done anything like that myself; so if you have some suggested wording that you would like to see added, tell me what and where, and we'll go from there. I would also like to add an out-of-kernel-source-tree modules example. It has been a long time since I did anything with out-of-kernel-source-tree stuff. The last time I did something like that was back in the days when the pcmcia drivers and the alsa drivers were not yet integrated into the main kernel source tree. And that was about ten years ago, I think. Much has changed in the world of kernel building since then. But we now have things like the proprietary nvidia kernel module and proprietary kernel modules for win-modems that can be used as examples. I have occasion to use both of those examples with my current hardware. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1562182024.75394.1281725183907.javamail.r...@md01.wow.synacor.com
Re: building 2.6.35
On Fri, Aug 13, 2010 at 7:46 PM, Stephen Powell zlinux...@wowway.com wrote: On Fri, 13 Aug 2010 13:27:50 -0400 (EDT), Arthur Machlas wrote: Stephen Powell wrote: The latest version of my kernel building web page, revised yesterday (http://www.wowway.com/~zlinuxman/Kernel.htm), recommends unpacking, configuring, and compiling the kernel from its default location as a non-root user which is a member of group src. It can be the system administrator's non-superuser self or an id created specifically for kernel building that is enrolled in group src, at the administrator's discretion. I have tested the procedure, and it works. That's my current recommendation. Obviously, you are entitled to disagree if you like. It's a pretty great document Stephen, and I don't think I mentioned earlier that it was my first and authoritative reference when first starting to build kernels, for exactly the reason you noted, much documentation is out-of-date or not debian specific. So thanks for that, belatedly. One thing I think is missing, that I had to discover myself, and perhaps is related to the OPs question, is that sometimes you need the headers and even the source for the custom kernels, e.g., Virtualbox from upstream. In which case, adding kernel_headers and/or kernel_source to the make-kpkg build line is a noteworthy item, since it will build debs' and take care of installing them correctly without linking back to the build directory when searching for source. That is valuable real-world feedback from a real-world user, Arthur. I will see what I can do to improve the document in this respect. I haven't done anything like that myself; so if you have some suggested wording that you would like to see added, tell me what and where, and we'll go from there. I would also like to add an out-of-kernel-source-tree modules example. It has been a long time since I did anything with out-of-kernel-source-tree stuff. The last time I did something like that was back in the days when the pcmcia drivers and the alsa drivers were not yet integrated into the main kernel source tree. And that was about ten years ago, I think. Much has changed in the world of kernel building since then. But we now have things like the proprietary nvidia kernel module and proprietary kernel modules for win-modems that can be used as examples. I have occasion to use both of those examples with my current hardware. -- .''`. Stephen Powell : :' : `. `'` `- Hey, The two things that i use k-headers for myself are the nvidia blob, and the virtual-box km's The only issues I ran into when building headers via make-kpkg where as follows, Make sure you use the same -append-to-version -stuff-here line as you do when building your kernel, or they wont match up and it wont find the k-headers. And, I have found that the packages made by make-kpkg are setting the wrong /lib/modules/kernel version/build symlink, pointing it to my the dir where i build the kernel rather than the correct /usr/src/kernel headers dir. (I think i need to bug report the 2nd, but I don't know if its something I am doing wrong). This is the line i used to build my last load of headers, # make-kpkg kernel_headers --append-to-version -2.6.35amd64-bfq-iowait -j3 Cheers for all your work on that very useful document, Regards, Angus -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktiki4ekvdm1ap6e2=w5krvy7mlc10qanquhox...@mail.gmail.com
Re: building 2.6.35
On Fri, Aug 13, 2010 at 2:12 PM, Angus Hedger demide...@gmail.com wrote: On Fri, Aug 13, 2010 at 7:46 PM, Stephen Powell zlinux...@wowway.com wrote: On Fri, 13 Aug 2010 13:27:50 -0400 (EDT), Arthur Machlas wrote: The only issues I ran into when building headers via make-kpkg where as follows, Make sure you use the same -append-to-version -stuff-here line as you do when building your kernel, or they wont match up and it wont find the k-headers. And, I have found that the packages made by make-kpkg are setting the wrong /lib/modules/kernel version/build symlink, pointing it to my the dir where i build the kernel rather than the correct /usr/src/kernel headers dir. (I think i need to bug report the 2nd, but I don't know if its something I am doing wrong). This is the line i used to build my last load of headers, # make-kpkg kernel_headers --append-to-version -2.6.35amd64-bfq-iowait -j3 You can just put them all on the same line, i.e., make-kpkg --append-to-version -2.635amd64_custom kernel_image kernel_headers kernel_source I don't use the -j3 switch, and I don't think that -j3 switch works like you think it does when using make-kpkg, at least, not if that's meant to utilize multiple processors when building. I'm at work right so this is all from memory, but I think the correct way to do it is to do export CONCURRENCY_LEVEL=3 where the number you provide is 1 + the number of processors you have. So if you have a duo-core, it's 3. If a single processor it would be two. And so forth. I seem to recall something in the make-kpkg documentation saying not to use the -j switch. Hopefully someone will correct me or provide more authoritative sources than this sorry excuse for a memory I have. As for your sources bug being symlinked incorrectly, I think I can confirm, however it hasn't negatively affected anything. Things still build properly against the headers / sources on custom kernels even when the build directory in my home dir is removed. But yes, I'm pretty sure I've seen warnings about it not being able to find sources in /home/arthur/linux/kernel/2.6.35/, though they are just strange warnings and I haven't bothered looking into it further since everything seems to still work fine. Best, AM -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=rbhqn7uskda3lf1g67yqpqs2cquvwumgw8...@mail.gmail.com
Re: building 2.6.35
Hey! On Fri, 13 Aug 2010 13:27:50 -0400 (EDT), Arthur Machlas wrote: The only issues I ran into when building headers via make-kpkg where as follows, Make sure you use the same -append-to-version -stuff-here line as you do when building your kernel, or they wont match up and it wont find the k-headers. And, I have found that the packages made by make-kpkg are setting the wrong /lib/modules/kernel version/build symlink, pointing it to my the dir where i build the kernel rather than the correct /usr/src/kernel headers dir. (I think i need to bug report the 2nd, but I don't know if its something I am doing wrong). This is the line i used to build my last load of headers, # make-kpkg kernel_headers --append-to-version -2.6.35amd64-bfq-iowait -j3 You can just put them all on the same line, i.e., make-kpkg --append-to-version -2.635amd64_custom kernel_image kernel_headers kernel_source Thanks for that! Will save me quite a bit of time. I don't use the -j3 switch, and I don't think that -j3 switch works like you think it does when using make-kpkg, at least, not if that's meant to utilize multiple processors when building. I'm at work right so this is all from memory, but I think the correct way to do it is to do export CONCURRENCY_LEVEL=3 where the number you provide is 1 + the number of processors you have. So if you have a duo-core, it's 3. If a single processor it would be two. And so forth. I seem to recall something in the make-kpkg documentation saying not to use the -j switch. As far as i know, -j3 sets that option just for this instance of make-kpkg, I think i got it off the man page! Oh here we go: man kpkg --jobs number -j number Set the environment variable CONCURRENCY_LEVEL to number. I have a quad but use -j3 as I have to run other cpu heavy tasks while compiling and that stops my whole computer from slowing right down! Hopefully someone will correct me or provide more authoritative sources than this sorry excuse for a memory I have. As for your sources bug being symlinked incorrectly, I think I can confirm, however it hasn't negatively affected anything. Things still build properly against the headers / sources on custom kernels even when the build directory in my home dir is removed. But yes, I'm pretty sure I've seen warnings about it not being able to find sources in /home/arthur/linux/kernel/2.6.35/, though they are just strange warnings and I haven't bothered looking into it further since everything seems to still work fine. I had problems building both the nvidia blob and the vbox kernel modules unless i fixed the symlink. Best, AM Cheers! Angus. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikt_vbiuk=cafa6myu-ozgjpv6zpx9nwkwe+...@mail.gmail.com
Re: building 2.6.35
On Fri, Aug 13, 2010 at 4:28 PM, Angus Hedger demide...@gmail.com wrote: Hey! I don't use the -j3 switch, and I don't think that -j3 switch works like you think it does when using make-kpkg, at least, not if that's meant to utilize multiple processors when building. I'm at work right so this is all from memory, but I think the correct way to do it is to do export CONCURRENCY_LEVEL=3 where the number you provide is 1 + the number of processors you have. So if you have a duo-core, it's 3. If a single processor it would be two. And so forth. I seem to recall something in the make-kpkg documentation saying not to use the -j switch. As far as i know, -j3 sets that option just for this instance of make-kpkg, I think i got it off the man page! Oh here we go: man kpkg --jobs number -j number Set the environment variable CONCURRENCY_LEVEL to number. I have a quad but use -j3 as I have to run other cpu heavy tasks while compiling and that stops my whole computer from slowing right down! And thanks for that authoritative clarification! Best, AM -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktik+objypzh2euuutkbk1stxogconu70vq+f9...@mail.gmail.com
Re: building 2.6.35
On Wed, 11 Aug 2010 17:33:12 -0400 (EDT), Bob Proulx wrote: If it is your own machine then you should certainly be in the 'src' group and then you would have access to /usr/src as your own normal user self. And if you don't know about src then you probably don't know about 'staff' and 'adm' either. The staff group gets you access to /usr/local and adm gets you read-only browsing capability to /var/log/*. You probably want all three. $ sudo adduser zlinuxman adm $ sudo adduser zlinuxman src $ sudo adduser zlinuxman staff Then log out. At login you will be set to those additional groups. With those in place you can work as yourself in those areas. Safer than using root since as yourself you can't smash anything in the system directories /etc or /bin or /var or other system locations. This makes installing local software through 'make install' much safer and more contained when not done as root. If one were to crawl out of /usr/local for example you would see the failure. If you were running as root then you would not. I do know about groups, but I don't necessarily know the intended purpose of all of the pre-defined groups in a Linux system. Where can I find documentation for that? Still, I should have noticed that the /usr/src directory was owned by user root and by group src. For some reason, I never made that connection. That's a great tip, thanks. I will have to play around with this. If I can get everything to work, then the next revision of my kernel building web page will be revised accordingly. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/399638650.38733.1281620510281.javamail.r...@md01.wow.synacor.com
Re: building 2.6.35
On Thu, Aug 12, 2010 at 8:41 AM, Stephen Powell zlinux...@wowway.com wrote: On Wed, 11 Aug 2010 17:33:12 -0400 (EDT), Bob Proulx wrote: Then log out. At login you will be set to those additional groups. With those in place you can work as yourself in those areas. Safer than using root since as yourself you can't smash anything in the system directories /etc or /bin or /var or other system locations. This makes installing local software through 'make install' much safer and more contained when not done as root. If one were to crawl out of /usr/local for example you would see the failure. If you were running as root then you would not. Isn't there a risk in granting user access to src, adm, and such if ever your user account is compromised? My uninformed opinion is that it's a question of relative risk; the 'risk' involved in building kernels as root, versus the risk involved in giving access to these dirs and tools should your account become compromised. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikqrfh+fg3zvs3qynpmfieskpzes0j-sw_t=...@mail.gmail.com
Re: building 2.6.35
On Thu, 12 Aug 2010 12:10:16 -0400 (EDT), Arthur Machlas wrote: On Wed, 11 Aug 2010 17:33:12 -0400 (EDT), Bob Proulx wrote: Then log out. At login you will be set to those additional groups. With those in place you can work as yourself in those areas. Safer than using root since as yourself you can't smash anything in the system directories /etc or /bin or /var or other system locations. This makes installing local software through 'make install' much safer and more contained when not done as root. If one were to crawl out of /usr/local for example you would see the failure. If you were running as root then you would not. Isn't there a risk in granting user access to src, adm, and such if ever your user account is compromised? My uninformed opinion is that it's a question of relative risk; the 'risk' involved in building kernels as root, versus the risk involved in giving access to these dirs and tools should your account become compromised. Obviously, the more groups an id is a member of, the more harm that id can do in the hands of a malicious (or foolish) user. And that's one reason why I can't make everyone happy no matter what my web page says! I suppose the most secure method would be to create an id just for kernel building which is a member of group src and its login group, and that's it. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1411985608.44786.1281630874966.javamail.r...@md01.wow.synacor.com
Re: building 2.6.35
On 2010-08-12 18:10 +0200, Arthur Machlas wrote: Isn't there a risk in granting user access to src, adm, and such if ever your user account is compromised? This depends on how the computer is used, I suppose. On personal desktops/laptops, giving intruders access to these groups is the least of your worries, because your private data are 1000 times more sensitive. My uninformed opinion is that it's a question of relative risk; the 'risk' involved in building kernels as root, versus the risk involved in giving access to these dirs and tools should your account become compromised. The kernel releases are cryptographically signed¹, and it is certainly a good idea to verify them before building and installing a kernel. Sven ¹ http://www.kernel.org/signature.html -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y6cb4uhy@turtle.gmx.de
Re: building 2.6.35
Stephen Powell wrote: I do know about groups, but I don't necessarily know the intended purpose of all of the pre-defined groups in a Linux system. Where can I find documentation for that? Unfortunately I have no idea. I don't even know if they are all documented someplace. And distro to distro those will vary since they tend to be local administration conventions. Still, I should have noticed that the /usr/src directory was owned by user root and by group src. For some reason, I never made that connection. That's a great tip, thanks. I will have to play around with this. If I can get everything to work, then the next revision of my kernel building web page will be revised accordingly. Don't berate yourself. There is too much information in the universe to know all of it! Only by working together can we manage to get a handle on even a small fraction of it. Bob signature.asc Description: Digital signature
Re: building 2.6.35
On 2010-08-12 19:25 +0200, Bob Proulx wrote: Stephen Powell wrote: I do know about groups, but I don't necessarily know the intended purpose of all of the pre-defined groups in a Linux system. Where can I find documentation for that? Unfortunately I have no idea. I don't even know if they are all documented someplace. And distro to distro those will vary since they tend to be local administration conventions. For Debian, there is some information in the /usr/share/doc/base-passwd/ directory. Still, I should have noticed that the /usr/src directory was owned by user root and by group src. For some reason, I never made that connection. That's a great tip, thanks. I will have to play around with this. If I can get everything to work, then the next revision of my kernel building web page will be revised accordingly. Don't berate yourself. There is too much information in the universe to know all of it! Only by working together can we manage to get a handle on even a small fraction of it. Yes, even the base-passwd maintainers who keep the users and groups with ID 100 in sync across Debian installations have sometimes no clue what a specific group is or was good for. Here is what they say about the 'bin' and 'sys' groups: , | bin | | HELP: No files on my system are owned by user or group bin. What good are | they? Historically they were probably the owners of binaries in /bin? It is | not mentioned in the FHS, Debian Policy, or the changelogs of base-passwd | or base-files. | [...] | | sys | | HELP: As with bin, except I don't even know what it was good for | historically. ` Sven -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ocd74swz@turtle.gmx.de
Re: building 2.6.35
Arthur Machlas wrote: Bob Proulx wrote: With those in place you can work as yourself in those areas. Safer than using root since as yourself you can't smash anything in the system directories /etc or /bin or /var or other system locations. Isn't there a risk in granting user access to src, adm, and such if ever your user account is compromised? There is always a risk associated with *everything*. The only truly secure computer is one that has had the following procedure applied to it. http://www.roseweb.de/caro/pages/security/v-one/cut-orig.htm My uninformed opinion is that it's a question of relative risk; the 'risk' involved in building kernels as root, versus the risk involved in giving access to these dirs and tools should your account become compromised. My experience is that accidents cause problems much more often than active intrusions. Security is certainly important. But more important for me is to create an environment that enables productive use of the system while limiting the risk caused by accidents from authorized users. Safety nets against accidents are very useful. If you are yourself (non-root) working on a tool that you own in /usr/local/bin/foo and while testing make a mistake and get a message that you can't read/write/remove a file in /etc when you meant /usr/local/etc then there isn't any harm done. You know what you did and that it isn't a problem (since you are non-root and have no permissions to /etc) and you fix your error and move on. But if you are root and the same occurs you won't get a permission error but instead will have modified the underlying hosting system. You might not even know that you had done so. This is not about intrusion detection but one of accident prevention. But accidents happen much more often than intrusions. Bob signature.asc Description: Digital signature
Re: building 2.6.35
Hi Well its still doesn't work. I am trying to build the VB kernel modules and well it fails. I need to build the linux-kbuild-2.6.35, working with linux-source just doesn't work ... (I don't want to build a new linux-image) Alex On Wed, Aug 11, 2010 at 6:19 PM, Alexander Samad a...@samad.com.au wrote: [snip] What do I need to do :) Maybe this will help... The make headers_install command exports the kernel's header files in a form suitable for use by userspace programs. The kernel header files can be generated from the kernel sources. Define INSTALL_HDR_PATH= for output location. http://www.mjmwired.net/kernel/Documentation/make/headers_install.txt so for clarity install linux-image-2.6.35-trunk-amd64 linux-source-2.6.35 tar jxf /usr/src/linux-source-2.6.35.tar.bz2 cp /boot/config-2.6.35-trunk-amd64 /usr/src/linux-source-2.6.35/.config make oldconfig make headers_install should have me done :) A Debian source package for 2.6.35 is also available in experimental: linux-source-2.6.35. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimzpyistwnj7p9rtjx_uvpvq8xpx0emo9hqg...@mail.gmail.com
RE: building 2.6.35
Okay I have a working solution and set of steps Unfortunately I didn't keep the url where I got this. But it works, I have to change the changelog to 2.6.35 instead of 2.6.34 == How to build linux-kbuild-2.6 yourself Fetch the sources from SVN: svn co svn://svn.debian.org/kernel/dists/trunk/linux-kbuild-2.6 Then, fetch the vanilla kernel tarball (important: the 2.6.x version, no 2.6.x.y version): wget http://ftp.de.kernel.org/pub/linux/kernel/v2.6/linux-2.6.27.tar.bz2 Now, you can prepare the package: cd linux-kbuild-2.6 ./debian/bin/genorig.py ../linux-2.6.27.tar.bz2 cd .. tar xzf orig/linux-kbuild-2.6_2.6.27.orig.tar.gz cd linux-kbuild-2.6-2.6.27/ cp -a ../linux-kbuild-2.6/* ./ ./debian/bin/gencontrol.py dch -i Now adjust the version, and add a comment like New upstream version or something, and build the package itself, after you installed eventually missing build-dependencies: make -f debian/rules clean dpkg-checkbuilddeps dpkg-buildpackage -us -uc and you are done. [snip] -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/003701cb3a90$0400bd10$0c0237...@samad.com.au
Re: building 2.6.35
[snip] What do I need to do :) Maybe this will help... The make headers_install command exports the kernel's header files in a form suitable for use by userspace programs. The kernel header files can be generated from the kernel sources. Define INSTALL_HDR_PATH= for output location. http://www.mjmwired.net/kernel/Documentation/make/headers_install.txt so for clarity install linux-image-2.6.35-trunk-amd64 linux-source-2.6.35 tar jxf /usr/src/linux-source-2.6.35.tar.bz2 cp /boot/config-2.6.35-trunk-amd64 /usr/src/linux-source-2.6.35/.config make oldconfig make headers_install should have me done :) A Debian source package for 2.6.35 is also available in experimental: linux-source-2.6.35. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinlnucex7a+49f33xvhx1q0zpvhx7sujar-2...@mail.gmail.com
Re: building 2.6.35
On Tue, 10 Aug 2010 16:43:04 -0400 (EDT), Arthur Machlas wrote: A less religious explanation, from Greg Kroah-Hartman, author of The Linux Kernel in a Nutshell, and well-known kernel hacker. This warning is the most important thing to remember while working through the steps in this book. Everything in this book—downloading the kernel source code, uncompressing it, configuring the kernel, and building it—should be done as a normal user on the machine. Only the two or three commands it takes to install a new kernel should be done as the superuser (root). There have been bugs in the kernel build process in the past, causing some special files in the /dev directory to be deleted if the user had superuser permissions while building the Linux kernel.* There are also issues that can easily arise when uncompressing the Linux kernel with superuser rights, as some of the files in the kernel source package will not end up with the proper permissions and will cause build errors later. * This took quite a while to fix, as none of the primary kernel developers build kernels as root, so they did not suffer from the bug. A number of weeks went by before it was finally determined that the act of building the kernel was the problem. A number of kernel developers half-jokingly suggested that the bug remain in, to help prevent anyone from building the kernel as root, but calmer heads prevailed and the bug in the build system was fixed. - Linux Kernel in a Nutshell, p. 4 Thanks, Arthur. I actually do agree with Greg from a philosophical point of view that it is better to do as much as possible as a non-root user. It is pragmatic, rather than philosophical reasons that cause me to build the kernel as root. I believe all the bugs mentioned above have been fixed now. And building the kernel as a non-root user adds extra complications. For example: (1) I believe that aptitude install linux-source-x.x.xx, as with any package installation, requires root privileges. (2) By default, aptitude install linux-source-x.x.xx installs the .tar.bz2 file in /usr/src. My non-superuser self does not have write permissions to that directory; so it cannot be uncompressed in place. It has to be moved somewhere else, such as a directory off of my home directory. And then I have to use chown and chgrp on it to assign the ownership of the file to my non-superuser self. (3) If I am using out-of-kernel-source-tree module source packages, I have to copy them too. By default, the source code installs to /usr/src/modules, I think. All the same issues arise here. And then I have to use the $MODULE_LOC environment variable to tell make-kpkg where to find the module source code. More overrides. It's just simpler to be root and do everything in its default location. If I were experiencing the problems that Greg describes above, it would be worth doing the extra steps to avoid them. But all those problems have been fixed, it seems. Still, since there are many people who feel strongly about this issue, perhaps I should consider revising my kernel building web page to address this subject in more detail. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1851191283.11027.1281537217247.javamail.r...@md01.wow.synacor.com
Re: building 2.6.35
Stephen Powell zlinuxman wrote: (1) I believe that aptitude install linux-source-x.x.xx, as with any package installation, requires root privileges. Yes, but that isn't the only way to get the source. There are many ways of getting linux kernel source that don't involve installing packages. (2) By default, aptitude install linux-source-x.x.xx installs the .tar.bz2 file in /usr/src. My non-superuser self does not have write permissions to that directory; so it cannot be uncompressed in place. It has to be moved somewhere else, such as a directory off of my home directory. And then I have to use chown and chgrp on it to assign the ownership of the file to my non-superuser self. If it is your own machine then you should certainly be in the 'src' group and then you would have access to /usr/src as your own normal user self. And if you don't know about src then you probably don't know about 'staff' and 'adm' either. The staff group gets you access to /usr/local and adm gets you read-only browsing capability to /var/log/*. You probably want all three. $ sudo adduser zlinuxman adm $ sudo adduser zlinuxman src $ sudo adduser zlinuxman staff Then log out. At login you will be set to those additional groups. With those in place you can work as yourself in those areas. Safer than using root since as yourself you can't smash anything in the system directories /etc or /bin or /var or other system locations. This makes installing local software through 'make install' much safer and more contained when not done as root. If one were to crawl out of /usr/local for example you would see the failure. If you were running as root then you would not. Bob signature.asc Description: Digital signature
Re: building 2.6.35
On Mon, 09 Aug 2010 19:01:50 -0400 (EDT), Alexander Samad wrote: On Mon, Aug 9, 2010 at 9:26 AM, Stephen Powell zlinux...@wowway.com wrote: On Sun, 08 Aug 2010 03:10:10 -0400 (EDT), Angus Hedger wrote: I have been fumbling my way though building custom kernels on debian using this guide http://www.wowway.com/~zlinuxman/Kernel.htm. Though, I have been using the .config from the stock 2.6.32 kernel and customising it to fit, as when I tried to make my own from scratch it didn’t boot. That is not recommended unless you are building a custom version of a 2.6.32 kernel. There are 2.6.35 stock kernel images available in experimental. For example: linux-image-2.6.35-rc6-686 or linux-image-2.6.35-rc6-amd64. If one of them will not do, you should at least use the config file from one of those as your starting point for configuration of your 2.6.35 source rather than using a 2.6.32 config file. I did trying using the packages for 2.6.35, but you can't install the headers because the linux-kbuild-2.6.35 is there Why do you want to install the headers if you already have the whole kernel source code? What are you trying to accomplish besides building a custom kernel? A Debian source package for 2.6.35 is also available in experimental: linux-source-2.6.35. can I use make-kpkg against this ? I haven't tried that specific source package, but I don't know of any reason why it wouldn't work. my reason for doing this is I have a problem with my screen - there is a bug open at freedesktop.org. and I need to get the lastest git from drm-intel So does this video driver use an out-of-kernel-source-tree kernel module, like the proprietary nvidia driver does? Are you trying to use module-assistant? Is that why you need the headers (or why you think you need the headers)? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/477765543.3782.1281445228509.javamail.r...@md01.wow.synacor.com
Re: building 2.6.35
On Tue, Aug 10, 2010 at 9:00 PM, Stephen Powell zlinux...@wowway.com wrote: On Mon, 09 Aug 2010 19:01:50 -0400 (EDT), Alexander Samad wrote: On Mon, Aug 9, 2010 at 9:26 AM, Stephen Powell zlinux...@wowway.com wrote: On Sun, 08 Aug 2010 03:10:10 -0400 (EDT), Angus Hedger wrote: [snip I did trying using the packages for 2.6.35, but you can't install the headers because the linux-kbuild-2.6.35 is there Why do you want to install the headers if you already have the whole kernel source code? What are you trying to accomplish besides building a custom kernel? I wanted the header file, so I could build the intel i915 modules, I was planning on taking the modules source that belong to that and try to compile against a debian kernel. A Debian source package for 2.6.35 is also available in experimental: linux-source-2.6.35. must have slipped past me - I saw the package, but so used to using the headers files. can I use make-kpkg against this ? I haven't tried that specific source package, but I don't know of any reason why it wouldn't work. my reason for doing this is I have a problem with my screen - there is a bug open at freedesktop.org. and I need to get the lastest git from drm-intel So does this video driver use an out-of-kernel-source-tree kernel module, like the proprietary nvidia driver does? Are you trying to use module-assistant? Is that why you need the headers (or why you think you need the headers)? no it not like the ndvidia think, just they freedesktop org - maintaniers would like me to use the lastest HEAD version... -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/477765543.3782.1281445228509.javamail.r...@md01.wow.synacor.com -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=anstqdawe1rf-qxch0eo-m7v1s5y=qrr9n...@mail.gmail.com
Re: building 2.6.35
On Mon, Aug 9, 2010 at 8:18 PM, John Hasler jhas...@debian.org wrote: Tom H writes: I wasn't saying that you should use sudo. I was pointing out that you were wrong in saying that shouldn't compile using root permissions. No he wasn't. Whether you choose fakeroot, sudo, su, or log on as root, is a religious-type discussion that you can have with someone who cares about such things. Read the fakeroot man page. Fakroot does _not_ get root. It does not give you any additional powers: that is why it exists. I have and I agree with you regarding what fakeroot does (based on the manpage that I've read in the past and read again after you posted part of it). IIUC, instead of giving you additional powers, fakeroot gives your environment additional powers (otherwise, why would it be used?) and that's probably why the kernel-package documentation doesn't differentiate between fakeroot and sudo, refers to them both as $Get_Root, and describes them as whatever you need to become root -- fakeroot or sudo...). -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikwjq3zk3ae2=gybecxyj7yhmb7buchgvdkr...@mail.gmail.com
Re: building 2.6.35
On Tue, 10 Aug 2010 14:58:04 -0400 (EDT), Tom H wrote: I have and I agree with you regarding what fakeroot does (based on the manpage that I've read in the past and read again after you posted part of it). IIUC, instead of giving you additional powers, fakeroot gives your environment additional powers (otherwise, why would it be used?) and that's probably why the kernel-package documentation doesn't differentiate between fakeroot and sudo, refers to them both as $Get_Root, and describes them as whatever you need to become root -- fakeroot or sudo...). In order to build a binary Debian package, some functions are used internally by make-kpkg (or lower level commands called by make-kpkg, such as dpkg-buildpackage) that would normally require root privileges. Examples are chmod(2), stat(2), etc. Compiling the kernel source code does not require root privileges, but building the .deb file normally does. There are several solutions to this problem, such as: (1) login as root. (2) login as a non-root user and issue su to get a nested shell session that has root privileges, assuming that you know the root password. (3) preface the make-kpkg command with sudo, assuming that you have proper sudo permissions. (4) use the --rootcmd option of make-kpkg, supplying sudo as its argument. For example, make-kpkg --rootcmd sudo ... This way, make-kpkg executes as a non-root user most of the time and uses sudo to become root only when it needs to be. (5) preface the make-kpkg command with fakeroot (6) use the --rootcmd option of make-kpkg, supplying fakeroot as its argument. For example, make-kpkg --rootcmd fakeroot ... And there are probably other scenarios that I haven't thought of. fakeroot, as its name implies, does not actually give you true root privileges. Rather, it supplies temporary replacements for the library functions needed by dpkg-buildpackage that would ordinarily require root privileges, such as chmod(2), stat(2), etc. These replacement functions simulate the effect the real library functions would have had, had the user really been root. It gives you just enough apparent root authority to build a package (selected file manipulation functions) and no more. If you've looked at my kernel building web page, http://www.wowway.com/~zlinuxman/Kernel.htm, you will see that I don't cover this. That's because I don't use it when I build my own custom kernels. I do use it when building a regular Debian package, but for some reason I've never bothered with it for creating my own custom kernels. I just log in as root and forget about it. For some people, this seems to be a religious issue. But I never bother with it. I just login as root and forget about it. So many of the steps require root authority (real root authority) that it's simpler for me just to stay root the whole time. If I ever get burned by it, I'll probably change my lazy ways. But I've never had a problem with it. To each his own. Live and let live. Etc. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1801908961.11483.1281469778081.javamail.r...@md01.wow.synacor.com
Re: building 2.6.35
If you've looked at my kernel building web page, http://www.wowway.com/~zlinuxman/Kernel.htm, you will see that I don't cover this. That's because I don't use it when I build my own custom kernels. I do use it when building a regular Debian package, but for some reason I've never bothered with it for creating my own custom kernels. I just log in as root and forget about it. For some people, this seems to be a religious issue. But I never bother with it. I just login as root and forget about it. So many of the steps require root authority (real root authority) that it's simpler for me just to stay root the whole time. If I ever get burned by it, I'll probably change my lazy ways. But I've never had a problem with it. To each his own. Live and let live. Etc. A less religious explanation, from Greg Kroah-Hartman, author of The Linux Kernel in a Nutshell, and well-known kernel hacker. This warning is the most important thing to remember while working through the steps in this book. Everything in this book—downloading the kernel source code, uncompressing it, configuring the kernel, and building it—should be done as a normal user on the machine. Only the two or three commands it takes to install a new kernel should be done as the superuser (root). There have been bugs in the kernel build process in the past, causing some special files in the /dev directory to be deleted if the user had superuser permissions while building the Linux kernel.* There are also issues that can easily arise when uncompressing the Linux kernel with superuser rights, as some of the files in the kernel source package will not end up with the proper permissions and will cause build errors later. * This took quite a while to fix, as none of the primary kernel developers build kernels as root, so they did not suffer from the bug. A number of weeks went by before it was finally determined that the act of building the kernel was the problem. A number of kernel developers half-jokingly suggested that the bug remain in, to help prevent anyone from building the kernel as root, but calmer heads prevailed and the bug in the build system was fixed. - Linux Kernel in a Nutshell, p. 4 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktik1npu8sgoebqabbu4g23b-5al_ouh4xtfo=...@mail.gmail.com
Re: building 2.6.35
[snip] I did trying using the packages for 2.6.35, but you can't install the headers because the linux-kbuild-2.6.35 is there Why do you want to install the headers if you already have the whole kernel source code? What are you trying to accomplish besides building a custom kernel? I wanted the header file, so I could build the intel i915 modules, I was planning on taking the modules source that belong to that and try to compile against a debian kernel. okay here is the problem with this, there are some extra steps needed to use the kernel-source so I installed the linux-image and the kernel-source package, boots up great - but I can't compile my vb kernel modules - no header files - I point it to /usr/src/.. (unpacked kernel-source), doesn't work... What do I need to do :) Alex A Debian source package for 2.6.35 is also available in experimental: linux-source-2.6.35. [snip] -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti==0+bse_c9pcxxegwgpmtzx1p0bs9zÿrq...@mail.gmail.com
RE: building 2.6.35
On Wed, 11 Aug 2010 08:45:04 +0800 a...@samad.com.au wrote: [snip] I did trying using the packages for 2.6.35, but you can't install the headers because the linux-kbuild-2.6.35 is there Why do you want to install the headers if you already have the whole kernel source code? What are you trying to accomplish besides building a custom kernel? I wanted the header file, so I could build the intel i915 modules, I was planning on taking the modules source that belong to that and try to compile against a debian kernel. okay here is the problem with this, there are some extra steps needed to use the kernel-source so I installed the linux-image and the kernel-source package, boots up great - but I can't compile my vb kernel modules - no header files - I point it to /usr/src/.. (unpacked kernel-source), doesn't work... What do I need to do :) Maybe this will help... The make headers_install command exports the kernel's header files in a form suitable for use by userspace programs. The kernel header files can be generated from the kernel sources. Define INSTALL_HDR_PATH= for output location. http://www.mjmwired.net/kernel/Documentation/make/headers_install.txt A Debian source package for 2.6.35 is also available in experimental: linux-source-2.6.35. [snip] -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=+bse_c9pcxxegwgpmtzx1p0bs9zÿrq...@mail.gmail.com
Re: building 2.6.35
On Mon, Aug 9, 2010 at 2:26 AM, Stephen Powell zlinux...@wowway.com wrote: On Sun, 08 Aug 2010 03:10:10 -0400 (EDT), Angus Hedger wrote: I have been fumbling my way though building custom kernels on debian using this guide http://www.wowway.com/~zlinuxman/Kernel.htm. Though, I have been using the .config from the stock 2.6.32 kernel and customising it to fit, as when I tried to make my own from scratch it didn’t boot. That is not recommended unless you are building a custom version of a 2.6.32 kernel. There are 2.6.35 stock kernel images available in experimental. For example: linux-image-2.6.35-rc6-686 or linux-image-2.6.35-rc6-amd64. If one of them will not do, you should at least use the config file from one of those as your starting point for configuration of your 2.6.35 source rather than using a 2.6.32 config file. A Debian source package for 2.6.35 is also available in experimental: linux-source-2.6.35. -- .''`. Stephen Powell : :' : `. `'` `- Oooh, I didnt know there was a 2.6.35 package, Ill go extract the .config and rebase mine on that now, thanks a lot! Angus ps, cheers for your work on the guide, its been invaluable -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinj1yjy-vdofluoujw1pvo3xf8h6anq6vf=g...@mail.gmail.com
Re: building 2.6.35
Tom H wrote: Bob Proulx wrote: Alexander Samad wrote: sudo CONCURRENCY_LEVEL=4 make-kpkg --initrd kernel_image You shouldn't compile using root permissions. You don't need to use sudo there and it is not desired. From the kernel-package documentation: 4% $Get_Root make-kpkg --revision=custom.1.0 kernel_image (Get_Root is whatever you need to become root -- fakeroot or sudo are examples that come to mind). Just because you can do something doesn't mean that you should do it. You shouldn't be using root to build packages. Bob signature.asc Description: Digital signature
Re: building 2.6.35
On Mon, Aug 9, 2010 at 9:26 AM, Stephen Powell zlinux...@wowway.com wrote: On Sun, 08 Aug 2010 03:10:10 -0400 (EDT), Angus Hedger wrote: I have been fumbling my way though building custom kernels on debian using this guide http://www.wowway.com/~zlinuxman/Kernel.htm. Though, I have been using the .config from the stock 2.6.32 kernel and customising it to fit, as when I tried to make my own from scratch it didn’t boot. That is not recommended unless you are building a custom version of a 2.6.32 kernel. There are 2.6.35 stock kernel images available in experimental. For example: linux-image-2.6.35-rc6-686 or linux-image-2.6.35-rc6-amd64. If one of them will not do, you should at least use the config file from one of those as your starting I did trying using the packages for 2.6.35, but you can't install the headers because the linux-kbuild-2.6.35 is there point for configuration of your 2.6.35 source rather than using a 2.6.32 config file. A Debian source package for 2.6.35 is also available in experimental: linux-source-2.6.35. can I use make-kpkg against this ? my reason for doing this is I have a problem with my screen - there is a bug open at freedesktop.org. and I need to get the lastest git from drm-intel Alex -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1200678901.264320.1281317212398.javamail.r...@md01.wow.synacor.com -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikkph_sxf866y7ukbxoo9ezc9jbh0ldifsf1...@mail.gmail.com
Re: building 2.6.35
Tom H wrote: 4% $Get_Root make-kpkg --revision=custom.1.0 kernel_image (Get_Root is whatever you need to become root -- fakeroot or sudo are examples that come to mind). From the fakeroot man page: DESCRIPTION fakeroot runs a command in an environment wherein it appears to have root privileges for file manipulation. This is useful for allowing users to create archives (tar, ar, .deb etc.) with files in them with root permissions/ownership. Without fakeroot one would need to have root privileges to create the constituent files of the archives with the correct permissions and ownership, and then pack them up, or one would have to construct the archives directly, without using the archiver. -- John Hasler -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874of35qvc@thumper.dhh.gt.org
Re: building 2.6.35
On Mon, Aug 9, 2010 at 5:51 PM, Bob Proulx b...@proulx.com wrote: Tom H wrote: Bob Proulx wrote: Alexander Samad wrote: sudo CONCURRENCY_LEVEL=4 make-kpkg --initrd kernel_image You shouldn't compile using root permissions. You don't need to use sudo there and it is not desired. From the kernel-package documentation: 4% $Get_Root make-kpkg --revision=custom.1.0 kernel_image (Get_Root is whatever you need to become root -- fakeroot or sudo are examples that come to mind). Just because you can do something doesn't mean that you should do it. You shouldn't be using root to build packages. I wasn't saying that you should use sudo. I was pointing out that you were wrong in saying that shouldn't compile using root permissions. The kernel-package documentation is clear; you need $Get_Root. Whether you choose fakeroot, sudo, su, or log on as root, is a religious-type discussion that you can have with someone who cares about such things. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimruggmd+_0bs+0dejrgybvk0modnb+zjwea...@mail.gmail.com
Re: building 2.6.35
On Mon, Aug 9, 2010 at 7:05 PM, John Hasler jhas...@debian.org wrote: Tom H wrote: 4% $Get_Root make-kpkg --revision=custom.1.0 kernel_image (Get_Root is whatever you need to become root -- fakeroot or sudo are examples that come to mind). From the fakeroot man page: DESCRIPTION fakeroot runs a command in an environment wherein it appears to have root privileges for file manipulation. This is useful for allowing users to create archives (tar, ar, .deb etc.) with files in them with root permissions/ownership. Without fakeroot one would need to have root privileges to create the constituent files of the archives with the correct permissions and ownership, and then pack them up, or one would have to construct the archives directly, without using the archiver. See http://lists.debian.org/debian-user/2010/08/msg00455.html -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinut0vgmc-kek0bka0uxchhzynlw6ragqrjg...@mail.gmail.com
Re: building 2.6.35
Tom H writes: I wasn't saying that you should use sudo. I was pointing out that you were wrong in saying that shouldn't compile using root permissions. No he wasn't. Whether you choose fakeroot, sudo, su, or log on as root, is a religious-type discussion that you can have with someone who cares about such things. Read the fakeroot man page. Fakroot does _not_ get root. It does not give you any additional powers: that is why it exists. -- John Hasler -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zkwv48xe@thumper.dhh.gt.org
Re: building 2.6.35
On Mon, 9 Aug 2010 19:38:48 -0400 Tom H tomh0...@gmail.com wrote: ... Whether you choose fakeroot, sudo, su, or log on as root, is a religious-type discussion that you can have with someone who cares about such things. As others have pointed out, the difference between fakeroot and the other choices is significant indeed; the latter run code as root, while the former does not. Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100809220615.38c6d932.cele...@gmail.com
Re: building 2.6.35
On Sun, Aug 8, 2010 at 3:45 AM, Alexander Samad a...@samad.com.au wrote: Hi I am looking at how to build 2.6.35 the debian way so I end up with deb packages. the current situation is 2.6.35 is avail in experimental (?!) with out a linux-kbuild packages - last time I asked about this it was because they only wanted people who understood how to build to play with the new linux-image. what ever the reason thats cool. I would like to install and play with the new kernel and I need headers. So I have had a look here http://wiki.debian.org/HowToRebuildAnOfficialDebianKernelPackage, there is a section on building linux-kbuild - but guess what the svn co downloads the 2.6.34 version :( I found this http://www.linuxconfig.org/building-kernels-the-debian-way - the comment down the bottom with the script - looks promising. going to give this a try. sudo CONCURRENCY_LEVEL=4 make-kpkg --initrd kernel_image kernel_headers modules_image - this seems todo most of the work So my thoughts were to start out with .config from 2.6.34 make olconfig it and then customise it from there. I seem to remember you could some how get the src package for linux-kbuild of experimental and thus just build it from there Any help comments would be appreciated Alex I have been fumbling my way though building custom kernels on debian using this guide http://www.wowway.com/~zlinuxman/Kernel.htm. Though, I have been using the .config from the stock 2.6.32 kernel and customising it to fit, as when I tried to make my own from scratch it didn’t boot. Regards, Angus ps, I have been having a weird bug with make-kpkg where, after building kernel headers and installing them as well as the image, the /lib/modules/kernel version name/build symlink has been pointing to the linux src dir that I used to build the kernel rather than the headers dir in /usr/src/linux-headers-kernel version name, just a heads up to watch out for that, I havent bug reported it yet as im not sure what the bug is with, as it worked fine to start with! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimmzskjoa1wphs+3qi902cyxdqotpeuqrzoa...@mail.gmail.com
Re: building 2.6.35
Alexander Samad: I am looking at how to build 2.6.35 the debian way so I end up with deb packages. The easiest way to get a kernel deb is to fetch vanilla sources from kernel.org, unpack them and run 'make make deb-pkg'. I am not sure whether such packages create an initramfs on installation by default, nowadays. J. -- In idle moments I remember former lovers with sentimental tenderness. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Re: building 2.6.35
On 2010-08-08 09:39 +0200, Jochen Schulz wrote: Alexander Samad: I am looking at how to build 2.6.35 the debian way so I end up with deb packages. The easiest way to get a kernel deb is to fetch vanilla sources from kernel.org, unpack them and run 'make make deb-pkg'. I am not sure whether such packages create an initramfs on installation by default, nowadays. They run the scripts in /etc/kernel/postinst.d in the postinst, and with initramfs-tools 0.94 or newer this is sufficient to generate an initramfs. Sven -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762zl7bd9@turtle.gmx.de
Re: building 2.6.35
On Sat, Aug 7, 2010 at 10:45 PM, Alexander Samad a...@samad.com.au wrote: I am looking at how to build 2.6.35 the debian way so I end up with deb packages. the current situation is 2.6.35 is avail in experimental (?!) with out a linux-kbuild packages - last time I asked about this it was because they only wanted people who understood how to build to play with the new linux-image. what ever the reason thats cool. I would like to install and play with the new kernel and I need headers. So I have had a look here http://wiki.debian.org/HowToRebuildAnOfficialDebianKernelPackage, there is a section on building linux-kbuild - but guess what the svn co downloads the 2.6.34 version :( If you don't want to wait for 2.6.35 to be available from a Debian source, you can get the 2.6.35 source from kernel.org and build a kernel the Debian way. You could also be really lazy while waiting for Debian to make 2.6.35 available and download a 2.6.35 deb from a Ubuntu repository... I found this http://www.linuxconfig.org/building-kernels-the-debian-way - the comment down the bottom with the script - looks promising. going to give this a try. If you do use that script, you should remove the embedded sudos from it. If you do use the script as is, you might want to increase sudo's timestamp_timeout value. http://www.wowway.com/~zlinuxman/Kernel.htm is a good guide to building a kernel the Debian way. It is written by d-u regular and is included in the kernel-package documentation as /usr/share/kernel-package/docs/Kernel.htm -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikwbrypknn+nv1adhvqutafpiq_tertqp545...@mail.gmail.com
Re: building 2.6.35
On Sat, Aug 7, 2010 at 11:57 PM, Bob Proulx b...@proulx.com wrote: Alexander Samad wrote: sudo CONCURRENCY_LEVEL=4 make-kpkg --initrd kernel_image You shouldn't compile using root permissions. You don't need to use sudo there and it is not desired. From the kernel-package documentation: 4% $Get_Root make-kpkg --revision=custom.1.0 kernel_image (Get_Root is whatever you need to become root -- fakeroot or sudo are examples that come to mind). -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=sl+3nkp_osuxiffy9vy_fhqzcrge7vkd3u...@mail.gmail.com
Re: building 2.6.35
* Alexander Samad [100808 12:45 +1000]: Hi I am looking at how to build 2.6.35 the debian way so I end up with deb packages. http://kernel-handbook.alioth.debian.org/ch-common-tasks.html Elimar -- what IMHO then? IMHO - Inhalation of a Multi-leafed Herbal Opiate ;) --posting from alex in debian-user-- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100808115059.gb6...@bilbo.home.lxtec.de
Re: building 2.6.35
On Sun, 08 Aug 2010 03:10:10 -0400 (EDT), Angus Hedger wrote: I have been fumbling my way though building custom kernels on debian using this guide http://www.wowway.com/~zlinuxman/Kernel.htm. Though, I have been using the .config from the stock 2.6.32 kernel and customising it to fit, as when I tried to make my own from scratch it didn’t boot. That is not recommended unless you are building a custom version of a 2.6.32 kernel. There are 2.6.35 stock kernel images available in experimental. For example: linux-image-2.6.35-rc6-686 or linux-image-2.6.35-rc6-amd64. If one of them will not do, you should at least use the config file from one of those as your starting point for configuration of your 2.6.35 source rather than using a 2.6.32 config file. A Debian source package for 2.6.35 is also available in experimental: linux-source-2.6.35. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1200678901.264320.1281317212398.javamail.r...@md01.wow.synacor.com
Re: building 2.6.35
On Sun, 08 Aug 2010 07:48:48 -0400 (EDT), Tom H wrote: http://www.wowway.com/~zlinuxman/Kernel.htm is a good guide to building a kernel the Debian way. It is written by d-u regular and is included in the kernel-package documentation as /usr/share/kernel-package/docs/Kernel.htm Unfortunately, the version included with kernel-package is out of date, especially Customizing the Kernel Installation Environment. I recommend reading the online web version. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/526028648.264473.1281317642096.javamail.r...@md01.wow.synacor.com
building 2.6.35
Hi I am looking at how to build 2.6.35 the debian way so I end up with deb packages. the current situation is 2.6.35 is avail in experimental (?!) with out a linux-kbuild packages - last time I asked about this it was because they only wanted people who understood how to build to play with the new linux-image. what ever the reason thats cool. I would like to install and play with the new kernel and I need headers. So I have had a look here http://wiki.debian.org/HowToRebuildAnOfficialDebianKernelPackage, there is a section on building linux-kbuild - but guess what the svn co downloads the 2.6.34 version :( I found this http://www.linuxconfig.org/building-kernels-the-debian-way - the comment down the bottom with the script - looks promising. going to give this a try. sudo CONCURRENCY_LEVEL=4 make-kpkg --initrd kernel_image kernel_headers modules_image - this seems todo most of the work So my thoughts were to start out with .config from 2.6.34 make olconfig it and then customise it from there. I seem to remember you could some how get the src package for linux-kbuild of experimental and thus just build it from there Any help comments would be appreciated Alex -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=syfcoxrdcp8xinn6snn9cg3yib0sfjdzdm...@mail.gmail.com
Re: building 2.6.35
Alexander Samad wrote: I have had a look here http://wiki.debian.org/HowToRebuildAnOfficialDebianKernelPackage, there is a section on building linux-kbuild - but guess what the svn co downloads the 2.6.34 version :( I found this http://www.linuxconfig.org/building-kernels-the-debian-way - the comment down the bottom with the script - looks promising. going to give this a try. See also the old newbiedoc too. http://newbiedoc.sourceforge.net/system/kernel-pkg.html sudo CONCURRENCY_LEVEL=4 make-kpkg --initrd kernel_image You shouldn't compile using root permissions. You don't need to use sudo there and it is not desired. kernel_headers modules_image - this seems todo most of the work So my thoughts were to start out with .config from 2.6.34 make olconfig it and then customise it from there. Yes. Start out using the previous config and then build the new kernel using that as a starting point. I have previously built kernels using a command line like this (where -2 is the second custom build): $ fakeroot make-kpkg --append_to_version -2-686-custom modules_image If you want to set the concurrency level then the right shell syntax is to put that first on the command line. $ CONCURRENCY_LEVEL=4 fakeroot make-kpkg --append_to_version -3-686-custom modules_image Bob signature.asc Description: Digital signature
Re: building 2.6.35
I should also say that I have the following in my ~/.devscripts file so as to always customize dpkg-buildpackage. DEBUILD_DPKG_BUILDPACKAGE_OPTS=-uc -us That avoids signing the source or changes files. Which IMNHO really shouldn't be done as part of the build but only later when you are ready to sign off on the package. You can use debsign when ready. Bob signature.asc Description: Digital signature
