Mounting from ufs:/dev/ad2s1a failed with error 19.
freebsd at edvax.de
Sat May 2 04:49:18 UTC 2020
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.
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
More information about the freebsd-questions