NetBSD-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Keeping NetBSD disklabel up to date
mlelstv%serpens.de@localhost (Michael van Elst) wrote:
> beaker%sdf.org@localhost (beaker) writes:
>
> >Is it safe and sufficient to run 'mbrlabel -fw <device>' on NetBSD
> >whenever there has been partition resizing (usually via Gpartd)
> >such that the disklabel no longer reflects the current partitioning
> >state?
>
> mbrlabel creates disklabel entries for MBR partition entries, nothing
> generic. It also won't move any data.
>
>
> >System in question is an old 32bit i386 with an MBR partition scheme
> >on a SATA disc hosting several Linux partitions and one NetBSD FFS2
> >partition. Bootloader is GAG, not GRUB nor native NetBSD bootloader.
>
> If you only change the Linux partitions, you can use mbrlabel
> (without -w) to print the necessary disklabel entries. mbrlabel
> doesn't know how to delete or modify existing entries, so you need
> to do that and use the mbrlabel output as a template.
>
> If you want to modify or even resize the NetBSD partitions, it gets
> much more complicated. A save approach is to boot from an alternate
> installation (Live- or Installation-CD), backup the partitions,
> modify them accordingly and restore the partition content from
> the backup. You may also have to reinstall the bootloader.
Thanks for the reply. Basically this question arrises from a recent
experience in which I was attempting to reformat an existing partition
to EXT2 for use as a "Commons" since neither the NetBSD nor Linux OSes
can mount eachother (one is BTRFS, the other UFS2; RW for UFS2 on
Linux is supposedly supported but I couldn't get it to work).
Anyway, a Linux formatted EXT2 "Commons" was unmountable by NetBSD so
I too-haistily tried the same from NetBSD and corrupted the nearby BTRFS
partition in the process, apparently due to the disklabel not accurately
reflecting the current partitioning "map". Well, that's why backups
get made..
So it sounds like mbrlabel by itself would not have been sufficient for
avoiding this scenario; it's output still needs to be applied via the
disklabel tool; is that correct? I'm sort of surprised as the mbrlabel(8)
manpage says
"mbrlabel is used to update a NetBSD disk label from the Master Boot
Record (MBR) label and Extended Boot Record (EBR) label(s) found on
disks that were previously used on DOS/Windows systems (or other MBR
using sys tems)."
Perhaps it's grammatically correct but not literally correct -- it is
used to update the disklabel but doesn't actually do it itself?
Regarding the GPT scheme as a possibility I'll have to get educated
on that but perhaps it's the better way to go since I'm goning to
have to start over with this disc anyway. I had it in my head that
GPT was a 64bit only option.
Home |
Main Index |
Thread Index |
Old Index