From nobody Fri Apr 14 06:41:39 2023 X-Original-To: questions@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PyRgX3mWXz44b1M for ; Fri, 14 Apr 2023 06:41:44 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.134]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.kundenserver.de", Issuer "Telekom Security ServerID OV Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PyRgX0Pbyz3k64 for ; Fri, 14 Apr 2023 06:41:43 +0000 (UTC) (envelope-from freebsd@edvax.de) Authentication-Results: mx1.freebsd.org; none Received: from r56.edvax.de ([178.5.233.107]) by mrelayeu.kundenserver.de (mreue010 [212.227.15.167]) with ESMTPA (Nemesis) id 1MRTAj-1q1h4q080r-00NUNV; Fri, 14 Apr 2023 08:41:41 +0200 Date: Fri, 14 Apr 2023 08:41:39 +0200 From: Polytropon To: "Dan Mahoney (Ports)" Cc: "questions@freebsd.org" Subject: Re: filesystem labels? Message-Id: <20230414084139.8b2d91dc.freebsd@edvax.de> In-Reply-To: <82C015E0-71B9-4189-AA84-71219CA14E73@gushi.org> References: <20230413111708.62d8c8d3.freebsd@edvax.de> <82C015E0-71B9-4189-AA84-71219CA14E73@gushi.org> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:eCINAzlxvM7/rGPAV6XZRlP8bdMZIOl5eg+7PiYWPJbkE4NiLB4 PXrXeRo4R5GtMl679S9nNc23UOt3t3omThH7gjXXc4jnOIH5IZe8svENbfTRcPh4j/wCJIY LtQWVL6ReHj0n1QB6ThTQeKKKjhpqBDl7BerquLlIgfmdBxGsK01exyeq9KqkqhvkKlxsCq 9mGHZqR/dq/Je076xMjFw== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:cuGpgCWJRl0=;n5C63GKTDn+BjQgllE2a8GL/9G4 oI7PQ/1JMI/sNhTsP5SGp1hz42XajEVUNpN076LMPIRtrji7d7c5mh2GpNl93YHNwAEYFRhhG ad6zHJDUgy3DFz/xTQ6wvh8CXkbKWUqJGFAl/IP5YKtmvczklO6y1vCMNwfw0x3DM3yD2IdkU RSObXGLqybB+DbIfwXQ0OvOxGaoaTbzPSeLUxlYrK0VAO6KDQLifKmzi7NqxzRTom8iYPMa6u Y/FWuF7L1HTCP4PwXU5qdQBttcAvKDyixb5YxZIz31FEQb1d5CMrWwFez+2mDPBSzgX6PQx4u 28+EXZtrx/l8s05SX4wtUk2nC72HdUug+6Ni42AUPi9tmOBuCJf6By0U9aePyQTQ/z/hAHnb6 /GjF8VzWhIMxCOyWbqdQmk4bHVShMvffldxluUj3YZrjkZOBVOhcAfJgL6++SqwQYhzaflo1z jCm8onkt4z4ErcxKR/RAnLnr2VXSkkB5CV1rnEOf5nen+5d7XdjuN4xOdAAD75aNTZCW0wEna MyHjlRYRL9JylpBU99pC4WAYbKnaNf97C/ZNOB7ZJaUcMFWI7EiHf3boBU6rShDQpat9sXXeT lBQd8OTIH/1UvAedMnuucU1V4R6+rSnbpAh7rRluUzfNlUAy95FwlrDzdgxDrDoDx8b9vAtkw 0y5qnnd70qQxnQEZVVrVVaE7Z4cdz3HXKUdoXGgALQ== X-Rspamd-Queue-Id: 4PyRgX0Pbyz3k64 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Thu, 13 Apr 2023 21:42:27 -0700, Dan Mahoney (Ports) wrote: > > > > On Apr 13, 2023, at 2:17 AM, Polytropon wrote: > > > > On Wed, 12 Apr 2023 08:58:22 -0700, Dan Mahoney (Ports) wrote: > >> I find that the handbook mentions glabel labels, but several > >> other places say don’t use them. > > > > For example? > > > > THis is a honest question, because in my experience glabels > > are a common solution for disk labelling. > > Warren Block (see the wonkitty link below? Same person.) said > in this old post to avoid it if you can: > > https://forums.freebsd.org/threads/odd-dax-device-mapping-in-freebsd-9-1-rc1.34676/ > > It’s also specific not only to an OS type, but also a fliesystem > type, whereas if you’re using GPT disks. Sorry, yes, stupid before input. ;-) GPT labels (!) are today's typical solution, because they are "already included" with GPT partitioning, and that partitioning scheme is the one to use today, especially in combination with EFI. Using MBR partitioning or no partitioning at all should only be done if you have a good reason _not_ to use GPT. As I mentioned, all other labelling mechanisms (glabel, disklabel, UFS label, UFSID) are of course supported, so if you want to use them, it will surely work. The tool glabel can be seen as being part of the suite of glabel, gmirror, gstripe, gconcat, gvinum, gjournal and "the other GEOM stuff". > Right now, the problem I’ve found is that even though I just > added a new device, and labeled it, it doesn’t show up in > /dev/gpt/anything — and even /dev/gpt doesn’t exist, despite > having previous GPT disks in the system, at boot. The new > drive doesn’t show in /dev/gpt even after a reboot. As /dev is dynamically generated, it will appear as soon as the disk logical drivers require it. The support has to be in the kernel, but it's the default anyway. Sometimes it seems to be required to "taste" a drive: # true > /dev/da1 This looks dangerous, but is supposed to be the correct way, especially when using USB memory sticks or SD cards. This causes the system to generate all neccessary files in /dev. > There are mentions of a number of sysctls that one *can* set, > but not a great list of what they do. > > root@collect-us:/home/dmahoney # sysctl -a | grep geom.label > kern.features.geom_label: 1 > kern.geom.label.disk_ident.enable: 0 > kern.geom.label.gptid.enable: 1 > kern.geom.label.gpt.enable: 1 > kern.geom.label.ufs.enable: 1 > kern.geom.label.ufsid.enable: 1 > kern.geom.label.reiserfs.enable: 1 > kern.geom.label.ntfs.enable: 1 > kern.geom.label.msdosfs.enable: 1 > kern.geom.label.iso9660.enable: 1 > kern.geom.label.flashmap.enable: 1 > kern.geom.label.ext2fs.enable: 1 > kern.geom.label.debug: 0 > > What manpage would document any of the above? You can read a short description using # sysctl -d kern.geom.label Also see "man 8 glabel". A full (?) list of label-related tunables can be found here: https://gist.githubusercontent.com/visualblind/8856820034ecaa2b4aa8b1600baa90ed/raw/846edd44a57576b3355aae543fed882d30b84949/sysctl-tunables I don't know where to find that information on an installed system though... > >> Or should I just keep on using /dev/daX in fstab? > > > > Nothing wrong with that in a static environment, i. e., > > one where you can safely predict which devices wiill be > > detected in which order to conclude what their device > > filenames will be. Otherwise, go with GPT labels. > > In this particular setup, I had a virtual machine with three > disks, one of which was slated to be removed. VMWare presents > things to the SCSI bus, in the order they’re added ot the system: > > Virtual Disk 1: /dev/da0 > Virtual Disk 2:/dev/da1 > Virtual Disk 3:/dev/da2 Yes, that is the correct way and to be expected. > What happens when I shut down, remove that second device, > and reboot? Disk 3 gets renumberd to disk 2, and gets seen > as da1. > > That’s my use case. Using /dev/daX in here is always suceptible > to that problem. Correct, and that is where labels are the best solution. As you probably have partitioned your virtual disk devices with GPT (because, why would you use MBR?), use GPT labels, which will be listed in /dev/gpt. Use those in /etc/fstab instead of the logical device names, so for example instead of /dev/ada0p2, use /dev/gpt/sysroot; /dev/ada0p2 becomes /dev/gpt/swapspace (or whatever name you assigned). NB: Dealing with gpart partition creation and destruction sometimes requires you to set # sysctl kern.geom.debugflags=16 in order to override some security mechanisms which could interfere with what you're intending. But don't ask me where this has been properly documented... ;-) > But…when the device entries don’t show up, either immediately, > and on reboot, and the manpages don’t tell me how to rescan > the thing, then I turn to -questions :) At least after a system reboot the labels should be visible to the system (or after "re-tasting", see above). Verify that you have successfully (!) written the labels by using # gpart list and check the partition(s) for "label:" entries. Each provider should have received one. For example: # gpart list | grep -e "Name" -e "label" 1. Name: ada0p1 label: biosboot 2. Name: ada0p2 label: sysroot 3. Name: ada0p3 label: swapspace This all of course depends on how you've created your partitions. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...