| gabriel rosenkoetter on Sat, 26 Jan 2002 12:30:14 +0100 |
|
On Fri, Jan 25, 2002 at 10:22:50PM -0500, Samantha Samuel wrote: > It does work on new kernel. No support on old one. Sorry if that was not > clear earlier. The old kernel doesn't support LKMs or there's no LKM compatible with the old kernel that supports your network card? (Kind of moot, really.) > Um...Dunno how to mount another partition. I know in Linux it would be > <dev>=/dev/hda1 > <mnt>=/mnt > In netbsd its wd0, wd1, so its /dev/wd0?? I couldn't figure out how to see > the entire hard-drive. I'd have to see the output of NetBSD's disklabel(8) to answer this question. Right now, I'd guess that NetBSD only has a conception of the NetBSD portion of the disk (that is, from the beginning of cylinder 638, based on the below). It's easy to make it aware of the rest of the disk and still be bootable. After you do this, based on Linux's fdisk output, you'd want to mount /dev/wd0a. But let me see the disklabel output and explain what it means before you go trying to do that. (Incidentally, if you've made a separate NetBSD swap area, you're wasting some of your disk. No reason the two can't share a swap partition. There's no way they'd get confused about data left over on it from the other OS being valid.) > Oh, I found the dissapearing dir in /home/lost+found under numbered dirs, > among other things. I found other user's (this is my own comp) stuff on > there too, plus many proggies I had made accessible only to root, and > so on that I discovered to be missing. I am pretty convinced > its because of the overlapping when I installed netbsd. Things end up in lost+found as a result of file system corruption, not as a result of their on-disk bytes being forcefully overwritten. (inodes lacking file system references will be moved to lost+found by fsck. That's just about the only way things get there--beyond your actively moving them there--on most file systems.) After seeing the output of both OS's fdisk, you are only overwriting Linux stuff with NetBSD stuff if Linux's fdisk actually starts counting at 0 instead of 1, despite claiming your sectors start at 1. But I'm pretty sure that Linux's fdisk just starts counting at 1. By which I mean that the following lines (interspliced) are saying that both OSes have exactly the same conception of your disk: > 0: sysid 131 (Linux Native) > start 63(which I believe is the right num), size 10249407 (5004MB) > beg: cylinder 0, head 1, sector 1 > end cylinder 637, head 254, sector 63 > /dev/hda1 1 638 5124703+ 83 Linux Offset the count-from number. Both OSes think Linux takes 637 cylinders and 10249407 disk blocks. (Reporting blocks in 1024 KB blocks may be more human readable, but considering the on-disk block size is 512 KB on any modern drive, it's less confusing and more exact to stick with 512 KB blocks in the long run.) > 1: sysid 169(NetBSD) > start 10249470, size 5002MB > beg: cylinder 638, head 0, sector 1 > end: cylinder 1022, head 254, sector 63 (is this the prob?) > /dev/hda2 * 639 1276 5124735 a9 NetBSD The NetBSD partition starts at the beginning of the 639th cylinder (that is, cylinder number 638) and is 10249470 disk blocks long. The fact that NetBSD's fdisk claims it ends on a cylnder before it actually does is just to remind you that you can't boot any partitions that live on the 1024th cylnder or beyond unless you've got a particularly smart BIOS. (Note that cylnder 1022, track 254, sector 63 is the last track of the last secter of the last cylinder before the 1024th.) (What's printed by NetBSD's fdisk is exclusively what the BIOS can see. What's printed by NetBSD's disklabel is exclusively what the OS sees in the OS-friendly label on the disk. What's printed in Linux is a combination of the two, losing some plausibly relevant information. Like, for instance, what's actually *in* that NetBSD partition... which is why I want to see your disklabel output.) > > borked? (What's the inode number of /etc/passwd? Of the user's home > inode number:480986. May I know what can be determined from this number? inode numbers are loosely sequential (till you run out and wrap around), assigned on creation of the node. I'm thinking that /home/<user> has an inode number fairly high up... as, probably, does everything you discovered in lost+found. This would support the "your disk wasn't sync'ed when it flaked out, and fsck moved the inodes-without-fs-anchors to lost+found" theory. > No idea as to how to find out what cylinder it is on. Doesn't matter, really. I'm as sure as I could be without being at your machine's console that the NetBSD install isn't stomping on the Linux portion of the disk. > > You ARE installing NetBSD on a separate MBR and fdisk partition, > > right? > Separate MBR: No. > Separate partition: Yes. > Didn't know you could have more than one MBR. You misunderstood my question. I wanted to make sure that you were putting each OS in separate MBR partitions. You are. > Didn't. [damage NetBSD to recreate the home directory] Another sign they're not overlapping. There'd be a good chance that forcing this data to disk would overwrite the boot blocks, kernel, portions of /bin... but more importantly, damage the NetBSD file system so that it'd need to be fsck'ed on boot (and end up being unreparable) if the partitions overlapped. > That is what I thought too, but since the user's account was hosed twice > after installing NetBSD, it seemed a little fishy. Istm that this has nothing to do with NetBSD and everything to do with your Linux 2.4 kernel either not dealing properly with ext2fs, with your IDE controller, or with your hard drive's on-board controller and DMA. It's possible that something in the NetBSD installation (perhaps the installation of boot blocks) is futzing with your ext2fs partition somehow, but judging by what you posted here, the actual data portions of the disks do not overlap. > bootman is the bootmanager for BeOS. Got mixed up in the names. :) I think the NetBSD/i386 bootloader is just called boot. -- gabriel rosenkoetter gr@eclipsed.net Attachment:
pgpJwu2fBgB4l.pgp
|
|