Date: Mon, 18 Nov 2024 17:13:22 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 282832] makefs zfs creates images with the same guid Message-ID: <bug-282832-227-yIp60c6vZR@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-282832-227@https.bugs.freebsd.org/bugzilla/> References: <bug-282832-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D282832 --- 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=3Dzroot -o bootfs=3Dzroot/ROOT/default -o rootpath= =3D/ \ -o fs=3Dzroot\;mountpoint=3Dnone \ -o fs=3Dzroot/ROOT\;mountpoint=3Dnone \ -o fs=3Dzroot/ROOT/default\;mountpoint=3D/ \ -o fs=3Dzroot/home\;mountpoint=3D/home \ -o fs=3Dzroot/tmp\;mountpoint=3D/tmp\;exec=3Don\;setuid=3Doff \ -o fs=3Dzroot/usr\;mountpoint=3D/usr\;canmount=3Doff \ -o fs=3Dzroot/usr/ports\;setuid=3Doff \ -o fs=3Dzroot/usr/src \ -o fs=3Dzroot/usr/obj \ -o fs=3Dzroot/var\;mountpoint=3D/var\;canmount=3Doff \ -o fs=3Dzroot/var/audit\;setuid=3Doff\;exec=3Doff \ -o fs=3Dzroot/var/crash\;setuid=3Doff\;exec=3Doff \ -o fs=3Dzroot/var/log\;setuid=3Doff\;exec=3Doff \ -o fs=3Dzroot/var/mail\;atime=3Don \ -o fs=3Dzroot/var/tmp\;setuid=3Doff \ ${outfileroot} ${rootdir} and the data pool is another typical invocation: makefs -t zfs -s 100m \ -o poolname=3Dzdata -o rootpath=3D/ \ -o fs=3Dzdata\;mountpoint=3D/\;canmount=3Dnoauto \ -o fs=3Dzdata/usr\;mountpoint=3D/usr\;canmount=3Doff \ -o fs=3Dzdata/usr/local\;canmount=3Doff \ -o fs=3Dzdata/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=3Dzroot 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 crea= tion 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 al= l 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-282832-227-yIp60c6vZR>