The rationale for GEOM_LABEL's existence is to make it possible to reference devices without referencing their physical device nodes. It's an abstraction layer which solves the issue of moving and renumbering devices, at least as far as the UFS file system is concerned.
For example, my fstab on one system looks like:
# Device Mountpoint FStype Options Dump Pass#
/dev/label/swap none swap sw 0 0
/dev/ufsid/49d629fac5da1db9 / ufs rw 1 1
/dev/ufsid/49d629fd255e43d4 /services ufs rw 2 2
/dev/ufsid/49ec5dbb90e1327c /data ufs rw 2 2
/dev/acd0 /cdrom cd9660 ro,noauto 0 0
In effect, this allows the fstab to work even if the devices are renumbered, moved to different controllers, etc. In fact, the last file system (/data) is on a software RAID (gmirror) device. Though in that case I could reference it as /dev/mirror/data, this is an alternative that "fits in" with the rest of the file systems.
One way to convert the system to use UFS ID labels is to look for kernel announcements of these labels and adjust fstab accordingly. Becuase the labels are getting used, this also bypasses the (harmless) "Removing label..." messages.
As far as the overly verbose GEOM_LABEL messages are concerned, they will probably be supressed in some way in the future, to reduce annoyance among users.
Why use UFS IDs instead of UFS labels? No special reason, expect UFS IDs are always present and labels are only present if the person invoking "newfs" remembered to specify them via the "-L" argument. Sysinstall currently doesn't create labels by default.
#1 Re: GEOM_LABEL ufsid
Hi! Ivan.
Is this something similar (and excuse me for the comparision) to /dev/disk/by-id of Linux kernel? (device identification by hardware id)
Have a nice day ;-)
TooManySecret
#2 Re: GEOM_LABEL ufsid
Up to the point that disk/by-id references individual drives while ufsid labels reference file systems, yes, they are similar.
There was also a plan to do disk ID labels, but lack of manpower postponed it.
#3 Re: GEOM_LABEL ufsid
Thanks a lot for your commit :)
#4 Re: GEOM_LABEL ufsid
This is really nice, but can it be used with GELI as well?
I've got /dev/ad4s3b.eli (swap) and /dev/ad4s3g.eli (/home) and those devices doesn't show in /dev/ufsid/
#5 Re: GEOM_LABEL ufsid
It should - that's an excellent use case for it. Do you have anything at all in /dev/ufsid?
#6 Re: GEOM_LABEL ufsid
Yes, the other partitions (/, /var, /usr/, tmp) that doesn't use GELI shows up in /dev/ufsid as it should, and I can add those to /etc/fstab.
#7 Re: GEOM_LABEL ufsid
Can you set kern.geom.label.debug sysctl to 5, then try booting or whatever you use to bring up the .eli devices, then post what kernel messages are generated? The idea is to see if the .eli devices trigger GEOM tasting mechanisms at all (they should).
#8 Re: GEOM_LABEL ufsid
Ok, so now I've solved one half of the problem, got the encrypted swap working at last, by manually creating a label, I guess it has to be done manually as /dev/ad4s3b isn't an ufs filesystem?
I noticed that ufsid for /dev/ad4s3g.eli shows _after_ /etc/rc.d/geli has run on /dev/ad4s3g (and then gets removed by the kernel), but then it's too late to be useful for mounting, right?
This is what the kernel outputs on boot:
GEOM_LABEL[2]: Tasting ad4.
GEOM_LABEL[1]: MSDOSFS: ad4: FAT12/16 volume not valid.
GEOM_LABEL[2]: Tasting ad4s1.
GEOM_LABEL[1]: MSDOSFS: ad4s1: FAT32 volume not valid.
GEOM_LABEL[0]: Label for provider ad4s1 is ntfs/Preload.
GEOM_LABEL[2]: Tasting ad4s2.
GEOM_LABEL[1]: MSDOSFS: ad4s2: FAT32 volume detected.
GEOM_LABEL[0]: Label for provider ad4s2 is msdosfs/SERVICEV001.
GEOM_LABEL[2]: Tasting ad4s3.
GEOM_LABEL[1]: MSDOSFS: ad4s3: FAT32 volume not valid.
GEOM_LABEL[2]: Tasting ntfs/Preload.
GEOM_LABEL[2]: Tasting msdosfs/SERVICEV001.
GEOM_LABEL[2]: Tasting ad4s3a.
GEOM_LABEL[1]: UFS2 file system detected on ad4s3a.
GEOM_LABEL[0]: Label for provider ad4s3a is ufsid/46ffbeb35d10efed.
GEOM_LABEL[1]: UFS2 file system detected on ad4s3a.
GEOM_LABEL[1]: MSDOSFS: ad4s3a: FAT32 volume not valid.
GEOM_LABEL[2]: Tasting ad4s3b.
GEOM_LABEL[0]: Label for provider ad4s3b is label/zebra_swap.
GEOM_LABEL[1]: MSDOSFS: ad4s3b: no FAT signature found.
GEOM_LABEL[2]: Tasting ad4s3c.
GEOM_LABEL[1]: MSDOSFS: ad4s3c: FAT32 volume not valid.
GEOM_LABEL[2]: Tasting ad4s3d.
GEOM_LABEL[1]: UFS2 file system detected on ad4s3d.
GEOM_LABEL[0]: Label for provider ad4s3d is ufsid/46ffbeb75b4235c7.
GEOM_LABEL[1]: UFS2 file system detected on ad4s3d.
GEOM_LABEL[1]: MSDOSFS: ad4s3d: no FAT signature found.
GEOM_LABEL[2]: Tasting ad4s3e.
GEOM_LABEL[1]: UFS2 file system detected on ad4s3e.
GEOM_LABEL[0]: Label for provider ad4s3e is ufsid/46ffbeb5faf9b157.
GEOM_LABEL[1]: UFS2 file system detected on ad4s3e.
GEOM_LABEL[1]: MSDOSFS: ad4s3e: no FAT signature found.
GEOM_LABEL[2]: Tasting ad4s3f.
GEOM_LABEL[1]: UFS2 file system detected on ad4s3f.
GEOM_LABEL[0]: Label for provider ad4s3f is ufsid/46ffbeb691694c86.
GEOM_LABEL[1]: UFS2 file system detected on ad4s3f.
GEOM_LABEL[1]: MSDOSFS: ad4s3f: no FAT signature found.
GEOM_LABEL[2]: Tasting ad4s3g.
GEOM_LABEL[1]: MSDOSFS: ad4s3g: no FAT signature found.
GEOM_LABEL[2]: Tasting ufsid/46ffbeb35d10efed.
GEOM_LABEL[2]: Tasting label/zebra_swap.
GEOM_LABEL[2]: Tasting ufsid/46ffbeb75b4235c7.
GEOM_LABEL[2]: Tasting ufsid/46ffbeb5faf9b157.
GEOM_LABEL[2]: Tasting ufsid/46ffbeb691694c86.
Trying to mount root from ufs:/dev/ufsid/46ffbeb35d10efed
GEOM_ELI: Device ad4s3g.eli created.
GEOM_ELI: Encryption: AES-CBC 256
GEOM_ELI: Crypto: software
GEOM_LABEL[2]: Tasting ad4s3g.eli.
GEOM_LABEL[1]: UFS2 file system detected on ad4s3g.eli.
GEOM_LABEL[0]: Label for provider ad4s3g.eli is ufsid/470a2897f463f2b2.
GEOM_LABEL[1]: UFS2 file system detected on ad4s3g.eli.
GEOM_LABEL[1]: MSDOSFS: ad4s3g.eli: no FAT signature found.
GEOM_LABEL[2]: Tasting ufsid/470a2897f463f2b2.
GEOM_ELI: Device label/zebra_swap.eli created.
GEOM_ELI: Encryption: AES-CBC 256
GEOM_ELI: Crypto: software
GEOM_LABEL[2]: Tasting label/zebra_swap.eli.
GEOM_LABEL[1]: MSDOSFS: label/zebra_swap.eli: no FAT signature found.
GEOM_LABEL[2]: Tasting ufsid/46ffbeb35d10efed.
GE
_LABEL[0]: Label ufsid/470a2897f463f2b2 removed.
GEOM_LABEL[2]: Tasting ufsid/46ffbeb5faf9b157.
GEOM_LABEL[2]: Tasting ad4s3g.eli.
GEOM_LABEL[1]: UFS2 file system detected on ad4s3g.eli.
GEOM_LABEL[0]: Label for provider ad4s3g.eli is ufsid/470a2897f463f2b2.
GEOM_LABEL[1]: UFS2 file system detected on ad4s3g.eli.
GEOM_LABEL[1]: MSDOSFS: ad4s3g.eli: no FAT signature found.
GEOM_LABEL[2]: Tasting ufsid/470a2897f463f2b2.
GEOM_LABEL[2]: Tasting ufsid/46ffbeb691694c86.
GEOM_LABEL[2]: Tasting ufsid/46ffbeb75b4235c7.
GEOM_LABEL[0]: Label ufsid/470a2897f463f2b2 removed.
#9 Re: GEOM_LABEL ufsid
Yes, swap space isn't a file system :) You created a label directly on ad4s3b? It would be better to destroy this label and create one on ad4s3b.eli, if you want to go this route. The reason is that you don't expose the label until the en/decrypted content is made accssible.
Judging by your messages, everything's ok:
GEOM_LABEL[0]: Label for provider ad4s3g.eli is ufsid/470a2897f463f2b2
You probably mount or in some other way use ad4s3g.eli directly, so that's why you get the follow-up message:
GEOM_LABEL[0]: Label ufsid/470a2897f463f2b2 removed.
Find the place where you use ad4s3g.eli (possibly fstab) and replace it with ufsid/470a2897f463f2b2,
#10 Re: GEOM_LABEL ufsid
But if I create a label for the swap on ad4s3b.eli, this device cannot be attached when I move the disk to the caddy (where the device name is ad0s3b) and GELI still tries to attach from ad4s3b? Or maybe I'm missing something?
fstab should look like this?
/dev/ufsid/470a2897f463f2b2 /home ufs rw 2 2
rc.conf:
geli_ad4s3g_flags="-k /root/ad4s3g.key"
replaced with
geli_ufsid/470a2897f463f2b2_flags="-k /root/ad4s3g.key"
and it should just work?
I'll give this a try, thanks for your great work on ufsid!
#11 Re: GEOM_LABEL ufsid
You're right about the label of course - it all depends on what you're trying to achieve.
The fstab line looks ok (I'd put "0 " for the fsck/dump counts).
The second rc.conf line doesn't look ok. First, slashes are not valid in rc.conf variable names.
You should just keep the first line (geli_ad4s3g_flags). When the ad4s3g.eli device comes up, GEOM_LABEL should pick up the file system within it and present you with a label.
If I read the rc.d code for GELI correctly, this is the sequence of events you should be getting:
I'm not an expert on GELI so if you are seeing something different please write back.
#12 Re: GEOM_LABEL ufsid
Well I tried the stuff I wrote above, and it doesn't work.
The problem is that the .eli devices in /dev are created after GELI has run, so one cannot have GELI attach from ufsid/labels on the .eli device that aren't revealed until after GELI has run on /dev/ad4s3g and the /dev/ad4s3g.eli is available/attached and /dev/ufsid/470a2897f463f2b2 created.
Classic chicken and egg problem ;)
So I guess I'll have to manually label the GELI encrypted partitions to get this to work when moving the drive around.
#13 Re: GEOM_LABEL ufsid
I don't follow you - GELI doesn't attach from ufsid label, GELI attaches on a raw drive and the label attaches to the .eli device.
#14 Re: GEOM_LABEL ufsid
I'll try to be more clear about what I'm trying to accomplish.
>GELI attaches on a raw drive
Yes, and this is a problem if I'm going to move the drive around, I can't have GELI trying to attach /dev/ad4s3g if the device name is /dev/ad0s3g after moving the drive to another computer.
#15 Re: GEOM_LABEL ufsid
Ah sorry, I'm constantly working around a bad idea. You can't use ufsid labels for that.
You could create a plain label ("glabel label...") on the raw device and create the .eli device on top of that label. But then you'd have a problem with slashes in device names in the rc.conf variables. Please post your question on the freebsd-geom@ mailing list, there are people who have created GELI there that could have an idea how to solve this problem.
#16 Re: GEOM_LABEL ufsid
>You could create a plain label ("glabel label...")
This was what I was planning to do.
So I rebooted in single user, created the label on ad4s3g and changed fstab+rc.conf.
After running '/etc/rc.d/geli start' I got a message saying it couldn't attach.
I changed fstab+rc.conf back to the original configuration, ran '/etc/rc.d/geli start' again.
Same error messages about not being able to attach again.
What the h*ll is going on?
Now I'm feeling all warm and pearls of sweat start to form on my forehead.
'geli dump ad4s3g'
metadata corrupt (or something like that)
NOOO!
Feeling even warmer now :(
But then I remember, didn't I do a backup of some stuff when I installed the computer 2 years ago.
Now where's that old usb flash drive I used back then...
Found it at last in a drawer, popped it in, mounted, and voila; ad4s3g.key and ad4s3g.metadata is there :)
So after 'man glabel' and 'man geli' I typed 'glabel clear home && geli restore ad4s3g.metadata ad4s3g'.
Fingers crossed.
'/etc/rc.d/geli start'
AND IT WORKS! =)
So at least now I can confirm that geli metadata backup/restore works as it's supposed to.
It seems that glabel and geli writes it's metadata in the same place on the last sector on the partition?
I guess I'll just have to manually change fstab and rc.conf for the GELI partition before moving the old harddrive to the ca
ddy, at least with ufsid there'll be less lines to change. :)
Now I'm going to install -CURRENT and try out VirtualBox on the new harddrive so I can experiment further without trashing m
y old installation ;)
#17 Re: GEOM_LABEL ufsid
Thanks for your work.
But wouldn't it be better to not polute /dev directory with ufsid and rather created something like /dev/disk/by-id or /dev/fs/ufsid ?
Because will we have special dir for each fs right in /dev ?
#18 Re: /dev pollution
Yes, this is a design choice I also don't like - it is advocated by the original author. Unfortunately, now it's "written in stone" and every new label type will have its own directory.
#19 Re: /dev pollution
Out of curiosity, who's the author? Maybe more of us could persuade him/her. :-) And I guess it might be possible to change it with the all new version like 8 or 9.. or not?