I am using tunefs -L to label my partitions since I am doing testing on an external RAID which causes the device names of the boot drive to change from da0 to da1 or da2. This all works just fine except that the root partition cannot be labeled from single-user boot. It seems to fail silently. Fix: Boot from CD into fixit mode and run the above tunefs label command. This allows the system to boot properly. Ideally sysinstall would allow one to set the disk label during newfs time. How-To-Repeat: reboot into single user mode run "tunefs -L root /dev/da0s1a" (assuming that's your root partition) edit /etc/fstab to use /dev/ufs/root as the root partition device name reboot. On reboot the loader will not be able to mount the root partition by the /dev/ufs/root device label name. No errors are produced on the above tunefs, and in fact the "success" indicators of the label being created are given on stdout and the syslog. The tunefs command works just fine for any other partition from single user mode.
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped
System is 13-STABLE from August. The title should be updated to "tunefs(8): silent failure change settings on boot partition". Running 13-STABLE and was unable to set TRIM, SUJ, Label. Entered: tunefs -t enable /dev/nvd0p3 It responded with the standard message and no error. "tunefs -p" showed TRIM enabled. Then mounted the volume RW and checked again and TRIM was disabled. Same with SUJ and Label. SWAG, a copy of the superblock is located in memory and that is update by tunefs but is not written to disk since it had been mounted RO. When "mount -u /" is executed, the superblock is read in again. Just a guess, but seems to fit the behavior. Ticket my be updated to "Affects some people". This ticket has been open for over 14 years with no attention. With the increasing use of SSDs that may miss enabling TRIM on the initial installation requiring the use of tunefs to enable it. I know from experience.
Created attachment 252231 [details] licen
Are GPT labels usable for this case?
Wow! I had to spend some time remembering this. I think that this stems from confusion between the three types of labels that are related to disks and disk partitions. tunefs(8) sets the gpt label which is not the glabel. The GPT label is created when a partition is created by gpart(8). I have never had any issue using tunefs(8) -L option to modify it. The glabel is a GEOM tool and not related to GPT. While I am sure that there are other uses for glabel (set and modified by the glabel(8) command), I have only used it for labeling swap partitions. GPT labels are specified in the specification for GPT and is used by almost all disk configuration while glabel is part of the FreeBSD GEOM system and us only relevant to that system which, as far as I understand it, limited to BSD and not Linux, Windows, or any other system. I am not use if all BSDs use it. THe fact that GPT and GEOM both start with 'G' and are tied to disc structure has caused a lot of confusion, but I thought it had quieted down.
(In reply to rkoberman from comment #5) From my naive search 'tunefs -L' does not set a GPT label. tunefs.8 does not say that and if I look into the source code I see fs->fs_volname populated: $ grep -r fs_volname . ./sbin/dumpfs/dumpfs.c: afs.fs_volname, (uintmax_t)afs.fs_swuid, ./sbin/dumpfs/dumpfs.c: if (fs->fs_volname[0] != '\0') ./sbin/dumpfs/dumpfs.c: printf("-L %s ", fs->fs_volname); ./sbin/growfs/debug.c: sb->fs_volname); ./sbin/newfs/mkfs.c: strlcpy(sblock.fs_volname, volumelabel, MAXVOLLEN); ./sbin/tunefs/tunefs.c: strncpy(sblock.fs_volname, Lvalue, MAXVOLLEN); ./sbin/tunefs/tunefs.c: sblock.fs_volname); ./share/man/man5/fs.5: u_char fs_volname[MAXVOLLEN]; /* volume name */ ./sys/geom/label/g_label_ufs.c: if (fs->fs_volname[0] != '\0') ./sys/geom/label/g_label_ufs.c: strlcpy(label, fs->fs_volname, size); ./sys/ufs/ffs/fs.h: * The volume name for this filesystem is maintained in fs_volname. ./sys/ufs/ffs/fs.h: uint8_t fs_volname[MAXVOLLEN]; /* volume name */ ./tools/tools/find-sb/mini_ufs.h: u_char fs_volname[MAXVOLLEN]; /* volume name */ ./usr.sbin/fstyp/ufs.c: strlcpy(label, fs->fs_volname, labelsize); ./usr.sbin/makefs/ffs/mkfs.c: strlcpy((char *)sblock.fs_volname, ffs_opts->label, ./usr.sbin/makefs/ffs/mkfs.c: sizeof(sblock.fs_volname)); I would wonder how the FS on top of GPT knows that it sits on top of GPT.