On Friday 27 June 2003 11:50 am, martin f krafft wrote: > I just configured, then made the kernel_image for a custom 2.4.21 > kernel with a couple of patches: > > make-kpkg --append-to-version > -diamond-grsec-1.9.10+freeswan-ext-1.99+preempt-20030617-2 > --revision 20030627.1726 --rootcmd fakeroot --config oldconfig > --added-patches grsecurity-2-4,freeswan,preempt configure > > make-kpkg --append-to-version > -diamond-grsec-1.9.10+freeswan-ext-1.99+preempt-20030617-2 --rootcmd > fakeroot kernel-image kernel-headers > > these worked quite nicely. > > Then I tried to compile a module for that kernel: > > make-kpkg --append-to-version > -diamond-grsec-1.9.10+freeswan-ext-1.99+preempt-20030617-2 > --rootcmd fakeroot --added-modules nvidia modules_image > > This fails: > > if [ -f /usr/src/modules/nvidia/debian/control.template ]; then \ > cp -a /usr/src/modules/nvidia/debian/control.template > /usr/src/modules/nvidia/debian/control; \ > fi > cp: cannot create regular file > `/usr/src/modules/nvidia/debian/control': Permission denied > > which makes perfect sense, because > > diamond:...new/src/linux-2.4.21> id > uid=1000(madduck) gid=100(users) ... > > I consider this a bug, but I can't imagine that this bug exists > because make-kpkg has existed for ages, and this is, after all, > Debian. > > So I am wondering: what am I doing wrong? I *should* be able to > compile modules for an existing kernel tree without write privs to > /usr/src/modules/..., right?
I noticed one oddity myself.. I've just been working with make-kpkg, and noticed in the output, that when it tried to delete (I think) and re-install the debian directory, that if I used --rootcmd fakeroot, it reported that it couldn't, but if I used "fakeroot make-kpkg..." that all went well.. Perhaps the --rootcmd doesn't work as expected? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
