Date: Thu, 5 May 2022 17:21:00 -0500 From: Wes Maag <jwmaag@gmail.com> To: Michael Schuster <michaelsprivate@gmail.com> Cc: FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: Re: FreeBSD, boot environments and /dev Message-ID: <CAHMcx4PKQzxOCo2GPa7gR544OK7GQrhfbwQ4A8BBQPCteQXKTA@mail.gmail.com> In-Reply-To: <CADqw_g%2BUa8oc-cPm6N3ah1Ey1v-nfNk881O2Vp9TquhBcjDj_g@mail.gmail.com> References: <CADqw_g%2BUa8oc-cPm6N3ah1Ey1v-nfNk881O2Vp9TquhBcjDj_g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Thu, May 5, 2022 at 4:10 PM Michael Schuster <michaelsprivate@gmail.com> wrote: > Hi all, > > while still working (slowly) on an answer to my own question on the > right workflow to keep current up to date reliably with boot > environments, I noticed that after creating and mounting a new BE, > that new BE's /dev (eg /mnt/dev) is very sparsely populated: > > [22:44:45: ~ 0] $ ll /mnt/dev > total 20 > 9 dr-xr-xr-x 4 root wheel 7 Apr 18 00:35 . > 9 drwxr-xr-x 23 root wheel 30 May 5 22:44 .. > 1 drwxr-xr-x 2 root wheel 2 Apr 18 00:35 fd > 1 lrwxr-xr-x 1 root wheel 12 Apr 17 20:41 log -> /var/run/log > 1 -rw-r--r-- 1 root wheel 63 May 3 22:19 null > 1 -rw-r--r-- 1 root wheel 1 May 3 22:18 null.bak > 1 drwxr-xr-x 2 root wheel 2 Apr 18 00:35 shm > [22:44:48: ~ 0] $ > > (no matter whether I use "beadm create" or "bectl create -r") > > I can then mount devfs: > # mount -t devfs devfs /mnt/dev > > and it will look (and work) as expected (eg for "pkg -c /mnt update" > (*)) ... as long as the BE is mounted. > When I try to boot from (into?) that BE though, it fails, and on the > console I can see messages about missing /dev/... entries. I sneaked a > peek into beinstall.sh, found no inspiration there, I'm afraid. > > I believe I noticed this apparent requirement to mount devfs > separately not so long ago ... definitely this year, while I've been > experimenting with boot environments for quite a bit longer. Was I > just lucky all along, or did something change ... and, more > importantly, how do I make my boot environments bootable again? > > TIA for hints, pointers, advice > Michael > > *) I first noticed something was amiss when "pkg -c /mnt ... " > complained about /dev/null missing, IIRC ... > -- > Michael Schuster > http://recursiveramblings.wordpress.com/ > recursion, n: see 'recursion' > > getting /dev/null errors with pkg -c makes sense. I wouldn't expect /dev to contain anything after a create. Why it is not populated on boot seems odd to me though... It's possible, if you created a deep boot environment, you created a pool/ROOT/dev dataset and it is overwriting the initial /dev from boot (I have not tested this theory). Tough to say without more information about the BE layout, and maybe a look at fstab. FWIW I typically run "pkg -r /tmp/be_mount.XXXX" after mounting with "bectl mount" which should give you the same effect as -c without the rooted devfs requirement -- Wes [-- Attachment #2 --] <div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 5, 2022 at 4:10 PM Michael Schuster <<a href="mailto:michaelsprivate@gmail.com">michaelsprivate@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br> <br> while still working (slowly) on an answer to my own question on the<br> right workflow to keep current up to date reliably with boot<br> environments, I noticed that after creating and mounting a new BE,<br> that new BE's /dev (eg /mnt/dev) is very sparsely populated:<br> <br> [22:44:45: ~ 0] $ ll /mnt/dev<br> total 20<br> 9 dr-xr-xr-x 4 root wheel 7 Apr 18 00:35 .<br> 9 drwxr-xr-x 23 root wheel 30 May 5 22:44 ..<br> 1 drwxr-xr-x 2 root wheel 2 Apr 18 00:35 fd<br> 1 lrwxr-xr-x 1 root wheel 12 Apr 17 20:41 log -> /var/run/log<br> 1 -rw-r--r-- 1 root wheel 63 May 3 22:19 null<br> 1 -rw-r--r-- 1 root wheel 1 May 3 22:18 null.bak<br> 1 drwxr-xr-x 2 root wheel 2 Apr 18 00:35 shm<br> [22:44:48: ~ 0] $<br> <br> (no matter whether I use "beadm create" or "bectl create -r")<br> <br> I can then mount devfs:<br> # mount -t devfs devfs /mnt/dev<br> <br> and it will look (and work) as expected (eg for "pkg -c /mnt update"<br> (*)) ... as long as the BE is mounted.<br> When I try to boot from (into?) that BE though, it fails, and on the<br> console I can see messages about missing /dev/... entries. I sneaked a<br> peek into beinstall.sh, found no inspiration there, I'm afraid.<br> <br> I believe I noticed this apparent requirement to mount devfs<br> separately not so long ago ... definitely this year, while I've been<br> experimenting with boot environments for quite a bit longer. Was I<br> just lucky all along, or did something change ... and, more<br> importantly, how do I make my boot environments bootable again?<br> <br> TIA for hints, pointers, advice<br> Michael<br> <br> *) I first noticed something was amiss when "pkg -c /mnt ... "<br> complained about /dev/null missing, IIRC ...<br> -- <br> Michael Schuster<br> <a href="http://recursiveramblings.wordpress.com/" rel="noreferrer" target="_blank">http://recursiveramblings.wordpress.com/</a><br>; recursion, n: see 'recursion'<br> <br></blockquote><div> </div><div><div>getting /dev/null errors with pkg -c makes sense. I wouldn't expect /dev to contain anything after a create.</div><div><br></div><div>Why it is not populated on boot seems odd to me though... It's possible, if you created a deep boot environment, you created a pool/ROOT/dev dataset</div><div>and it is overwriting the initial /dev from boot (I have not tested this theory). Tough to say without more information about the BE layout, and maybe a look at fstab.<br></div><div><br></div><div>FWIW I typically run "pkg -r /tmp/be_mount.XXXX" after mounting with "bectl mount" which should give you the same effect as -c without the rooted devfs requirement<br></div><div><br></div><div>--<br></div><div>Wes </div> </div></div></div>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHMcx4PKQzxOCo2GPa7gR544OK7GQrhfbwQ4A8BBQPCteQXKTA>