From owner-freebsd-questions@freebsd.org Wed Nov 27 16:11:04 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 43F741B06D8 for ; Wed, 27 Nov 2019 16:11:04 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (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 47NQjy5gwnz4FGy for ; Wed, 27 Nov 2019 16:11:02 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r56.edvax.de ([188.102.99.44]) by mrelayeu.kundenserver.de (mreue107 [212.227.15.183]) with ESMTPA (Nemesis) id 1M2fM1-1iWRGL3mcp-004DXc; Wed, 27 Nov 2019 17:10:55 +0100 Date: Wed, 27 Nov 2019 17:10:53 +0100 From: Polytropon To: tech-lists Cc: freebsd-questions@freebsd.org Subject: Re: 12.1-STABLE r354923 snapshot install doesn't like manual ufs setup Message-Id: <20191127171053.0b2f38b8.freebsd@edvax.de> In-Reply-To: <20191127155224.GC75104@bastion.zyxst.net> References: <20191127033739.GB75104@bastion.zyxst.net> <20191127131609.e69ab03c.freebsd@edvax.de> <20191127155224.GC75104@bastion.zyxst.net> 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=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:PvgWxzSAP9aeHeIU2NeTU4Vadx6Yr0spCameCzo3+JCv0hKxyG6 7lrZGOCxoELYxgOYs9gYjVfe+LpDa6/tLXXHPtKzyrcPws8uc4sL8IW3xttFkgDjl1M9Wur lrTAzW1/J0yRph5frMwwT5FvyagL2KDvE2BNr/BM5SysYSin8+FINQsFybkk7KYkolAf4bR STq7YSkrSco+fDlOSbsoA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:Mh+Q+FWIbNU=:3UNsI24T/WuY/cIGy+gtMw 2tYGbxCbrETfvCM8atnoj2Pz+kGx2iwwA0fRiCE3WZFh3ic5WSlDL2EAtyqdUfOnXtHa5kwTA HSJlOufCElxPRHVcQpUu1NlAo9dCng/WHRgqZucIhPuBM9QctlmTAfyQFZGSZdvKc9vCYJWc4 Gw3ZT1C1b4Xf+ZfMx7kL8pKTADF+w3pQMZqi06uyBgDpL5rIsNZmXeqbqmB7tStSCGov5WAku epH8GJWSE2SKtrYTfoMyed0tGfO87aAr5dIq8IinF2Dncx4cr82wp4A15+KPhFaKcCqiJ4ALo rXTkXagq0MU33AJSV2SDDO3JTLdxEVh0vEMk6ZXZOD3iLguRwO4QLEMZrKm+R12GRNanLibdD WDdtYY/Aev9PgjSxxHzhFKXssiO+RW2uePbNeS+Z8BFVTQ6161o35nUc1YG5EmuGMFumMKll9 m/+dT40j883ekgQVMHzmv3wxL0/50vr2zMvV+Q/Z6WB3WNELbG8/vid+1UwooFrUyLZyr5cI1 k2XTMr5CnJaS3fIDguKNrugelEvZZp9C0GSN+oW+XtyaXmllC/DyoXH2kbdiJobMqgVFnakKG C9yhNIhbDqfXBU+pDzsX7d87GJ+Q87rFVfvAUs6umRlpjRE/PgICggyu9OZ7Ybw/HOqxJG2UW ptaP2o1CEpTTZmKHM2ioxZonYgURo4w1Br6Ss0YEprsXMRgbFZ8F8lZHeKTsfXsWr9KEUoWbU w3RVgSECuKFguxBk1HJqSzpPrzPoBUi03+4wCGBr45xlzcDzFFuRK+qjeGm7CZNLRIZvkeJNG llyEHcoaF+20bW87jmoJVKk+AxVR9mQP3rvWaH34VohkIsPrBWVOX7tEVyz4rPxC+Q/uz1EiV L0QKuAr4so7AG9wyzERg== X-Rspamd-Queue-Id: 47NQjy5gwnz4FGy 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 212.227.17.13) smtp.mailfrom=freebsd@edvax.de X-Spamd-Result: default: False [4.28 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[freebsd@edvax.de]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; HAS_ORG_HEADER(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:212.227.0.0/16, country:DE]; MIME_TRACE(0.00)[0:+]; RECEIVED_SPAMHAUS_PBL(0.00)[44.99.102.188.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[edvax.de]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.83)[0.832,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.96)[0.960,0]; MID_CONTAINS_FROM(1.00)[]; RCVD_IN_DNSWL_NONE(0.00)[13.17.227.212.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(0.08)[ip: (-0.63), ipnet: 212.227.0.0/16(-1.23), asn: 8560(2.29), 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: Wed, 27 Nov 2019 16:11:04 -0000 On Wed, 27 Nov 2019 15:52:24 +0000, tech-lists wrote: > Hi, > > On Wed, Nov 27, 2019 at 01:15:42PM +0100, Polytropon wrote: > >On Wed, 27 Nov 2019 03:37:39 +0000, tech-lists wrote: > >> Hi, > >> > >> Got a new ssd so tried latest snapshot install to it. I wanted seperate /usr > >> /var and / partitions, also to enable trim, also two 16GB swap partitions, > >> so selected manual UFS, completed the install, reboot, cannot find kernel. > > > >Did you do this using the bsdinstall program, or manually > >via shell? > > I don't know specifically if it was the bsdinstall program. I guess it was. It > was whatever is invoked after booting the install disk/image and then > selecting "Install". Yes, that all is "bsdinstall", the successor of "sysinstall" (the dialog-driven installer program of older FreeBSD versions). > >> Repeated the install the same way again with same result. Rebooted, ran > >> the installer for a third time, selected auto ufs and everything worked > >> as expected on reboot, but of course without the modifications I wanted. > >> > >> Is this a known issue? > > > >Even though bsdinstall isn't that bad, I personally prefer > >to prepare the disk via shell commands manually before I > >return to bsdinstall, add the created partitions, and have > >the installer do it's work, in case I needed something that > >is "non-standard" (as you've described). This is because of > >my impression (I wouldn't call it an issue though) that the > >bsdinstall program doesn't understand when you leave its > >predefined path... ;-) > > I'd say if it's not working as suggested or implied then it's broken, or why > have the manual option at all? The manual option is something you need to use if you want to do non-standard (but possible) things that the installer does not include. For example, a dedicated installation (the one without either MBR or GPT) requires you to prepare the disk using shell commands, and then return to the installer to write the files to those filesystems. So its presence is not a sign of brokenness, but a convenient means to do more than the installer allows you to do. There is no one-size-fits-all egg-laying wool-milk-sow. :-) > I don't expect the consequence of selecting > this option to be "doesn't install a kernel" or "everything is installed, it's > just not bootable" without notification. Fully agree. The default installation should work, and little deviations from that predefined procedure should work as well. Personally, I consider the "separate partitions approach" as a little deviation, not as something totally non-standard or obscure. However, my very individual impression is that bsdinstall works well for the standard paths of doing things, but does not so for anything more... "non-preprogrammed". In the past, as I have to admit, I preferred the dialog-driven setup method for disks of ye olde sysinstall - the slice editor and the partition editor. Now I mostly use the shell to prepare the disk (in "non-standard ways", if I may use this term now for anything that bsdinstall doesn't directly map to), and then return to the installer, make certain settings as needed, and continue with the actual installation. Getting the "boot chain" working for such "non-standard ways" seems to be a bit tricky for bsdinstall, so I'll do that myself. > I've not encountered the issue before because my installation context is > mostly bhyve-based so I just accept the defaults. Because this is bare metal, > I was hoping to optimise the SSD somewhat. Yes, there are several things you can do to optimize for SSD use. Part of it is custom newfs options, but if I remember correctly, bsdinstall doesn't allow you to add those - you'll need to use the shell to run newfs with the desired options manually, at least that's what I tend to do. :-) > >> Also, MBR is selected by default. SHould I be using GPT instead, nowadays? > > >Probably yes. Use GPT. Use MBR only if you have a good reason > >to do so (inter-OS things might be such a case). > > There should be a reason why this is selected as default. "Most x86 systems" > isn't enough. I'd fix this if I knew how. What is the GPT advantage? GPT can rightfully be understood as the successor of MBR. While MBR is considered legacy, and mostly only matters in cases where either your computer system (here: the BIOS) has problems dealing with GPT, or you have a multi-OS setup where involved systems do have those problems, only in such cases you'll have to use MBR. MBR brings you certain disadvantages and limitations that _might_ not matter in those special cases, but GPT is typically a lot easier to deal with. MBR has been introduced primarily because of PCs and their understanding of "DOS primary partitions", which GPT finally abandoned for a more consistent way of creating and managing partitions of disks. Conclusion: Rule: Use GPT. Sidenote: Use "dedicated" if you know what you're doing, and why. :-) Old standard: MBR New standard: GPT Non-standard: dedicated (also known as "very old standard"). You can find a good comparison of the different structure here: http://www.wonkity.com/~wblock/docs/html/disksetup.html The tools you use from the shell are usually gpart and newfs (for GPT and MBR), but in case of MBR only, you can even use the old tools fdisk, disklabel (bsdlabel), boot0cfg, and newfs, they still work as expected. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...