12.1-STABLE r354923 snapshot install doesn't like manual ufs setup

[Polytropon]

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, ...