debootstrap can't chroot

i just had the same problem on edgy ; dapper seems to work fine

FWIW, I used debootstrap_0.3.3.0ubuntu7_all.deb for the (non-functional) edgy install and debootstrap_0.3.3.0ubuntu2_all.deb for the (working) dapper install

I have
david@jlh ~ $ dpkg -l debootstrap
Name Version Description
+++-=======================-=======================-==============================================================
ii debootstrap 0.3.3.0ubuntu8~edgy1 Bootstrap a basic Debian system

I am getting the same error, but I don't think it's a problem with chroot. Chroot is complaining that it can't find /mnt/usb/bin/mount (from the above example), which means that an earlier part of debootstrap failed to put it there. From the debootstrap.log above (and I have the same errors in mine) the first error is:

ar: /mnt/usb/: File format not recognized

So that's where debootstrap is breaking (or giving the first error message).

After reading this forum, I tried bootstraping the previous version of Ubuntu (breezy, as I am running dapper) and it appears to be working (it did not fail at the same point as earlier). It looks like debootstrap'ing the previous version works but doing the same as the system you run it on fails.

Can confirm this on an attempt to debootstrap a Debian sid chroot under Feisty.

Running the command where the `W' warning emits (chroot /mnt/usb mount -t proc proc /proc) shows that libdevmapper isn't present in the chroot, which is somewhat required by the mount call on /proc to succeed. Including that in the debootstrap invocation ( e.g. `--include=dmsetup,libdevmapper1.02' or libdevmapper1.02.1 when pulling from Debian sid) should work.

After a few moments I got a Debian sid debootstrap successfully completed.

The workaround for me was to create a symlink of $chroot/lib/libdevmapper.so.1.02 to $chroot/lib/libdevmapper.so.1.02.1 so that the chroot's mount of /proc will work.

I stumbled on this while trying to create sid chroot on Feisty too.
Thanks for the workaround Zak.

Had the same problem.
that`s not chroot bug, it might be debootstrap.
Check your "/mnt/usb/etc/apt/sources .list", when using image and file protocol.
Instead of "deb file:/mnt/iso/ubuntu edgy main", you propably have "deb http://debootstrap.invalid edgy main"

debootstrap? forgets repository path, thats all .

This was fixed in Feisty cycle.

Actually, I just experienced the same problem in hardy. As described by czapa_ols, the repository path isn't making it from the command line into etc/apt/sources.lst, and presumably as a result, /bin/bash isn't getting copied into the bootstrap-target.

Same issue here with hardy

which image was used?
using LiveCD (Desktop Edition) will not work as its does not have required packages.
Debootstrap parses Packages file for debs with required and important priority.
With LiveCD it finds only one deb : "libatm1" which is properly copied :D

I've got this issue on a hard-drive-installed Ubuntu 8.04 Desktop system (not a LiveCD session).

By the way, pardon the launchpad-newbie question, but does somebody need to open a new bug for this? It doesn't look like this one's going to get (re-)assigned to anyone, since it's listed as having a "fix released."

@Mick Bauer - which image was used AS REPOSITORY?? or you`ve got this issue when using http?

I used the Ubuntu 8.04 Desktop CDROM as the repository, mounted to /dev/cdrom. But as far as I can tell, debootstrap was instead trying to use "deb http://debootstrap.invalid edgy main" as the repository -- that's what got written to the chrooted /etc/apt/sources.list file. :-(

ignore sources.list at this stage, debootstrap uses cp to "retrive" packages while using file:/

and as i wrote before
using LiveCD (Desktop Edition) will not work as its does not have required packages.

Debootstrap parses Packages file for debs with required and important priority.
on LiveCD there is only one such deb : "libatm1"

fell free to compare
http://archive.ubuntu.com/ubuntu/dists/hardy/main/binary-i386/Packages.bz2
with one on your CDROM

without other packages "debootstrap can`t chroot" because it has nothing to chroot in to.

IT IS NOT A BUG, IT`S FAULT OF USELESS CDROM REPOSITORY. (only one package of one hundred required)

maybe DVD will do.

Maybe not a bug, but possibly a design flaw: It seems reasonable to expect that a CDROM you can use to completely install Ubuntu should also be usable for creating bootstrap-images. Obviously the necessary packages *are* present; just not in a format/place debootstrap expects.

Regardless, this issue really ought to be spelled out in Ubuntu's debootstrap documentation.

Does this work now, with the latest Jaunty / Karmic CD's? :)

This bug is still existing in jaunty.
Running amd64 and using --arch=i386

This may be a stupid question, but I'm asking anyway: do you have ia32-libs installed? Maybe this has to do with amd64 not being able to run i386 processes, maybe even because it can't find ia32-libs files.

Could you try something like compiling a Hello World on your amd64 machine, putting it in the debootstrap path under bin/helloworld, then running chroot /mnt/foo /bin/helloworld ? If that works, try compiling a Hello World on i386, running it on your amd64 machine, then putting it in the debootstrap under bin/helloworld2 followed by chroot /mnt/foo /bin/helloworld2. :)

Yes ia32-libs are installed.
I saw that the directory is almost empty.
I executed the failing command alone:
Error message:
chroot: cannot run command `mount': No such file or directory
Even if I copy /bin/mount into the directory it isn't found.

I've tried to do it with the amd64 iso file, its the same :( :

sudo debootstrap jaunty debjaunty/ file:///home/u/Desktop/jaunty64
I: Retrieving Release
I: Retrieving Packages
I: Validating Packages
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Checking component main on file:///home/u/Desktop/jaunty64...
I: Retrieving libatm1
I: Validating libatm1
W: Failure trying to run: chroot /home/u/debjaunty mount -t proc proc /proc

It works with the *server* iso. Both i386 and amd64. I was using the
*desktop* one!

I just tried debootstrapping lucid i386 on karmic amd64 and the W: Failure trying to run: chroot /somepath mount -t proc proc error occurred. I then tried 'debootstrap --arch=i386 --foreign somepath' and then chroot ed to somepath and did a '/debootstrap/debootstrap --second-stage' successfully. Can anyone confirm this?

I can confirm problem still exists on lucid 10.04 when trying to use desktop cdrom.

A basic debootstrap lucid /mnt/kubuntu-10.04 works fine.

This needs to be fixed or doc updated to avoid wasting folks' time...

Richard,

Please don't go around bringing back to life an already fixed bug! The fact that you used the desktop iso as the source repository for a debootstrap task means that you have a basic misunderstanding of the way the tool works, not a bug in the tool itself. May I suggest the following readings?

https://wiki.ubuntu.com/DebootstrapChroot

https://wiki.ubuntu.com/DebootstrapSchroot

It seems reasonable to suppose that an install ISO would have the required files on it! Doc should be updated. I am not the first to suggest this it seems.

As I already stated, this is not a bug.

Could Ubuntu-QA mark this bug as WONT-FIX? Thanks

Actually here are two bugs in one bug report.
One ,related to libdevmapper.so ,that was fixed a long time ago. (comments #4-#6)
Second, related to missing packages on *Desktop* iso, that should probably be marked as WishList

@Richard Lennox, please live this one alone , and feel free to report the second separately.
Best Regards