dev_mkdb coredumps under -stable with a different root disk...

[Barry Bouwsma]

[bla bla drop address to reply bla bla archives bla bla IPv6 bla]

Howdy,

This probably isn't the right place to ask, but here goes anyway...

Is there a good reason why `dev_mkdb' should coredump when encountering
selected devices in a /dev directory on a different filesystem than that
containing the kernel which I booted?  It has no problems on the /dev
directory on the disk I used to keep kernel, root, and all -- only on
a different disk to which I copied (then later re-created) the /dev
directory from the original.  FreeBSD 4.x in use from some months back.

Also, the /var/run directory on the original disk contains a suitably
small dev.db file:
-rw-r--r--  1 root  wheel  32768 Dec 24 18:56 /var/run/dev.db
while that from the not-original disk is far larger:
-rw-r--r--   1 root  wheel    150929408 Dec 18 11:29 dev.db
which probably explains why it takes several minutes to run, but I
still wonder *why* it's much larger and induces coredumps.


I got fed up with the CMD640 chipset on this old machine and decided
to use it for little more than booting the kernel.  So I tar'red me up
the / and /usr filesystems and untarred them onto a firewire-attached
disk.

Well, actually, I first tried `pax' for fun, but upon extracting the
/dev directory, it seemed all devices were created with major/minor
numbers of 0, though my system (4.something) is a bit old.  `tar'
only had a problem with two foo.ctl devices, complaining the number
was too big or something, so I went ahead with that.

Booting, then mounting root at ufs:/dev/daFOO went mostly okay, but
as noted, dev_mkdb kept sig-11'ing on me.  So I recreated /dev from
scratch with MAKEDEV if something was messed up in untarring.

Still no joy.  In order to achieve joy, it turned out I needed to
delete a good number of devices:  apparently all raw disk and tape
and similar devices; plus all `c' disk partitions and such, and maybe
a few others I don't remember -- I think the .ctl devices that failed
`tar' also had to fall victim.  Finally, dev_mkdb finished.

Other than that, and a small bit of minor tweaking, things are working
fine, and the accursed CMD640 only gets to hog interrupts at boot,
after which it's no longer needed for the system root and utilities
and logs, and I appear to achieve the performance I sought.

Is there a simple explanation why a manually-specified root filesystem
somewhere else (specified in loader.conf) triggers an intense dislike
of raw devices and whole-device partitions?  Might a different block/
fragment size have something to do with it?  (I shared an existing
partition created with a completely different purpose in mind, for
which 65536/32768 b/fsize was more appropriate for multi-gig files.)


thanks,
Barry Bouwsma, puzzled