Re: sarge installation fails to populate directories

[brownh@hartford-hwp.com (Haines Brown)]

> Haines Brown wrote:
> > The problem is that /usr and /var directories are empty. I struggled
> > with this with debootstrap for a while, although usually the /var
> > partition was filled, but never /usr until advised to use
> > cdebootstrap. That went well and partitions were filled, but for a
> > reason irrelevant here, I started again from the beginning, and now
> > cdebootstrap wouldn't fill /var and /usr. All the base packages were
> > downloaded and unpacked, but for some reason one or more directories
> > not seen. 
> 
> That's quite stange, I have never heard of or experienced
> debootstrap having such a problem. I'd look to see if my kernel or
> filesystem or disk are broken somehow, and strace debootstrap to see
> what's happening when it tries to create files in those directories.

Joey,

a) I'm doing a cross installation, and there's no kernel yet on the
target disk. I assume you don't mean my local kernel (which is stock).

b) I went to check on the reiser filesystem, but couldn't run fsck
because "device is busy." The best I can make out, once I run chroot
on the target disk, it no longer can be umounted without a reboot. But
otherwise, I have no reason to supect a broken file system, since I've
done many partition re-initializations on this disk without any hint of
problems.

After rebooting (see below), I ran fsck on the unmounted target:

  # fsck -t reiserfs /dev/sdc
  reiserfs_open: the reiserfs superblock cannot be found on /dev/sdc
  failed to open the filesystem. 

I ran 

  # fsck.reiserfs --rebuild-sb /deb/sdc
 
But I did not know enough to continue:

  My reiserfs is apparently version 3.6.17
  It apparently could not find the superblock
  Enter size: I accepted the default 4096 as a guess
  No journal device was specified: I say yes to journal default
  Did you use resizer?

At this point I was in way over my head and backed out. However, I
don't see how a damaged or absent superblock would affect
cdebootstrap. 
  
c) As for the hardware, there is indeed another anomaly. I abandoned
the disk at the begining of the year because things went
haywire. Hitachi/IBM provided a hard disk test utility to see if I
could replace it under warrantee. However, the disk passed that test
with flying colors, and I concluded my problems were software
related. However, since then, running smartctl, I did discover that
there was one write error correction and one correction algorithm
invocation. However, I assumed this was simply reporting a bad sector
that had to be put out of action.

d) I ran an strace on cdebootstrap, but the results complicated. I ran
it first while the target device was still mounted and it ended with
the error it could not mount /proc:

  ...
  munmap(0x4001a000, 4096)                = 0
  close(6)                                = 0
  munmap(0x4001b000, 4096)                = 0
  mount("proc", "/mnt/debinst/proc", "proc", , 0) =
	       -1 EBUSY (Device or resource busy)
  write(3, "E: can\'t mount proc\n", 20)  = 20
  write(2, "E: can\'t mount proc\n", 20)  = 20
  munmap(0x40018000, 4096)                = 0
  munmap(0x40019000, 4096)                = 0
  exit_group(1)                           = ?

Obviously I needed to umount the target, but knowing of no other way,
I rebooted. This time I was careful not to run chroot to mount the
target disk locally (apparently, it was the chroot command that
prevented an umount). 

Here are exactly my steps subsequent to the boot. The target disk
is already partitioned and the partitions were initialized, including 
swap. I booted and:

  1. # mount /dev/sdc1 /mnt/debinst
  2. # strace -o /opt/tmp/strace cdebootstrap sarge /mnt/debinst
     http://http.us.debian.org/debian 

This time /proc mounted OK: 

  ...
  munmap(0x4001a000, 4096)                = 0
  close(6)                                = 0
  munmap(0x4001b000, 4096)                = 0
  mount("proc", "/mnt/debinst/proc", "proc", , 0) = 0
  pipe([4, 5])                            = 0
  pipe([6, 7])                            = 0
  fork()                                  = 1383
  close(5)                                = 0 

but the process termininated with:

  E: Couldn't install root!

In the strace for this:

  ...
  poll([{fd=4, events=POLLIN, revents=POLLHUP}, {fd=6, events=POLLIN, 
     revents=POLLHUP}], 2, -1) = 2
  waitpid(1581, [{WIFEXITED(s) && WEXITSTATUS(s) == 1}], 0) = 1581
  close(4)                                = 0
  munmap(0x4001a000, 4096)                = 0
  close(6)                                = 0
  munmap(0x4001b000, 4096)                = 0
  write(3, "E: Couldn\'t install root!\n", 26) = 26
  write(2, "E: Couldn\'t install root!\n", 26) = 26
  oldumount("/mnt/debinst/proc")          = 0
  munmap(0x40018000, 4096)                = 0
  munmap(0x40019000, 4096)                = 0
  exit_group(1)                           = ?

I'm not sure what "installing root" implies in this context. 

That's it. To judge by google, the Can't mount root error message from
cdebootstrap is apparently not common. Last year it came up once with
a particular version of gcc, but I'm running sarge, and presumably
that problem was fixed. 

Haines Brown