Mounting from ufs:/dev/ad2s1a failed with error 19.

[Polytropon]

On Fri, 1 May 2020 11:51:00 -0700, David Christensen wrote:
> On 2020-04-30 23:55, Polytropon wrote:
> > On Thu, 30 Apr 2020 22:42:47 -0700, David Christensen wrote:
> >> On 2020-04-30 20:11, Polytropon wrote:
> >>> On Thu, 30 Apr 2020 20:29:14 +0200, Christoph Kukulies wrote:
> >>>> Could solve it myself: bootet back to usb drive, mounted
> >>>> /dev/ada0s1 /mnt and edited /mnt/etc/fstab to the correct
> >>>> mount device.
> >>>> There were ada2s1 for / and another ada2 device for swap.
> >>>> Changed that to ada0s1 and now the system boots fine.
> >>>
> >>> If you can, use labels to avoid those kinds of problem. :-)
> >>>
> >>> https://www.freebsd.org/doc/handbook/geom-glabel.html
> >>
> >> Is there a FreeBSD labeling solution, or any other identifier solution
> >> that avoids using device nodes, for the combination BIOS, MBR, GELI, and
> >> ZFS?
> > 
> > For this constellation, probably glabel is the convenient
> > tool: "glabel label <name> <device>", and then in the "zpool
> > create" command use gpt/<name> indead of the device name.
> > 
> > I have no idea of why MBR should be involved here (as you
> > want to use ZFS)...
> > 
> > Documentation:
> > 
> > 	https://www.freebsd.org/doc/handbook/zfs-quickstart.html
> > 
> > As the example shows, there is no MBR-related step involved.
> > ZFS can manage devices just fine by itself. However, today's
> > suggestion is to always use gpart (with -t freebsd-zfs for
> > use with ZFS), so that's probably the best way to go.
> > 
> > Here is some specific inspiration that also includes the
> > use of GELI:
> > 
> > 	https://blog.haraschak.com/from-dev-to-label/
> > 
> > So if I understand this correctly, the suggested approach
> > is to use -l <label> in the "gpart add -t freebbsd-zfs"
> > step for each disk, and then using those labels as mentioned
> > above. The GELI partitions should then bear that name
> > <label>.eli instead of the device name <device>.eli.
> > 
> > 
> > 
> >> And, that works if I use dd(1) to copy the raw system disk
> >> contents from one device to another -- ATA drive, USB drive, SD card, etc.?
> > 
> > That probably depends on the source and target size, as if I
> > remember correctly, labels are stored at the "logical end"
> > of the device (last sector or block). However, labels are not
> > supposed to be "cloned" that way. A typical solution is to
> > prepare the target media using the appropriate tools (like
> > gpart, maybe newfs), and then transfering the data. For ZFS,
> > always use ZFS's native tools for that; for UFS, dump and
> > restore are very convenient (and can deal with the case of
> > non-matching sizes).
> 
> Thanks for the reply.
> 
> 
> I have a mix of computers of varying ages.  Some are BIOS, some are 
> early EFI/UEFI, some are recent UEFI.  All have firmware quirks.
> 
> 
> I like being able to move my system images (binary data) from one device 
> to another device and/or to move my system drives (devices) from one 
> computer to another computer, and have everything "just work".
> 
> 
> The combination of BIOS and MBR gives me the best results for the above 
> constraints and goals.

I fully agree. Today's consensus is "use GPT except you have
a good reason not to", and intending to be able to use systems
that don't (fully) support GPT can be such a valid case.

Adding labels here is very convenient. I have the same "problem"
that systems detect devices in a different order, so what has
been ada0 in computer A will suddenly be ada4 in computer B.



> When building a FreeBSD system disk, I use the FreeBSD installer and 
> select "Partitioning" of  "Auto (ZFS)".  For example, here is my SOHO 
> server.  The system drive (ada0) is an Intel SSD 520 Series 60 GB with a 
> 14g FreeBSD slice (ada0s1) containing a 2g ZFS boot partition (ada0s1a), 
> a 2g GELI swap partition (ada0s1b), and a 10g GELI ZFS root partition 
> (ada0s1d) (the 42g slice ada0s2 is a GELI/ ZFS cache for the data drives):
> 
> 2020-05-01 10:57:34 toor at f3 ~
> # gpart show -p ada0 ada0s1
> =>       63  117231345    ada0  MBR  (56G)
>           63       1985          - free -  (993K)
>         2048   29360128  ada0s1  freebsd  [active]  (14G)
>     29362176   87869232  ada0s2  freebsd  (42G)
> 
> =>       0  29360128   ada0s1  BSD  (14G)
>           0   4194304  ada0s1a  freebsd-zfs  (2.0G)
>     4194304   4194304  ada0s1b  freebsd-swap  (2.0G)
>     8388608  20971520  ada0s1d  freebsd-zfs  (10G)
> 
> 
> Looking at the last sectors of the first slice and the three partitions, 
> they all contain data.  So, if I use glabel(8) to label them, things 
> will break.

That is an interesting question. Using glabel should not interfere
with existing data, and should definitely not damage data that is
already part of a filesystem.



> It sounds like I need to hack the FreeBSD installer to leave room at the 
> end of the FreeBSD slice, to leave room at the end of each partition 
> (does glabel work for swap?), to invoke glabel(8) with the right 
> arguments to create labels, and to adjust all the other commands ('zpool 
> create ...' , swap?) to use the labels while building the system image (?).

Yes, you can label a swap partition. All commands should be able
to accept labels instead of device names, as long as you make sure
that each label uniquely refers to an existing device file.



-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...