First, I have to say - I'm much more familiar with Linux than with BSD and I'm not sure I really understand the BSD terminology or concept of labels and slices.

Now, my situation: I have NetBSD installed (and working well) on a disk with various other Windows and Linux partitions. NetBSD is installed on two partitions (/dev/wd0a for / and /dev/wd0h for /usr... well, and also /dev/wd0b for swap). They both fit into what disklabel declares as "unused", that is "c" (I suppose it would be /dev/wd0c) and what is being seen "from outside" (for example - parted from Linux) just as a single "sun-ufs" partition (but, from Linux I can only mount the NetBSD's /, it doesn't see it's /usr... I suppose it's normal ). That wd0c (or, maybe, better to say - wd0h), happens to be, by physical order on the disk, the very last partition that fits into the maximal range disklabel can see (I have all partitions from wd0e to wd0p, of Windows or Linux type, and they are all before the NetBSD partition; there're also some partitions at the and of the disk, but, they are ignored by disklabel).

Now, my problem: it's coming to be quite packed on my /usr; in fact, it's more than full and I've already had to pull out /pkgsrc ant to declare a new path, but, it's still nearly full. And I have a plenty of free space just after the NetBSD partition. I'd like either to make a new partition, or to enlarge (indestructibly!) the present /usr. I don't mind which solution I would apply, but, I'm not sure if any of them is available (and, if yes - how?)

A) Is it possible to resize (indestructibly!) a NetBSD partition? Maybe from a LiveCD? With another BSD?

B) If I create a new partition, would disklabel see it? May I instruct disklabel to ignore some of Windows partitions and just to jump over, so that the new partition may fit into its range? For, example, I don't care to have access from NetBSD to the present wd0g... may I make a NetBSD partiton and tell disklabel to take it for a new wd0g (obviously, I'd like to preserve "wd0h" for /usr)? And... would I lose that partition (Windows or whatever) on the disk, too? For other OS's.

Can I do something? (Except to reinstall NetBSD and take more space.) And, in the case of "yes", please - what exactly? Thanks in advance.

Last edited by J65nko; 28th January 2012 at 02:40 PM.
Reason: Some whitespace added ;)

Somebody ported this to NetBSD, but AFAIK it is not part of the NetBSD base system.

I've just found it. However, it obviously cannot be run on a mounted partition. So, can that utility be found on a FreeBSD LiveCD (supposing that it exists) and would it be safe to run it on a NetBSD partition?

Quote:

BTW your problem would be more understandable if you would post your fdisk and disklabel output

I'm not familiar with tools to re-size a NetBSD partition, so I can't answer some of your questions about that, but a few general comments might be helpful.

Any resizing would have to stay within the NetBSD slice of the disk, which is E8 on your fdisk output and c: on your disklabel output (also, d: on the disklabel output refers to the whole disk). Since there are other extended partitions on either side of the NetBSD one, the possibility of expanding the NetBSD slice would seem to be nil unless you eliminated the neighbours, probably/perhaps not an option for you.

One thing you could consider is to create a new Linux ext2 partition outside of the NetBSD slice and use it (or redeploy an existing partition). It could be defined in your disklabel to replace one of the other many DOS and Linux partitions if you don't use it from NetBSD. Then the new ext2 one could be mounted in the NetBSD filesystem wherever you want. To create an ext2 that NetBSD can work with you need to use the following options at mke2fs time:

Code:

-I 128 -O ^dir_index

This is admittedly not the ideal solution but it could be considered to get something workable if other ideas don't pan out.

Any resizing would have to stay within the NetBSD slice of the disk, which is E8 on your fdisk output and c: on your disklabel output (also, d: on the disklabel output refers to the whole disk).

That far, I think I've already understood "slices", even myself

Quote:

Since there are other extended partitions on either side of the NetBSD one, the possibility of expanding the NetBSD slice would seem to be nil unless you eliminated the neighbours, probably/perhaps not an option for you.

Well, not exactly. The disklabel output might not be very clear, since it isn't listed by order on the disk, but, there is about 40GB of free space *between* the NetBSD partition and the next Linux partition near the end of the disk. (And even if it were not, I could make some space, that wouldn't be a problem.)

Quote:

One thing you could consider is to create a new Linux ext2 partition outside of the NetBSD slice and use it (or redeploy an existing partition).

But, NetBSD wouldn't see it(?) As well as it doesn't see those Linux partitions at the end of the disk.

Quote:

It could be defined in your disklabel to replace one of the other many DOS and Linux partitions if you don't use it from NetBSD. Then the new ext2 one could be mounted in the NetBSD filesystem wherever you want. To create an ext2 that NetBSD can work with you need to use the following options at mke2fs time:

