View Single Post
Old 29th January 2012
IdOp's Avatar
IdOp IdOp is offline
Too dumb for a smartphone
 
Join Date: May 2008
Location: twisting on the daemon's fork(2)
Posts: 1,027
Default

Quote:
Oh, you were still talking about ext2...
Yup, I just wanted to be sure that comments/advice about one approach wasn't applied to the other, as of course that could be trouble.

BTW, I agree with you that it would be better to use a native FS, and ext2 is just a "last resort". Let's look at that in moment, but just a quick word of encouragement about ext2. My main system is dual boot Linux and NetBSD; I use the same ext2 FS as HOME for both systems, rw of course. The only problem I've had is that NetBSD can't fsck the FS, but since I boot Linux regularly this isn't a big deal. But just because it "works for me" is no reason you should do it, and the native approach is probably better for your circumstances. So enough of ext2 for now.

I had some thoughts overnight abour your "expanding things" approach, so I'll give them first, then try to answer some of your other questions as best I can.

So you have 40G free after the NetBSD slice. One could think about doing something like this:

0) Make a record of the current fdisk partitions, in Linux

# fdisk -l /dev/hda > fdisk-record

This is for if things don't work and you decide to go back to what you had.

1) With fdisk in Linux, increase the size of the NetBSD slice E8 to absorb some or all of the following 40G. (Don't overlap into E9.)

Note: at this point, the partition table will not agree with the existing disklabel's idea of what the NetBSD slice (c: on disklabel) is! NetBSD may or may not boot with this inconsistency; I dunno never tried that!

2) Within the new extra area, put one or more (your choice) new native FFS filesystems. This means editing the disklabel to replace existing entries for MSDOS, NTFS, or Linux ext2, with new disklabel partitions. Using disklabel should be done from NetBSD, *but*, because of the problem noted at 1), it may not be possible or safe to do this by booting the on-disk NetBSD! So I think a good idea would be to do this disklabel editing from a booted install CD. You could exit the install system at the start to get a shell, and run disklabel from there.

Of course, don't overlap anything else in the NetBSD slice. Plan the desired locations and sizes carefully beforehand.

3) Once the disklabel is ready, things should be in sync and should boot [*] the hard disk NetBSD. Then, newfs the new partitions (this could also be done from the install CD after editing the disklabel ... might be a better idea).

[*] Well, from your PS, I don't understand how you boot, so you better think about this point!

4) mount the new partitions, check them out, enter them in /etc/fstab and enjoy the new, improved, expanded NetBSD slice.

Note: I've never had the need to do the above, so they're just ideas I think should work. I hope this is helpful idea-wise. Comments from others on this are welcome!

Quote:
I did it, several times. But, I'm still missing something, I still don't feel I've understood... probably because I should know something I don't know.
I've also found the man page hard to understand in parts, although have managed to do the things I needed to do without understanding all aspects of the command.

Quote:
What does "in-core" mean? And where should I install the disklabel - "in-core", "on-disk", or both?
My understanding (probably imperfect) of this is that a copy of the disklabel is kept on the hard disk in the early part of the NetBSD slice. The disklabel is a BSD-analog of the DOS-type partition table. The kernel reads it from the disk to find out where the partitions it can access are located. It keeps a copy of this "in core," i.e., in the memory used by the kernel. So you could in principle update the on-disk label by writing to it and the kernel wouldn't know about the changes ... until you rebooted. So if you want to use the changes now, tell the kernel. I hope this is about right. Again, corrections are welcome.

Quote:
Also, I would feel more comfortable to export the label first to a "protofile" and edit that file, rather then editing directly. Should I apply the option -W to re-import it?
It's good to be cautious like that. If I understand -W right, it sounds like it is allowing writes by other programs (not disklabel). So i don't see why you'd need that. Probably just -R is enough.

Quote:
And also, I don't understand the relation between disklabel, installboot and maybe something else... (although it's already another pair of shoes... see the " P.S:" at the bottom)
You might want to start by looking at boot(8) and following through other related pages from there, such as installboot(8) and mbr(8).

Quote:
P.S. Let me explain: This NetBSD is a "reincarnation" of an old NetBSD I used to have, but, that became unbootable with the new motherboard. I've managed to "resurrect" it recently by upgrading it to 5.1.1.x. That old NetBSD, at the begining, used to have a boot menu with 3 options: NetBSD, Windows and Linux (Grub on another drive). At some point, after an incident (I don't remember what it was), I've lost the boot menu. I've been able to rescue it,
but, with the only option "1.Windows" (!?) I have still been able to boot to NetBSD since my Windows bootloader has had the NetBDS boot image (or via Grub on another disk). and it's same now, with this "resurrected" NetBSD. Even if I press "0" or "2", I get something like "? Error". Of course, it's not an issue, but, it's still a bit annoying, since I can't boot directly to NetBSD. Maybe while I'm around disklabel, I might fix it too?
I don't think this can be fixed with disklabel. It sounds complicated, and since I don't use Windows or Grub, I might only be of peripheral help with it. FWIW, I install LILO on the MBR and boot NetBSD with an "other = /dev/hdaX" entry. There are many ways to boot, however, and no reason you should do it this way.
Reply With Quote