make-kpkg --revision, deb file naming convention?

haertig · 07-07-2006, 11:52 AM

I installed the standard kernel sources and headers from the Debian Sarge repository for the kernel I'm running (2.6.12)

How come this:

Code:

make-kpkg --initrd --revision=dfh1 kernel_image

...results in the following deb file (the filename has duplicate "dfh1" revision info):

Code:

kernel-image-2.6.12-1-686-dfh1_dfh1_i386.deb

To compile, I ran the following (the compile ran without error):

Code:

$ su -
# uname -r
2.6.12-1-686
# cd /usr/src/linux (is a symlink to /usr/src/linux-source-2.6.12)
# make clean
# make distclean
# make-kpkg clean
# cp /boot/config-2.6.12-1-686 .config
# make menuconfig (no changes were made, just "save")
# make-kpkg --initrd --revision=dfh1 kernel_image

I don't remember running into this on previous compiles. But those were on different Debian systems running Sid (this one is Sarge, but I don't see how that would matter).

Interestingly, my /usr/src/linux/.config file has the following right at the top:

Code:

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.12-1-686-dfh1
# Fri Jul  7 09:35:52 2006
#

I'm not sure how "dfh1" got into the .config file. The only place I mentioned it was in the make-kpkg commandline. That "dfh1" part was not in the /boot/config-2.6.12-1-686 that I manually copied to /usr/src/linux/.config in the early steps. Does make-kpkg put the revision info into the .config file? Not that I care that it's there, but I'm thinking this might be the source of the duplication in the resulting deb filename.

HappyTux · 07-07-2006, 12:33 PM

Quote:

Originally Posted by haertig

I installed the standard kernel sources and headers from the Debian Sarge repository for the kernel I'm running (2.6.12)

How come this:

Code:

make-kpkg --initrd --revision=dfh1 kernel_image

...results in the following deb file (the filename has duplicate "dfh1" revision info):

Code:

kernel-image-2.6.12-1-686-dfh1_dfh1_i386.deb

Not sure why that is happening you should have the normal -10.00.Custom_ in place of the dfh1 but you want to try --append-to-version=dfh1 in place of the --revision to add to the kernel version number.

Quote:

To compile, I ran the following (the compile ran without error):

Code:

$ su -
# uname -r
2.6.12-1-686
# cd /usr/src/linux (is a symlink to /usr/src/linux-source-2.6.12)
# make clean
# make distclean
# make-kpkg clean
# cp /boot/config-2.6.12-1-686 .config
# make menuconfig (no changes were made, just "save")
# make-kpkg --initrd --revision=dfh1 kernel_image

I don't remember running into this on previous compiles. But those were on different Debian systems running Sid (this one is Sarge, but I don't see how that would matter).

It could be a bug in Sarge's version for the rest of your procedure. You should install the fakeroot package and use that instead of being root when compiling here is what I would use, you have a lot of not needed steps in there.

Code:

$cd /usr/src/
$tar -xjvf linux-source-2.6.12.tar.bz2
$ln -s linux-2.6.12 linux
$cd linux
$make menuconfig (go to bottom select Load Alternative config type in /boot/config-2.6.12-1-686 then save)
$fakeroot make-kpkg clean
$fakeroot make-kpkg --initrd --append-to-version=dfh1 kernel_image

Now you would change up to the /usr/src directory and become root to install the resulting .deb image and you want to have the normal user account be a member of the src group (adduser user_name src logout and back in for change to take effect).

Quote:

Interestingly, my /usr/src/linux/.config file has the following right at the top:

Code:

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.12-1-686-dfh1
# Fri Jul  7 09:35:52 2006
#

Not that I care that it's there, but I'm thinking this might be the source of the duplication in the resulting deb filename.

No I get the same here and the .deb kernel image is named properly.

Code:

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.17-ck1
# Sun Jun 18 10:52:15 2006
#

>$ ls -l /usr/src/linux-image-2.6.17-ck1_2.6.17-ck1-10.00.Custom_amd64.deb
-rw-r--r-- 1 stephen src 4682318 2006-06-18 11:02 /usr/src/linux-image-2.6.17-ck1_2.6.17-ck1-10.00.Custom_amd64.deb

haertig · 07-07-2006, 01:14 PM

