Date: Sun, 28 Dec 2003 02:21:23 +0100 (CET) From: Barry Bouwsma <freebsd-misuser@remove-NOSPAM-to-reply.NOSPAM.dyndns.dk> To: Hackers of the Hallowed Order of FreeBSD <freebsd-hackers@freebsd.org> Subject: dev_mkdb coredumps under -stable with a different root disk... Message-ID: <200312280121.hBS1LNs08470@NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk>
next in thread | raw e-mail | index | archive | help
[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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200312280121.hBS1LNs08470>