From owner-freebsd-questions@freebsd.org Sat Sep 7 12:47:29 2019 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 10155D1998 for ; Sat, 7 Sep 2019 12:47:29 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46QZ2R63mDz4XbP for ; Sat, 7 Sep 2019 12:47:27 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r56.edvax.de ([188.103.162.60]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.183]) with ESMTPA (Nemesis) id 1Mk178-1iZ13f10ye-00kN1n; Sat, 07 Sep 2019 14:47:03 +0200 Date: Sat, 7 Sep 2019 14:46:59 +0200 From: Polytropon To: "@lbutlr" Cc: Aleksandr via freebsd-questions Subject: Re: Convert MBR Partitions to GPT Message-Id: <20190907144659.33354f88.freebsd@edvax.de> In-Reply-To: <668AE706-2B7D-40F9-B88A-208797D419BB@kreme.com> References: <1ef6d7eb-a7c9-2a5d-12b2-20c4ef255523@wavecable.com> <20190902133941.e563291f.freebsd@edvax.de> <0e0c086c-a907-d224-98b8-9486d921e7a5@wavecable.com> <20190902141116.264edd01.freebsd@edvax.de> <88cabc53-eff5-3e1a-6e77-2d86da2b8c8d@wavecable.com> <20190902164836.98486301.freebsd@edvax.de> <20190906132003.a0e2c6a0.freebsd@edvax.de> <20190906234411.9aba1e00.freebsd@edvax.de> <668AE706-2B7D-40F9-B88A-208797D419BB@kreme.com> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:WIoG8HZVLLKT/90yVANlgkCZmQPRqYXy0jfCZ1oN24OJOCCqyuZ HecQvcfnN0OMwdNoJwthJY7y7Ou9x1HYHxiOzFtnYgAGrbUpOvqqS0qiIj2MeKJCSWfOml7 EN8SSaryqRDCZvPL6nQ29Si1HOo+wRoJycPt2wd/2dEnAnAiKJQ40IaReg66Q/2MFcoXU7h 0IqS/AsaomZw/lsJEyqVg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:qfGRfm5DBHo=:OjraUvNWqu/xcn2I3tVZlV vtx4YRfai0NNheMrDZcFRBIGmsz0owENy7GCeyllOuxF9gLH5ET+V5TMIpTsO59v0aifJRgnD R+GcUNtWhsehyhVKJ2HSf5xI8/kyHNNS4Ul8sdnggQDYqElG4bDeYO/b4MCSHPcwSbraHh0nF 0gONArQPOSuPsFiiZSvCiRhap0iZb+x4pYsC40NXtH2zE/4VubNyRGBakcSW0fjC764ppMPF5 UIgh5S6QcbtEfeoZ3xst+LUjnAJuIOtAv4jhf74gOmYXuZfTVanwfY26FgWYqRse9Rxr3gyQK cKfdx6GaZEhCmMArk9PpxFvN48wtu5/Fn6jFSSoG1u+XMxvywb/7FuENwkwYJfmqP6X12xdxE Cq6V63yXfdGySfQeyrY05HkQrtaslenVi2HyHwPKkN3E69AEAvPg/M6OFuJ5h0fl9MV00kGM1 XbBZ9FKP9svW/T6d/GcOt30QR7C0CLmrqM5sQD3fWYLEFeZXUVFwKX5OxPmMnTcA0Nzj/CkF/ 65uHLohcjewjR7z1C5nXgj2/5SpSvk1Vbq4TJ13W/44KEhBWwW72fI5a1G1qsHybxdjVJty/i HMlrK25umWg2R1m233e8tOemEGVvTKQuL3MBMKtA3pr9Qn+dHBuKxWxPt8WjVcd6yA/YT3jnu WObt3/v+ZhBebYYQTExTC/5EhVqcCJ/sKE6CIXR0/rT/u3fy8s7wozDK41D9bZhZvt1fyubBG wO9pucc4oXIFLHOMdOQ5gyf6RAswTyp9VXAfB9B0/CFmVSVc6PYK+EqegXJ0jclSwHiMKdOYr zo2d3YhxOl4aP0CpeSlC0b6mUlbCsElHNWgmcq+57/wqvlRaMs= X-Rspamd-Queue-Id: 46QZ2R63mDz4XbP X-Spamd-Bar: +++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@edvax.de has no SPF policy when checking 217.72.192.75) smtp.mailfrom=freebsd@edvax.de X-Spamd-Result: default: False [5.49 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[freebsd@edvax.de]; MV_CASE(0.50)[]; HAS_ORG_HEADER(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:8560, ipnet:217.72.192.0/20, country:DE]; MIME_TRACE(0.00)[0:+]; RECEIVED_SPAMHAUS_PBL(0.00)[60.162.103.188.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.81)[0.814,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[edvax.de]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.74)[0.739,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.99)[0.991,0]; MID_CONTAINS_FROM(1.00)[]; RCVD_IN_DNSWL_NONE(0.00)[75.192.72.217.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(0.54)[ip: (0.34), ipnet: 217.72.192.0/20(0.22), asn: 8560(2.17), country: DE(-0.01)] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2019 12:47:29 -0000 On Fri, 6 Sep 2019 16:28:36 -0600, @lbutlr wrote: > On 6 Sep 2019, at 15:44, Polytropon wrote: > > On Fri, 6 Sep 2019 12:25:21 -0600, @lbutlr wrote: > >> On 6 Sep 2019, at 05:20, Polytropon 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. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...