Thanks for the reply. I'll play around with it some more. I don't compile kernels terribly often, so I'm no master at it. I've always managed somehow - probably more from luck and the hard work of others who designed make-kpkg, etc.

Quote:

you should install the fakeroot package and use that instead of being root when compiling

Could I ask why? What does fakeroot gain me, given I'm root?

I was going to install fakeroot, but decided not to (why do I really need it?) after seeing the following bugs (may be minor, but why bother with them?):

Code:

# apt-listbugs list fakeroot
Reading package fields... Done
Reading package status... Done
Retrieving bug reports... Done
critical bugs of fakeroot (-> ) <done>
 #317911 - fakeroot: Needs to update to current dpkg-dev and gcc
grave bugs of fakeroot (-> ) <done>
 #316307 - fakeroot: fakeroot execs interactive /bin/sh
 #316308 - fakeroot scripts do not invoke shell correctly
Summary:
 fakeroot(3 bugs)
#

HappyTux · 07-07-2006, 01:26 PM

Quote:

Originally Posted by haertig

Thanks for the reply. I'll play around with it some more. I don't compile kernels terribly often, so I'm no master at it. I've always managed somehow - probably more from luck and the hard work of others who designed make-kpkg, etc.

Could I ask why? What does fakeroot gain me, given I'm root?

That is the whole point not being root, fakeroot will allow you to compile as if you are root while eliminating the security problem of compiling as root.

Quote:

I was going to install fakeroot, but decided not to (why do I really need it?) after seeing the following bugs (may be minor, but why bother with them?):

Code:

# apt-listbugs list fakeroot
Reading package fields... Done
Reading package status... Done
Retrieving bug reports... Done
critical bugs of fakeroot (-> ) <done>
 #317911 - fakeroot: Needs to update to current dpkg-dev and gcc
grave bugs of fakeroot (-> ) <done>
 #316307 - fakeroot: fakeroot execs interactive /bin/sh
 #316308 - fakeroot scripts do not invoke shell correctly
Summary:
 fakeroot(3 bugs)
#

The 317911 applied to a 64bit install as I read it and the last two are duplicates of the same problem, you could always try with fakeroot and see if it helps either way you have too many unnecessary steps in your compile method if you want to continue doing it that way it is up to you.

haertig · 07-07-2006, 02:10 PM

Quote:

That is the whole point not being root, fakeroot will allow you to compile as if you are root while eliminating the security problem of compiling as root.

Is the security problem just the "you never want to be root unless you have to" issue? Or is there something inherantly unsecure about compiling as root? I understand that starting a compile as root and then walking away from your terminal would be highly unsecure (you could have a walk-up hacker kill the compile and gain shell access).

This is just my desktop workstation and I'm sitting here the whole time during the compile, working on something else (as a normal user) in another window. Assuming no terminal breaches during the compile, installation and subsequent root logoff, is the newly compiled kernel somehow less secure? Thanks!

HappyTux · 07-07-2006, 02:31 PM

Quote:

Originally Posted by haertig

Is the security problem just the "you never want to be root unless you have to" issue? Or is there something inherantly unsecure about compiling as root? I understand that starting a compile as root and then walking away from your terminal would be highly unsecure (you could have a walk-up hacker kill the compile and gain shell access).

This is just my desktop workstation and I'm sitting here the whole time during the compile, working on something else (as a normal user) in another window. Assuming no terminal breaches during the compile, installation and subsequent root logoff, is the newly compiled kernel somehow less secure? Thanks!

Or you could have some malicious code in the compile when executed as root destroy/compromises the system of course if we lived in a perfect world this would not be necessary and there would be no difference. And if real worried about as less root access as possible the install command could be as normal user su -c 'dpkg -i linux-image-????.deb' then all you need is the root pasword when asked and it will execute that command as root.

haertig · 07-07-2006, 03:01 PM

Quote:

you could have some malicious code in the compile

Very good point! I did not consider this. I'm not terribly worried about this specific kernel compile (source was downloaded from official Debian repositories). In general though, not compiling as root sounds like the prudent thing to do.