Oh, BINGO! Well... not yet But - a sort of, a halfBINGO Anyway, it was definitely a thing I wanted to know. So, it is possible! Disklabel doesn't need to comprise contiguous partitions. So, how could I do it. What should I do to pull a Windows partiton out of it?

Quote:

This is admittedly not the ideal solution but it could be considered to get something workable if other ideas don't pan out.

Thank you very much! Now, there is something that, in extremis, I can do (I only need to know how exactly I should deal with disklabel). Of course, I'd still prefer to have a native filesystem. (And I do have a free space!)

Awesome (you had mentioned something about d: so I thought I'd add a comment about it.)

Quote:

Well, not exactly. The disklabel output might not be very clear, since it isn't listed by order on the disk, but, there is about 40GB of free space *between* the NetBSD partition and the next Linux partition near the end of the disk.

You're quite right. I had just assumed your fdisk E9 was located contiguous at the end of the NetBSD E8, without checking. But yup there's 40Gig in between there.

Quote:

But, NetBSD wouldn't see it(?) As well as it doesn't see those Linux partitions at the end of the disk.

Well, I assume all those DOS and Linux partitions were added by default, until the disklabel capacity to hold more partition references was full. But if you're not using one of those DOS/Linux disklabel entries, you can get rid of it and put in a new definition of your own. In this way you can reference one or more partitions that you really want. Just edit the disklabel.

Quote:

So, it is possible! Disklabel doesn't need to comprise contiguous partitions. So, how could I do it. What should I do to pull a Windows partiton out of it?

You'll have to begin by studying carefully the disklabel(8) man page. You'll probably want to use the -e flag, which will edit it with what's in your EDITOR environment variable (e.g., emacs, vi). Then you just have to over-write, in the editor, one of the existing DOS or Linux entries with the start, size and filesystem type of the new ext2fs partition you really want to access. The overall format should be the same as you see for existing Linux entries.

Disklabel can be confusing and scarey at first, and it is very important to be careful not to trash any entries you want to keep, because this is after all how the OS tries to find them and you don't want it going off into the wrong part of the disk!

In this way you can reference one or more partitions that you really want. Just edit the disklabel.

So, what my proceeding should look like?
1st step: fdisk, to expand the slice? I think I've found something about somewhere in forums. Is it right? (If I should do it) can I do it from NetBSD (or, maybe, it should be done just after the boot prompt, by pressing a key and running a command?) and would it be safe for my /dev/wd0a and /dev/wd0h? (Of course, if I "expand" it the wrong way, it would be very unsafe )
2nd step: disklabel editing
3th step:newfs or something, to create the new fs.
Is that proceeding correct, or maybe I should first create the fs and only then to edit disklabel?

Quote:

You'll have to begin by studying carefully the disklabel(8) man page. You'll probably want to use the -e flag, which will edit it with what's in your EDITOR environment variable (e.g., emacs, vi). Then you just have to over-write, in the editor, one of the existing DOS or Linux entries with the start, size and filesystem type of the new ext2fs partition you really want to access. The overall format should be the same as you see for existing Linux entries.

Disklabel can be confusing and scarey at first, and it is very important to be careful not to trash any entries you want to keep, because this is after all how the OS tries to find them and you don't want it going off into the wrong part of the disk!

So, what my proceeding should look like?
1st step: fdisk, to expand the slice? I think I've found something about somewhere in forums. Is it right? (If I should do it) can I do it from NetBSD (or, maybe, it should be done just after the boot prompt, by pressing a key and running a command?) and would it be safe for my /dev/wd0a and /dev/wd0h? (Of course, if I "expand" it the wrong way, it would be very unsafe )

WAIT No, do not proceed by using fdisk to expand the slice. Expanding of slices and partitions was outside the context of the idea I was proposing and is potentially very dangerous. (That is not to say that something along that line couldn't be done, but it is another matter entirely.)

What I was proposing was either:

a) create a new logical partition in your extended partition, at the end of it, if there is room.
This would be done with fdisk.

OR

b) take one of your existing partitions, which you are not using (if there is such) and re-purpose it (after backing up anything you want to keep from it, of course).

