[Bug 282832] makefs zfs creates images with the same guid
- In reply to: bugzilla-noreply_a_freebsd.org: "[Bug 282832] makefs zfs creates images with the same guid"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 18 Nov 2024 17:13:22 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282832 --- Comment #6 from Pat Maddox <pat@patmaddox.com> --- My root pool is copied from release / our prior convo: makefs -t zfs -s 20g \ -o poolname=zroot -o bootfs=zroot/ROOT/default -o rootpath=/ \ -o fs=zroot\;mountpoint=none \ -o fs=zroot/ROOT\;mountpoint=none \ -o fs=zroot/ROOT/default\;mountpoint=/ \ -o fs=zroot/home\;mountpoint=/home \ -o fs=zroot/tmp\;mountpoint=/tmp\;exec=on\;setuid=off \ -o fs=zroot/usr\;mountpoint=/usr\;canmount=off \ -o fs=zroot/usr/ports\;setuid=off \ -o fs=zroot/usr/src \ -o fs=zroot/usr/obj \ -o fs=zroot/var\;mountpoint=/var\;canmount=off \ -o fs=zroot/var/audit\;setuid=off\;exec=off \ -o fs=zroot/var/crash\;setuid=off\;exec=off \ -o fs=zroot/var/log\;setuid=off\;exec=off \ -o fs=zroot/var/mail\;atime=on \ -o fs=zroot/var/tmp\;setuid=off \ ${outfileroot} ${rootdir} and the data pool is another typical invocation: makefs -t zfs -s 100m \ -o poolname=zdata -o rootpath=/ \ -o fs=zdata\;mountpoint=/\;canmount=noauto \ -o fs=zdata/usr\;mountpoint=/usr\;canmount=off \ -o fs=zdata/usr/local\;canmount=off \ -o fs=zdata/usr/local/poudriere \ ${BUILDDIR}/zdata.zfs ${BUILDDIR}/data ----- > the root pool should be reguid'ed on first boot anyway. The official VM images configure this automatically (they set zpool_reguid=zroot in /etc/rc.conf) Good to know, I will check that out. I would kind of expect it to not work, because I think the boot process doesn't even make it that far as I showed above. I'll try it out and report back though. So I think it may be worth providing a way to 1) randomize the guid on creation and/or 2) seed the RNG on creation. Extend this to a third disk: I have one root pool, one read-only pool with a dataset, and a third writable pool that contains long-lived data. I need all of these to have different GUIDs. The reason I may want to seed the RNG is because if I replace the root pool, I want the VM to think it's the same. From the VM standpoint, it's like I exported the pool, imported it to another host, did some stuff on it, and imported it back on the VM. I happen to be reconstructing the disk via code, but no reason the VM needs to know that. -- You are receiving this mail because: You are the assignee for the bug.