Convert MBR Partitions to GPT
freebsd at edvax.de
Sat Sep 7 12:47:29 UTC 2019
On Fri, 6 Sep 2019 16:28:36 -0600, @lbutlr wrote:
> On 6 Sep 2019, at 15:44, Polytropon <freebsd at edvax.de> wrote:
> > On Fri, 6 Sep 2019 12:25:21 -0600, @lbutlr wrote:
> >> On 6 Sep 2019, at 05:20, Polytropon <freebsd at edvax.de> wrote:
> >>> Now, journaling tends to cause problems when using dump to backup
> >>> data partition-wise (e. g., "dump -0Lauf /mnt/rootfs.dmp /dev/ada0p2”).
> >> I’m not sure that is a problem with journaling as opposed to a problem
> >> with dump.
> > I'm not primarily complaining about the problems between journaling
> > and dump, I'm complaining because the _choice_ is gone (or at least
> > choice now requires additional booting and fiddling with what has been
> > possible with ye olde sysinstall for decades).
> The defaults are always going to annoy some people. I’d say using dump
> for backup seems like it’s pretty much and edge case these days.
I wouldn't say that. Over the years, I've encountered many settings
where there's more than only one partition per disk, and several
disks in a system, and backing up data partition-wise is very
convenient. As opposed to tools like cp, rsync, or tar, a dump
has the advantage that _all_ information (especially "meta-information"
such as flags, extended attributes, symlinks and hardlinks) can
be saved and restored (!) exactly 1:1, as it should be. Sure, this
approach has advantages and disadvantages, but omitting the _choice_
is, in my oinion, the wrong thing to do for the installer. I fully
agree with you that SU+J is fine for many settings, especially for
"one disk, one partition" single-user systems. Still the installer
could offer a means to change that setting, while presenting SU+J
as the default. It's not that hard, even ye olde sysinstall did it
in a way that I would call "the correct way". :-(
> >> Pick one fo the following:
> >> 1. Journaling and rsync/tar/etc
> >> 2. ZFS Journaling/snapshots and dump to your heart's content
> >> 3. Use an older disk format
> > This is not always possible. Imagine a setting where you need to
> > introduce a new UFS-based system to a conglomerate where dumps are
> > obtained automatically at runtime. None (!) of the things listed
> > above is a solution.
> Why does it have to be UFS and why can’t you manually format the disk
> if you really care that much?
This is exactly what I want to avoid when I use an installer tool
such as bsdinstall. Sure, I now (!) tend to not use bsdinstall, and
drop to the CLI in the first step, so I can do the initialization of
the filesystems as needed. But that fully defeats the purpose of having
the installer. Remember sysinstall? You could change (!) the settings
for the automated tasks before they took place, and you would even
_know_ what settings would be applied _before_ the steps started.
Now, the way the filesystems will be initialized is obscure - you can
only see it afterwards.
With sysinstall, you could also combine automated and manual things.
I have not tried this yet with bsdinstall, but maybe this is a way
to deal with it: Partition and init via CLI, then return to the installer,
which then actually installs FreeBSD to the prepared partitions?
Still a bit inconvenient, but it would work for the cases where
journaling is not desired.
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
More information about the freebsd-questions