If either of these are possible you would have a "new" partition, which you would make an ext2 file system on (using Linux' mke2fs) with the proper options so NetBSD can use it.

Quote:

2nd step: disklabel editing

Correct. Once you have the new partition formatted as ext2, then go to NetBSD and edit the disklabel after studying the man page carefully. If unsure, ask for help before proceeding. The basic idea is to reference the new partition in the disklabel, instead of one of the other existing DOS or Linux partitions, one which you don't intend to access from NetBSD. For example, if you decided that MSDOS partition m: would never be needed from NetBSD, you could use the "m: slot" in the disklabel to refer to the new ext2 partition instead. Simply edit this line in the disklabel inserting the new size and offset (these you can get from fdisk output). And edit the fstype column from "MSDOS" to "Linux ext2". Save the disklabel and reboot if necessary.

Quote:

3th step:newfs or something, to create the new fs.
Is that proceeding correct, or maybe I should first create the fs and only then to edit disklabel?

I would do the mke2fs from Linux right after creating the new partition [case a)], or for case b) to reformat the partition you want to re-purpose after backing it up.

Step 3 would then be to mount the new partition in NetBSD:

#mount -t ext2fs -r /dev/wd0m /some/where

Again, this is my original alternate approach, nothing to do with expanding things.

If either of these are possible you would have a "new" partition, which you would make an ext2 file system

Oh, you were still talking about ext2...

Quote:

after studying the man page carefully.

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. For example:
It says:

Code:

disklabel -e -r sd0
Read the on-disk label for sd0, edit it and reinstall in-core as well as
on-disk.

What does "in-core" mean? And where should I install the disklabel - "in-core", "on-disk", or both?
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?
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)

Quote:

Again, this is my original alternate approach, nothing to do with expanding things.

Well, it's rather logical, if we're talking about ext2 (Although I would certainly make it wrong, without your option). I'll keep this solution as (a relatively simple) last thing, if nothing else comes out, but, I'll wait another couple of days since I'd really prefer to have a 4.2BSD fs. I think that an ext2 could potentially be dangerous. I certainly wouldn't mount it from Linux and above all I wouldn't mount it rw, nor I'd have it in (Linux) /etc/fstab... but, I might run a LiveCD and, you know, those new LiveCD's, these days, may like to mount whatever they find, since some people may believe it a good way to please as much Windows converts as possible - they'd be able to play with their C: as soon as the CD starts and they'd find Ubuntu to be a "cool thing".
But, anyway, you gave me another idea, not related to this particular problem: I might create an ext2 partition to be used as a "parking" place for VM-ware guest OS's, both for NetBSD and Linux.

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?

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.

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)

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.

So I think a good idea would be to do this disklabel editing from a booted install CD.

