Re: FreeBSD, boot environments and /dev

2022-05-09 Thread Dave Cottlehuber
On Mon, 9 May 2022, at 06:25, Michael Schuster wrote:
> On Fri, May 6, 2022 at 12:15 AM Wes Maag  wrote:
>> 
>> 
>> On Thu, May 5, 2022 at 4:10 PM Michael Schuster  
>> 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:

This is expected; /dev would usually be empty until devfs is mounted.

Looking into the unmounted /dev via the last zfs snapshot of your
/ filesystem should also be empty:

$ ls -AFGhl /.zfs/snapshot/$(ls -rt /.zfs/snapshot/ | tail -1)/dev
total 0

If it's not I'd guess these are stray garbage from BE experiments
where /dev wasn't mounted and various scripts & tools tried to pipe
via /dev/{fd,zero,null,...}.

If you created a hypothetical "empty" BE from scratch, unpacked
src tarballs into it, it would also be empty.

A+
Dave



Re: FreeBSD, boot environments and /dev

2022-05-09 Thread Michael Schuster
On Fri, May 6, 2022 at 12:15 AM Wes Maag  wrote:

>
>
> On Thu, May 5, 2022 at 4:10 PM Michael Schuster 
> 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 ...
>>
>>
> 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." after mounting with
> "bectl mount" which should give you the same effect as -c without the
> rooted devfs requirement
>

thx Wes and others for feedback, on or off list.
For now I'd like to keep the simplest setting in focus:

When I do:
# beadm create new_BE
# beadm activate new_BE
# reboot

I would expect new_BE to boot and also otherwise to all intents and
purposes behave just like the previous BE I just "left"; similarly, if I
skip the 'activate' step and select new_BE from the FreeBSD boot menu.

thx
Michael
--
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'