This kernel compile was in preparation for some other kernel module compiles - and THAT source came from other places! Specifically www.truecrypt.org On other machines in the past, I have not been able to get TrueCrypt compiled unless I was running a kernel that I had locally compiled myself. Probably something in my build environment was missing, and by compiling the kernel it got put where it was needed. So I've just gotten into the habit of first compiling my kernel locally, once per machine per kernel, before embarking on any kernel module compiles on that machine.

haertig · 07-07-2006, 03:25 PM

Doh! I found it. Evidently I *had* recompiled my kernel - or at least started to - on this Sarge machine.

Right there in /usr/src/linux/Makefile I find this:

Code:

EXTRAVERSION = -1-686-dfh1

I must have manually edited it sometime in the past. Just goes to show you I have no real grasp on how "EXTRAVERSION" vs. "--revision" vs. "--append-to-version" interact with each other, or why you would mess with one instead of the other. I guess I should do some more research (but if someone here knows a quick and dirty answer, feel free to offer it!)

Thanks

HappyTux · 07-07-2006, 03:36 PM

Quote:

Originally Posted by haertig

Very good point! I did not consider this. I'm not terribly worried about this specific kernel compile (source was downloaded from official Debian repositories). In general though, not compiling as root sounds like the prudent thing to do.

This kernel compile was in preparation for some other kernel module compiles - and THAT source came from other places! Specifically www.truecrypt.org On other machines in the past, I have not been able to get TrueCrypt compiled unless I was running a kernel that I had locally compiled myself. Probably something in my build environment was missing, and by compiling the kernel it got put where it was needed. So I've just gotten into the habit of first compiling my kernel locally, once per machine per kernel, before embarking on any kernel module compiles on that machine.

I do the same for the same reason although module-assistant can help with the kernel modules if they are in Debian. I just downloaded the Ubuntu package for x86_64 and put it into my local repository it seems to want to install without problems and there are no real dependencies on Ubuntu specific packages so you may want to try downloading one of them and install that way.

Code:

 HappyTux:/var/www/debian-packages# apt-get -s install truecrypt
Reading package lists... Done
Building dependency tree... Done
The following extra packages will be installed:
   dmsetup (1.02.07-1)
The following NEW packages will be installed:
   dmsetup (1.02.07-1)
   truecrypt (4.2a-0)
0 upgraded, 2 newly installed, 0 to remove and 4 not upgraded.
Inst dmsetup (2:1.02.07-1 Debian:testing)
Inst truecrypt (4.2a-0 localhost)
Conf dmsetup (2:1.02.07-1 Debian:testing)
Conf truecrypt (4.2a-0 localhost)
HappyTux:/var/www/debian-packages# apt-cache show truecrypt
Package: truecrypt
Version: 4.2a-0
Priority: optional
Section: base
Maintainer: TrueCrypt Foundation <http://www.truecrypt.org>
Depends: dmsetup, module-init-tools, mount
Architecture: amd64
Filename: binary/truecrypt-4.2a/truecrypt_4.2a-0_amd64.deb
Size: 784188
MD5sum: e23802dd0e7bade532d8a8b192207d7c
Description: transparent volume encryption
 TrueCrypt volumes can be mapped as virtual block devices and used as any other
 standard block device. All data being read from a mapped TrueCrypt volume is
 transparently decrypted and all data being written to it is transparently
 encrypted.
HappyTux:/var/www/debian-packages# apt-cache showpkg truecrypt
Package: truecrypt
Versions:
4.2a-0(/var/lib/apt/lists/localhost_debian-packages_binary_Packages)

Reverse Depends:
Dependencies:
4.2a-0 - dmsetup (0 (null)) module-init-tools (0 (null)) mount (0 (null))
Provides:
4.2a-0 -
Reverse Provides:

haertig · 07-07-2006, 03:50 PM

I wasn't aware you could successfully install Ubuntu packages on Debian, even though I knew Ubuntu is Debian-based. Handy to know this may be an option.

HappyTux · 07-07-2006, 04:31 PM

Quote:

Originally Posted by haertig

I wasn't aware you could successfully install Ubuntu packages on Debian, even though I knew Ubuntu is Debian-based. Handy to know this may be an option.

It will mostly work until a package has a dependency on a version specific to Ubuntu even then it will normally work to compile it from source using a deb-src line for Ubuntu and getting only the source for the package you want then using Debian for the build dependencies.