You've answered before I asked! All you've said sounds very reasonable to me (although it doesn't prove anything ) and I really hope it will work. Oh, just another question and I hope it will be the last one Can I prepare a "protofile" in advance, edit *that* file and then, from the install CD shell, just load the edited copy? And what exact command should I use? However, i think I'll wait a bit, to have a really fresh mind when I do it

Quote:

Comments from others on this are welcome!

I couldn't agree more!

Quote:

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.

I've just wandered whether I'd need it. Because the man page states:

Code:

-N Disallow writes to the disk sector that contains the label. This
is the default state.

Of course, I'll first try wuthout "-W".

Quote:

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.

Well, I already have at least two ways to boot to NetBSD. I was just looking for a way to be able (as I used to be, at the begining) to bypass the foreign boot loaders and to boot directly to NetBSD. However, never mind...

BTW, I agree with you that it would be better to use a native FS, and ext2 is just a "last resort".

Oh, yes... and yet another risk about ext2: One day I might wish to resize my partitions and to catch that one, too. I'd probably do it from Linux. And that may happen after a long time, so that I forget to update my disklabel in NetBSD. And tthen...

Can I prepare a "protofile" in advance, edit *that* file and then, from
Athe install CD shell, just load the edited copy? And what exact command should I use?

I think you can, and it's a good idea. I haven't used protofiles much, but from the man page example it looks like the command is

#disklabel -R wd0 protofile

(assumes wd0 is your disk). As an experiment you might try that with a protofile that has not been altered in any way, and see if it still works. Another issue is to be sure you can access the protofile from the install CD. Since we're worried the disklabel slice entry at this point doesn't match the disk partitions, you might have to put protofile on an ext2 and see if you can access it from the install CD shell. This too could be tested before doing anything for real.

Quote:

However, i think I'll wait a bit, to have a really fresh mind when I do it

In Step 2, while editing the disklabel to add a new BSD partition, you must also edit the slice definition c: so that it matches the fdisk logical partition expansion done in Step 1.

That has always been the thing I was mostly concerned about. Especially since I discovered that wd0a+wd0h+wd0b(swap) sizes do not exactly match the wd0c size! The difference (overlapping) is very small (189 sectors), but, here it is. And that has been done by NetBSD itself, during the installation!
Now, I'm preparing to do some tests (to put in and out some existing partitions), I've prepared the protofiles and I'm just going to boot into NetBSD. I'll do it first with another disk, without any slices.

Excuse me, are you sure it should go with that regex metacharacter? (Why?)

Quote:

Originally Posted by IdOp

Code:

-I 128 -O ^dir_index

When, under Linux, I try to run an operation on that partition (with sfdisk, or parted), I'm getting "

Code:

Error: File system has an incompatible feature enabled.
Compatible features are has_journal, dir_index, filetype,
sparse_super and large_file. Use tune2fs or debugfs to
remove features.

And why do I need to run an operation (move) on it? Because I've come to the point to do the first trial (not only a trial, it's also a step in my proceeding) with the NetBSD install shell. (I've already done two trials with re-arranging the existing partitions inside disklabel.) Good news - it works (I mean disklabel from the install shell). Bad news - it have found that my partitions (wd0h and its new neighbor) were overlapping. (Of course, it's also a good news, rather then bad, as it doesn't let you go on if your partitions are overlapping). What I've done? I've created two ext2 partitions next to the NetBSD's one, at its right side. The first one (the one in the middle) is meant to serve just as a placeholder for the future NetBSD partition (unnecessary step, of course, but, I think it can make the proceeding more clear and I can prepare the disklabel - apart of wd0c - as well as /etc/fstab - apart of partition type). The second one happens to be wanted (it should be the "parking place" for VMware guest OS's I've got the idea a couple of posts above), but, I would have created a (temporary) partition in any case - to serve me as a marker, as a delimiter of the free space when I delete the first one to make room to enlarge the slice. So, since I plan to continue to use that partition the way I've said, I've created it with your option, but, I've got a problem. Now, I'm going to debug it, since in this moment I don't need to have it available for NetBSD, but, the question stays about the latter use. BTW, it's a very small overlapping (126 sectors) and I've just put my new partition at the beginning of the free space I had been presented, but, it seems that Linux partitioning programs are getting a bit confused with the NetBSD slice.

Yes, I've seen these installers do some bizarre things. The other week I put NetBSD back on my laptop, and IIRC I asked the installer to use the whole slice with one filesystem. So then it shows you the disklabel, and it has made a swap [OK], a root partition [OK] and about 3GB of the slice are left empty [*DOH*}. Something is broken.

Error: File system has an incompatible feature enabled.
Compatible features are has_journal, dir_index, filetype,
sparse_super and large_file. Use tune2fs or debugfs to
remove features.

And why do I need to run an operation (move) on it?

I'm not quite sure I'm following this. By "(move)" are you referring to "remove" in the error message? If so, I think it's asking you to remove one of the conflicting features ... or that is my best guess given the limited info.

Quote:

Because I've come to the point to do the first trial (not only a trial, it's also a step in my proceeding) with the NetBSD install shell. (I've already done two trials with re-arranging the existing partitions inside disklabel.) Good news - it works (I mean disklabel from the install shell). Bad news - it have found that my partitions (wd0h and its new neighbor) were overlapping. (Of course, it's also a good news, rather then bad, as it doesn't let you go on if your partitions are overlapping). What I've done? I've created two ext2 partitions next to the NetBSD's one, at its right side.

To clarify: are these in the 40GB of free space? Or somewhere else (you mentioned using another disk)?

Quote:

The first one (the one in the middle) is meant to serve just as a placeholder for the future NetBSD partition (unnecessary step, of course, but, I think it can make the proceeding more clear and I can prepare the disklabel - apart of wd0c - as well as /etc/fstab - apart of partition type). The second one happens to be wanted (it should be the "parking place" for VMware guest OS's I've got the idea a couple of posts above), but, I would have created a (temporary) partition in any case - to serve me as a marker, as a delimiter of the free space when I delete the first one to make room to enlarge the slice. So, since I plan to continue to use that partition the way I've said, I've created it with your option, but, I've got a problem. Now, I'm going to debug it, since in this moment I don't need to have it available for NetBSD, but, the question stays about the latter use. BTW, it's a very small overlapping (126 sectors) and I've just put my new partition at the beginning of the free space I had been presented, but, it seems that Linux partitioning programs are getting a bit confused with the NetBSD slice.

It wasn't (only) that, but, also "resize_inode". I don't have a clear idea where that second feature came from, since I've done nothing else, but to apply your exact command, but, maybe with that version of mke2fs it's being added by default. (I recall I've already had a similar problem some time before.) However, it's solved. I've run debugfs, removed both resize_inode and dir_index and, after being done with partitioning, added "^dir_index" where it was needed.

Quote:

Maybe some features are enabled by default and they don't mix? Do you have an /etc/mke2fs.conf ?