failure trying to install from Debian 4.0 (kernel 2.6.18-5)

[Brian Morris]

When trying to run debootstrap (version 1.0.28) to install a new current Ubuntu system on a new partition from a running Debian 4.0 (kernel 2.6.18-5) system I get the following error:

) sudo debootstrap --arch i386 lucid /mnt/newsys
...
I: Installing core packages...
W: Failure trying to run: chroot /mnt/newsys dpkg --force-depends --install /var/cache/apt/archives/base-files_5.0.0ubuntu20_i386.deb /var/cache/apt/archives/base-passwd_3.5.22_i386.deb

If I manually run that command, I see:

) sudo chroot /mnt/newsys dpkg --force-depends --install /var/cache/apt/archives/base-files_5.0.0ubuntu20_i386.deb /var/cache/apt/archives/base-passwd_3.5.22_i386.deb
tar: ./postinst: Cannot utime: Bad file descriptor
tar: ./preinst: Cannot utime: Bad file descriptor
tar: ./conffiles: Cannot utime: Bad file descriptor
tar: ./md5sums: Cannot utime: Bad file descriptor
tar: ./control: Cannot utime: Bad file descriptor
tar: .: Cannot utime: Bad file descriptor
tar: Exiting with failure status due to previous errors
dpkg-deb: subprocess tar returned error exit status 2
dpkg: error processing /var/cache/apt/archives/base-files_5.0.0ubuntu20_i386.deb (--install):
 subprocess dpkg-deb --control returned error exit status 2
tar: ./postinst: Cannot utime: Bad file descriptor
tar: ./md5sums: Cannot utime: Bad file descriptor
tar: ./control: Cannot utime: Bad file descriptor
tar: .: Cannot utime: Bad file descriptor
tar: Exiting with failure status due to previous errors
dpkg-deb: subprocess tar returned error exit status 2
dpkg: error processing /var/cache/apt/archives/base-passwd_3.5.22_i386.deb (--install):
 subprocess dpkg-deb --control returned error exit status 2
Errors were encountered while processing:
 /var/cache/apt/archives/base-files_5.0.0ubuntu20_i386.deb
 /var/cache/apt/archives/base-passwd_3.5.22_i386.deb

If I use strace to track down the source of those errors I see:

12:52:10.758566 execve("/bin/tar", ["tar", "xf", "-"], [/* 12 vars */]) = 0
...
12:52:10.766846 mkdir(".", 0700) = -1 EEXIST (File exists)
12:52:10.766869 stat64(".", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
12:52:10.766917 open("./postinst", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0700) = 4
12:52:10.766959 write(4, "#!/bin/sh\nset -e\n\ninstall_local_"..., 5941) = 5941
12:52:10.767007 close(4) = 0
12:52:10.767029 semget(4294967196, 134778280, IPC_CREAT|IPC_NOWAIT|0xbff64000|0100) = -1 ENOSYS (Function not implemented)
12:52:10.767074 write(2, "tar: ", 5) = 5
12:52:10.767172 write(2, "./postinst: Cannot utime", 24) = 24
12:52:10.767238 write(2, ": Bad file descriptor", 21) = 21
12:52:10.767302 write(2, "\n", 1) = 1
12:52:10.767379 chown32("./postinst", 0, 0) = 0
12:52:10.767406 chmod("./postinst", 0755) = 0
...

It looks like what tar (or the associated libc) is calling 'utime' strace seems to think is 'semget'. This seems like some sort of kernel call / libc incompatibility. I have tried a few hacks to get it to use the tar from the local system (which does seem to work) but I can't seem to get it to run the installation without overwriting it from the tar package it's installing into the new system.

Is this tar/syscall problem a known issue? Is there any workaround? Or is Debian 4.0 (or the 2.6.18-5 kernel in question) not supported to bootstrap a modern system?

[Brian Morris (brian-morris)]

Actually, as I was putting this together I realized a way I might be able to work around what was going on, and I just tried it and it seems to have worked. By copying 'tar' from the local system to /usr/bin/tar in the new system I can put a working tar before the problematic tar in the path, and the working tar doesn't get overwritten by the new tar installation.

I still wonder whether something can or should be done to make debootstrap handle this itself more gracefully...

[Ken Sharp (kennybobs)]

Fixed?

[Brian Morris (brian-morris)]

I had forgotten I even filed this a decade ago. I don't really have such a system to test with anymore, and it's not clear what more recent versions of things would be worth testing with. I suspect this can just be closed.

[Launchpad Janitor (janitor)]

[Expired for debootstrap (Ubuntu) because there has been no activity for 60 days.]