Re: FreeBSD, boot environments and /dev
On Sat, May 14, 2022, 21:40 Michael Schuster wrote:
>
> On Thu, May 12, 2022 at 9:21 AM Dave Cottlehuber wrote:
> >
> > On Thu, 12 May 2022, at 07:12, Michael Schuster wrote:
> > > On Wed, May 11, 2022 at 11:38 PM Dave Cottlehuber
> > > wrote:
> > >> On Wed, 11 May 2022, at 14:58, Michael Schuster wrote:
> > >> > I then created a new BE, mounted it on /mnt, removed /mnt/dev/* (only
> > >> > regular files and empty directories). Booting into that BE didn't work
> > >> > either, I got errors about missing "/dev/" files (can't recall the
> > >> > exact names).
> > >> >
> > >> > What do you guys (plural ;-)) think?
> > >
> > > Hi Dave,
> > > thx for your perseverance :-)
> > >
> > > I have (at least) one question for you before I attempt this:
> > > where do I get these .txz files?
> >
> > https://download.freebsd.org/ftp/snapshots/amd64/amd64/14.0-CURRENT/
> > https://download.freebsd.org/ftp/releases/amd64/amd64/13.1-RC6/
> >
> > > should devfs be in /etc/fstab? in my current BE, it isn't ...
> >
> > this is the bare minimum I used. NB my partitions have artisanal
> > GPT labels, yours will probably be different.
> >
> > # DeviceMountpoint FStype Options
> > DumpPass#
> > #/dev/gpt/swap0 noneswapsw
> > 0 0
> > /dev/gpt/efiboot/boot/efi msdosfs
> > rw,late,longnames 0 0
> > tmpfs /tmptmpfs
> > rw,mode=01777,size=120g 0 0
> >
> > thats all I needed to boot to userland & login. I'm reasonably sure that,
> > assuming you have a default zfs install, you'd not need anything in
> > /etc/fstab
> > to boot.
> >
> > > if so: do you have an example of such a line? In the instances I looked
> > > up, I wasn't quite able to make it work (but perhaps that's a dead end
> > > anyway).
> > >
> > >> # bectl activate -t vanilla
> > >
> > > does that ("activate -t") work on UEFI systems? The last time I used it
> > > (at least a year ago), it wasn't.
> >
> > Yes it does here. failing that just use `bectl activate`. The -t is
> > a very nice addition.
> >
> > Well, we're definitely on the FreeBSD-current email list here, so it's
> > definitely in CURRENT, and 13.1 RC.
>
> Dave, all:
>
> findings:
> 1) temporary activation doesn't work for me: bectl accepts the option
> but there's no effect I noticed(*), beadm refuses the option.
update (answered in a different thread, but to keep this here too):
temporary activation does in fact work, it's not reflected in the list
of BEs presented at the boot menu
I'm still working on a "full" installation of what I have on the
running BE into the new one ("vanilla") - if you have any ideas, I
welcome them :-)
thx
Michael
>
> 2) booting into 'vanilla' worked - I got into a root shell on the console.
>
> Since I copied the files you mention (/etc/fstab /etc/rc.conf
> /boot/loader.conf) unchanged, that looks good.
>
> so ... this is probably a good starting point (again ;-)).
>
> I rebooted into the last "good" BE, mounted vanilla a clone of vanilla
> on /mnt (with vanilla a point to start again if anything goes wrong)
> and started with "pkg -r /mnt install pkg" ...
>
> but I admit it's getting late today, so I'll be lazy and ask if you
> have any further recommendations - I've come to expect them to work
> nicely :-) (and yes, I am grateful!)
>
> *) unless the first BE to be shown when I select 'boot environments'
> at boot isn't in fact the active one
>
Re: FreeBSD, boot environments and /dev
On Sat, May 14, 2022 at 10:30 PM Mark Millard wrote: > > Michael Schuster wrote on > Date: Sat, 14 May 2022 21:40:56 +0200 : > > > findings: > > 1) temporary activation doesn't work for me: bectl accepts the option > > but there's no effect I noticed(*), beadm refuses the option. > > . . . > > *) unless the first BE to be shown when I select 'boot environments' > > at boot isn't in fact the active one [...] > > I expect that you will find the temporary activation worked just > fine, as it always has for me: you are right - it did! thanks for the advice (a bit surprising, but who am I to judge ;-)) cheers -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion'
Re: FreeBSD, boot environments and /dev
On Thu, May 12, 2022 at 9:21 AM Dave Cottlehuber wrote:
>
> On Thu, 12 May 2022, at 07:12, Michael Schuster wrote:
> > On Wed, May 11, 2022 at 11:38 PM Dave Cottlehuber
> > wrote:
> >> On Wed, 11 May 2022, at 14:58, Michael Schuster wrote:
> >> > I then created a new BE, mounted it on /mnt, removed /mnt/dev/* (only
> >> > regular files and empty directories). Booting into that BE didn't work
> >> > either, I got errors about missing "/dev/" files (can't recall the
> >> > exact names).
> >> >
> >> > What do you guys (plural ;-)) think?
> >
> > Hi Dave,
> > thx for your perseverance :-)
> >
> > I have (at least) one question for you before I attempt this:
> > where do I get these .txz files?
>
> https://download.freebsd.org/ftp/snapshots/amd64/amd64/14.0-CURRENT/
> https://download.freebsd.org/ftp/releases/amd64/amd64/13.1-RC6/
>
> > should devfs be in /etc/fstab? in my current BE, it isn't ...
>
> this is the bare minimum I used. NB my partitions have artisanal
> GPT labels, yours will probably be different.
>
> # DeviceMountpoint FStype Options
> DumpPass#
> #/dev/gpt/swap0 noneswapsw
> 0 0
> /dev/gpt/efiboot/boot/efi msdosfs
> rw,late,longnames 0 0
> tmpfs /tmptmpfs
> rw,mode=01777,size=120g 0 0
>
> thats all I needed to boot to userland & login. I'm reasonably sure that,
> assuming you have a default zfs install, you'd not need anything in /etc/fstab
> to boot.
>
> > if so: do you have an example of such a line? In the instances I looked
> > up, I wasn't quite able to make it work (but perhaps that's a dead end
> > anyway).
> >
> >> # bectl activate -t vanilla
> >
> > does that ("activate -t") work on UEFI systems? The last time I used it
> > (at least a year ago), it wasn't.
>
> Yes it does here. failing that just use `bectl activate`. The -t is
> a very nice addition.
>
> Well, we're definitely on the FreeBSD-current email list here, so it's
> definitely in CURRENT, and 13.1 RC.
Dave, all:
findings:
1) temporary activation doesn't work for me: bectl accepts the option
but there's no effect I noticed(*), beadm refuses the option.
2) booting into 'vanilla' worked - I got into a root shell on the console.
Since I copied the files you mention (/etc/fstab /etc/rc.conf
/boot/loader.conf) unchanged, that looks good.
so ... this is probably a good starting point (again ;-)).
I rebooted into the last "good" BE, mounted vanilla a clone of vanilla
on /mnt (with vanilla a point to start again if anything goes wrong)
and started with "pkg -r /mnt install pkg" ...
but I admit it's getting late today, so I'll be lazy and ask if you
have any further recommendations - I've come to expect them to work
nicely :-) (and yes, I am grateful!)
*) unless the first BE to be shown when I select 'boot environments'
at boot isn't in fact the active one
cheers
Michael
--
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'
Re: FreeBSD, boot environments and /dev
On Wed, May 11, 2022 at 11:38 PM Dave Cottlehuber wrote:
> On Wed, 11 May 2022, at 14:58, Michael Schuster wrote:
> > I then created a new BE, mounted it on /mnt, removed /mnt/dev/* (only
> > regular files and empty directories). Booting into that BE didn't work
> > either, I got errors about missing "/dev/" files (can't recall the
> > exact names).
> >
> > What do you guys (plural ;-)) think?
>
Hi Dave,
thx for your perseverance :-)
I have (at least) one question for you before I attempt this:
> this works for me:
>
> # zfs create -o canmount=noauto -o mountpoint=/ zroot/ROOT/vanilla
> # bectl mount vanilla /mnt
> # cd /some/path/to/sets/
> # tar xzpf ./kernel.txz -C /mnt/
> # tar xzpf ./base.txz -C /mnt/
>
showing my ignorance here: where do I get these .txz files?
# tzsetup -C /mnt UTC
> # pwd_mkdb -p -d /mnt/etc /mnt/etc/master.passwd
> # ln -s /usr/home /mnt/home
> ### copy in & amend /etc/fstab /etc/rc.conf /boot/loader.conf as required
>
should devfs be in /etc/fstab? in my current BE, it isn't ...
if so: do you have an example of such a line? In the instances I looked up,
I wasn't quite able to make it work (but perhaps that's a dead end anyway).
# bectl activate -t vanilla
>
does that ("activate -t") work on UEFI systems? The last time I used it (at
least a year ago), it wasn't.
Thx
Michael
# reboot
>
> try that and let us know what, if any, errors you get?
>
> A+
> Dave
>
--
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'
Re: FreeBSD, boot environments and /dev
On Mon, May 9, 2022 at 10:04 AM Dave Cottlehuber wrote:
>
> 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.
You're right - I have a few "historical" BEs lying around, and for
most of them, /dev/ is empty. As you guess (below), for the others,
they're most likely remnants of the first time I tried to do "pkg -c
/mnt" without /mnt/dev being mounted. (as an aside: when was that
changed? I know for sure that this hasn't always been necessary)
I then created a new BE, mounted it on /mnt, removed /mnt/dev/* (only
regular files and empty directories). Booting into that BE didn't work
either, I got errors about missing "/dev/" files (can't recall the
exact names).
What do you guys (plural ;-)) think?
Thx
Michael
>
> 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
--
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'
Re: FreeBSD, boot environments and /dev
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'
Re: FreeBSD, boot environments and /dev
Hi Wes, finally I get round to responding (below) ... 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 ... >> -- >> 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. as I wrote, I *thought* that worked automatically ... apparently not. > 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. (after beadm create and beadm mount): $ zfs list -tall [...] tank/ROOT/BE_20220507_171901_adm 184K 397G 17.9G / tank/ROOT/BE_20220507_171901_adm/ports 8K 397G 1.92G /usr/ports tank/ROOT/BE_20220507_171901_adm/src 8K 397G 2.57G /usr/src $ mount | grep dev devfs on /dev (devfs) /dev/nvd0p1 on /boot/efi (msdosfs, local) devfs on /compat/linux/dev (devfs) fdescfs on /compat/linux/dev/fd (fdescfs) tmpfs on /compat/linux/dev/shm (tmpfs, local) $ cat /etc/fstab # DeviceMountpoint FStype Options DumpPass# /dev/nvd0p1 /boot/efi msdosfs rw 2 2 /dev/nvd0p3 noneswapsw 0 0 proc/proc procfs rw 0 0 > 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 good point ... until now, "pkg -c" worked as expected, I never looked further ;-) I'll keep it in mind! I expected (perhaps naively) that with -c, pkg would be using the "new" stuff I'd installed in the previous step (see below), not the currently running bits ... Any thoughts on that? One more data point, perhaps that's relevant: I've been updating these BEs using a sequence of installing freshly built current into /mnt (using "DESTDIR=/mnt"), following by a few ports (drm-devel, primarily), and then doing pkg update/upgrade. thx Michael -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion'
FreeBSD, boot environments and /dev
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'
Re: "pkg upgrade" failing with "Fail to create temporary file: ... Not a directory"
On Thu, Apr 28, 2022 at 10:43 AM Christoph Moench-Tegeder wrote: > > ## Michael Schuster (michaelspriv...@gmail.com): > > > $subject happened to me just now on current. I researched it on the > > internet, > > Don't look that far, the answer is in UPDATING: > 20220426: > AFFECTS: users of deskutils/grantleetheme thx all - that was the relevant hint here. regards Michael > > Regards, > Christoph > > -- > Spare Space -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion'
Re: "pkg upgrade" failing with "Fail to create temporary file: ... Not a directory"
Chris, thx for your response. However On Thu, Apr 28, 2022 at 4:19 AM Chris wrote: > > On 2022-04-27 12:59, Michael Schuster wrote: > > Hi, > > > > $subject happened to me just now on current. I researched it on the > > internet, the answer to this issue seems to be a universal "uninstall > > and install the package" which seems to have worked in all cases I saw > > it suggested. > > > > I'm trying to embed this command into a script and would like to avoid > > manual intervention (I have to admit, this is the first time I've > > encountered this error in the two years I've been doodling with > > FreeBSD again) ... > > Is anything more known about this error behaviour, and what I can do > > to avoid it? > > > > TIA > > Michael > > > > PS: in case it matters: the full path shown in the error message is > > /usr/local/include/KF5/GrantleeTheme/GrantleeTheme/.pkgtemp.GenericFormatter.qSk5LxEaheWG, > > the package being extracted is grantleetheme-22.04.0 > This looks more a case for the Maintainer of the GrantleeTheme than for > current@ ... maybe. OTOH, the instances I found mentioned on the 'net are all about different packages: eg: https://forums.freebsd.org/threads/pkg-upgrade-fail-to-create-temporary-file.67923/ https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237767 I feel there's something different at work here than just one maintainer's oversight. Thx Michael -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion'
"pkg upgrade" failing with "Fail to create temporary file: ... Not a directory"
Hi, $subject happened to me just now on current. I researched it on the internet, the answer to this issue seems to be a universal "uninstall and install the package" which seems to have worked in all cases I saw it suggested. I'm trying to embed this command into a script and would like to avoid manual intervention (I have to admit, this is the first time I've encountered this error in the two years I've been doodling with FreeBSD again) ... Is anything more known about this error behaviour, and what I can do to avoid it? TIA Michael PS: in case it matters: the full path shown in the error message is /usr/local/include/KF5/GrantleeTheme/GrantleeTheme/.pkgtemp.GenericFormatter.qSk5LxEaheWG, the package being extracted is grantleetheme-22.04.0 -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion'
advice sought: workflow with -CURRENT and amd GPU [Re: -CURRENT hangs since at least 2022-04-04]
Hi, I'm highjacking and re-purposing the previous thread, I hope that's OK (I did change the subject ;-)) - I'm keeping some of the previous contents for reference. I have similar HW to OP (Ryzen 7 4700 w. Renoir Graphics), and have been using a similar approach to keep the machine up to date - or so I suspect. Still, after a while (several months), I end up with one or more of these: - I get some sort of panic in DRM (at startup or, currently, at shutdown) - when I boot into to a previous BE to attempt a fix and then again reboot into the current one, I get tons of messages like this "... kernel: KLD iic.ko: depends on kernel - not available or version mismatch ... kernel: linker_load_file: /boot/kernel/iic.ko - unsupported file type" and computer refuses to accept input (let alone start X) and some others I don't recall right now. Before I ask for advice (see below), let me explain the approaches I've taken so far. I install with ZFS from the beginning, current boot env is "N". These are outlines, not exact commands: I) never touch the current BE, always update a new one: 1) given current BE N, I create a new BE N+1 and mount it on /mnt, 2) 'cd /usr/src; git pull; sudo make DESTDIR=/mnt ... (build, install, etc)' 3) 'cd usr/ports/graphics/drm-devel-kmod; sudo make DESTDIR=/mnt install' 4) beadm activate BE N+1; reboot II) keep a "new" BE as backup/fallback, update current BE: 1) given current BE N, I create a new BE N+1 (mounting not required) (this is the intended 'fallback') 2) 'cd /usr/src; git pull"; then "make" as described in the Handbook "24.6. Updating FreeBSD from Source" 3) 'cd usr/ports/graphics/drm-devel-kmod; sudo make install' 4) reboot in both scenarios(sp?), I do "pkg update; pkg upgrade" from time to time (also following the resp. approach shown above). I suspect that I'm missing something fundamental in my approaches - does anyone have a (for them) foolproof approach along these lines, or can someone show me what I'm missing in either of mine (in private, if you prefer)? TIA for all and any advice Michael On Mon, Apr 18, 2022 at 9:33 PM Pete Wright wrote: > > > > On 4/18/22 12:23, filis+fbsdcurr...@filis.org wrote: > > Hi, > > > > I'm running -CURRENT on this one desktop box which is a "Ryzen 7 4800U > > with Radeon Graphics", since it didn't work on 13R. > > I use Boot environments and on 2022-04-04 I updated it and it started > > to completely freeze under X (I haven't tried letting it run without > > X) after a few dozen minutes. > [...] > > > After updating your CURRENT environment did you rebuild the drm-kmod > package? that's usually required as the LKPI is much more of a moving > target on that branch compared to STABLE or RELEASE. i have a pretty > much identical setup and building/installing drm-devel-kmod has been > working flawlessly for quite a while. > > after building/installing my latest world i do following (this is from a > local script i use when rebuilding): > > cd $PORTS/graphics/drm-devel-kmod > sudo pkg unlock -y drm-devel-kmod > sudo make package > sudo pkg upgrade -y work/pkg/*.pkg > sudo pkg lock -y drm-devel-kmod > > -pete > > -- > Pete Wright > p...@nomadlogic.org > @nomadlogicLA > > -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion'
Re: recover deleted file
On Sat, Apr 16, 2022, 13:24 Sami Halabi wrote: > Hi, > is there anyway easy to restore deleted file by accident in UFS > If you used "rm" and didn't take the media offline immediately after, then no, not only not easy but probably impossible (depending on how active the FS is) > Sami > > -- > Sami Halabi > Information Systems Engineer > NMS Projects Expert, FreeBSD SysAdmin Expert > Asterisk Expert >
solved: [Re: CURRENT doesn't recognise synaptics touchpad]
Hi all, sometimes, reading documentation does help :-) I followed the instructions at https://github.com/wulf7/iichid and added this: ig4_load="YES" iicbus_load="YES" to the already present iichid_load="YES" in /boot/loader.conf, and now touchpad works. cheers! Michael On Thu, Mar 3, 2022 at 9:06 PM Michael Schuster wrote: > Hi all, > > I have another issue with my recent re-installation to Current: touchpad > support seems to have vanished. I know it works because the keyboard lights > up when I touch it, it also works under linux (dual-boot), and it worked > with the previous installation of FreeBSD, where I installed iichid (and > others, I guess) from the sources. > > I've been searching high and low for things to test or set, with no > visible success: > - create an /etc/X11/xorg.conf > - add or remove various settings from /boot/loader.conf > > I have libinput and xf86-input-libinput installed. > > TIA for all and any advice/pointers/RTFMs. > > cheers > Michael > -- > Michael Schuster > http://recursiveramblings.wordpress.com/ > recursion, n: see 'recursion' > -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion'
CURRENT doesn't recognise synaptics touchpad
Hi all, I have another issue with my recent re-installation to Current: touchpad support seems to have vanished. I know it works because the keyboard lights up when I touch it, it also works under linux (dual-boot), and it worked with the previous installation of FreeBSD, where I installed iichid (and others, I guess) from the sources. I've been searching high and low for things to test or set, with no visible success: - create an /etc/X11/xorg.conf - add or remove various settings from /boot/loader.conf I have libinput and xf86-input-libinput installed. TIA for all and any advice/pointers/RTFMs. cheers Michael -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion'
Re: "vidcontrol -i mode" shows no output except header (in search of smaller console font)
On Mon, Feb 28, 2022 at 9:31 AM Ronald Klop wrote: > Hi, > > Where would this sysctl needed to be documented for the OP to find it? > IMO vt(4) would have been a good place. > > Regards, > Ronald > > > *Van:* Toomas Soome > *Datum:* 28 februari 2022 08:29 > *Aan:* Michael Schuster > *CC:* FreeBSD CURRENT > *Onderwerp:* Re: "vidcontrol -i mode" shows no output except header (in > search of smaller console font) > > > > On 28. Feb 2022, at 08:23, Michael Schuster > wrote: > > Hi Toomas, > > > On Sun, Feb 27, 2022 at 10:54 PM Toomas Soome wrote: > >> >> >> On 27. Feb 2022, at 23:36, Michael Schuster >> wrote: >> >> Hi all, >> >> I'm trying to get a smaller font in my text-consoles (using vt) on my >> Ryzen 4700 and Vega10 Renoir - based laptop with a fresh install of FreeBSD >> CURRENT from last week. >> >> [...] > > >> UEFI or BIOS setup? >> > > UEFI > > >> With UEFI, sc and hw.vga.textmode has no effect. With UEFI or >> BIOS+hw.vga.textmode=0, you can set screen.font variable (empty value will >> cause the values list to be printed), or use loadfont command with your >> custom font file (created with vtfontcvt). >> > > I added 'screen.font="8x16"' to /boot/loader.conf, worked like a charm > first time. > > Many thanks! > Michael > > > You are welcome. > > rgds, > toomas > > > > > > -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion'
Re: "vidcontrol -i mode" shows no output except header (in search of smaller console font)
Hi Toomas, On Sun, Feb 27, 2022 at 10:54 PM Toomas Soome wrote: > > > On 27. Feb 2022, at 23:36, Michael Schuster > wrote: > > Hi all, > > I'm trying to get a smaller font in my text-consoles (using vt) on my > Ryzen 4700 and Vega10 Renoir - based laptop with a fresh install of FreeBSD > CURRENT from last week. > > [...] > UEFI or BIOS setup? > UEFI > With UEFI, sc and hw.vga.textmode has no effect. With UEFI or > BIOS+hw.vga.textmode=0, you can set screen.font variable (empty value will > cause the values list to be printed), or use loadfont command with your > custom font file (created with vtfontcvt). > I added 'screen.font="8x16"' to /boot/loader.conf, worked like a charm first time. Many thanks! Michael -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion'
"vidcontrol -i mode" shows no output except header (in search of smaller console font)
Hi all, I'm trying to get a smaller font in my text-consoles (using vt) on my Ryzen 4700 and Vega10 Renoir - based laptop with a fresh install of FreeBSD CURRENT from last week. My research led me to believe that using vidcontrol would help me here, but however I do try, "vidcontrol -i mode" prints nothing except the header line, and other "vidcontrol" subcommands give me "Inappropriate ioctl for device". I tried a few things - switched to sc via setting "kern.vty=sc" in /boot/loader.conf, this caused a hang on reboot - setting "hw.vga.textmode" to 1 - "kldload vesa" ... and probably a few other things I now forget, all to no effect - I still get nothing. I then performed an update from a freshly 'git pulled' source today (kernel, world, drm-devel-kmod), a simple "vidcontrol" test still shows the same. I know it can work because I had a smaller font before I re-installed over the previous installation (which originally came from ghostbsd in Aug 2020), so - I assume - it can't be rocket science :-) I'd appreciate further hints/pointers/RTFMs (though I've tried quite a few of those). TIA Michael -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion'
Re: "linker_load_file ... unsupported file type" after upgrade attempts on -CURRENT
to respond to myself: I bit the bullet and installed one of the latest
memstick images of -CURRENT , and am back up and running - with amdgpu and
drm-current, and KDE (which had stopped working for me on the previous
setup a while ago).
Sorry if anyone's gone to any lengths here, though I didn't get any
feedback.
Thx
Michael
On Sun, Feb 20, 2022 at 3:12 PM Michael Schuster
wrote:
> Hi,
>
> I'm currently running on -CURRENT from November, though I think the
> message for amdgpu.ko ("kernel: linker_load_file: /boot/modules/amdgpu.ko -
> unsupported file type") started to appear as early as last August. Since
> this isn't my daily driver (yet!), I didn't notice for quite a while, and
> scfb is adequate for what little I currently do on FreeBSD.
> When I initially installed this machine in Aug 2020, my GPU (Vega10
> Renoir) wasn't supported by DRM, so over time I made several builds of the
> graphics/drm-devel-kmod port, which worked for a while last year.
>
> In the last weeks, in the time I managed to set aside for this work, I
> made several attempts to bring this machine up-to-date, using "pkg
> upgrade", building my own from /usr/src (always up-to-date using 'git
> pull'), and beinstall.sh. (both separately and in combination). I always
> work with separate build environments for these attempts.
> All my upgrade attempts have resulted in a system that boots, but neither
> starts X nor lets me log in on a console. There are "linker_load_file ... "
> message for several .ko files, all preceded by a line like this:
>
> "KLD hconf.ko: depends on kernel - not available or version mismatchmodule
> name"
>
> here are the paths I get this message about:
>
> /boot/kernel/cuse.ko
> /boot/kernel/hconf.ko
> /boot/kernel/hms.ko
> /boot/kernel/hmt.ko
> /boot/kernel/intpm.ko
> /boot/kernel/lindebugfs.ko
> /boot/kernel/linux.ko
> /boot/kernel/linux64.ko
> /boot/modules/amdgpu.ko
> /boot/modules/drm.ko
>
> The information I found on the Internet about this error message seem to
> indicate that I need to re-build the .ko being reported by the message with
> the current kernel, which is .. hard if I can't even log in ;-). I would
> also not expect a version mismatch after a pkg upgrade (but no, I didn't go
> through all the output that generated).
>
> Does anyone have an idea what I can do to get past this obstacle? I could
> of course always re-install, but that feels like giving in :-)
>
> TIA
> Michael
> --
> Michael Schuster
> http://recursiveramblings.wordpress.com/
> recursion, n: see 'recursion'
>
--
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'
"linker_load_file ... unsupported file type" after upgrade attempts on -CURRENT
Hi,
I'm currently running on -CURRENT from November, though I think the message
for amdgpu.ko ("kernel: linker_load_file: /boot/modules/amdgpu.ko -
unsupported file type") started to appear as early as last August. Since
this isn't my daily driver (yet!), I didn't notice for quite a while, and
scfb is adequate for what little I currently do on FreeBSD.
When I initially installed this machine in Aug 2020, my GPU (Vega10 Renoir)
wasn't supported by DRM, so over time I made several builds of the
graphics/drm-devel-kmod port, which worked for a while last year.
In the last weeks, in the time I managed to set aside for this work, I made
several attempts to bring this machine up-to-date, using "pkg upgrade",
building my own from /usr/src (always up-to-date using 'git pull'), and
beinstall.sh. (both separately and in combination). I always work with
separate build environments for these attempts.
All my upgrade attempts have resulted in a system that boots, but neither
starts X nor lets me log in on a console. There are "linker_load_file ... "
message for several .ko files, all preceded by a line like this:
"KLD hconf.ko: depends on kernel - not available or version mismatchmodule
name"
here are the paths I get this message about:
/boot/kernel/cuse.ko
/boot/kernel/hconf.ko
/boot/kernel/hms.ko
/boot/kernel/hmt.ko
/boot/kernel/intpm.ko
/boot/kernel/lindebugfs.ko
/boot/kernel/linux.ko
/boot/kernel/linux64.ko
/boot/modules/amdgpu.ko
/boot/modules/drm.ko
The information I found on the Internet about this error message seem to
indicate that I need to re-build the .ko being reported by the message with
the current kernel, which is .. hard if I can't even log in ;-). I would
also not expect a version mismatch after a pkg upgrade (but no, I didn't go
through all the output that generated).
Does anyone have an idea what I can do to get past this obstacle? I could
of course always re-install, but that feels like giving in :-)
TIA
Michael
--
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'
Re: -CURRENT compilation time
Jeremie, a few observations (from the POV of someone who builds current ~ once a month) On Mon, Sep 6, 2021 at 10:09 AM Jeremie Le Hen wrote: > Hey, > > I want to build -CURRENT again from sources. It's been a long time > since I hadn't done that. I'm shocked by the compilation time. > > I started the whole thing on Friday night and Monday morning it's > still in stage 4.2 (building libraries). Through occasional glancing > at the screen over the weekend, it seems obvious to me that the > compilation time is utterly dominated by LLVM. Do you actually measure anything? have you looked into what your I/O is doing? How about swap? Compiling C++ seems > extremely CPU heavy and this is made worse by the fact LLVM is built > twice (once for build/cross tools, once for the actual world). > > So OK, my CPU is not the most powerful out there but it's still decent [1]. > I didn't check the specs: how many cores does your box have, and how many are you actually using (-j N)? IME, htop gives a good idea of how busy the CPUs really are. > So I have a couple of questions coming to my mind: > 1. Is there any optimization I could benefit from? (I'm sure there's a > knob to use the existing compiler instead of building a > cross-compiler.) > look at the build man page (https://www.freebsd.org/cgi/man.cgi?build(7)) for some tips on how to configure your environment. 2. More generally, isn't this compilation time not considered as a > problem for developers? This seems to terribly slow down the iteration > time for people working on the build system. I wouldn't be surprised > if this drove people away from working on/improving that area. > > [1] > https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i5-6260U+%40+1.80GHz=2671 > > Cheers, > -- > Jeremie Le Hen > j...@freebsd.org > > regards Michael -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion'
Re: /usr/share/mk/bsd.sanitizer.mk not found
On Tue, Aug 3, 2021 at 5:13 PM FreeBSD User wrote: > Hallo, > > running latest CURRENT as of FreeBSD 14.0-CURRENT #147 > main-n248437-600745f1e226: Mon Aug 2 > 18:34:54 CEST 2021 amd64, while compiling x11/nividia-driver, I get an > error, stating > /usr/share/mk/bsd.sanitizer.mk is missing. This file ist existent in > /usr/src/share/mk/, but > does not get installed. > > devel/libsysinfo is another port (requisite for firefox) failing due to > the same error. > > What's wrong here? > wild guess: one of the environment variobles used for building (see https://www.freebsd.org/cgi/man.cgi?build(7)) is set. HTH Michael -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion'
panic when connecting or disconnecting A/C power
Hi all, [this is the continuation and update of a thread I incorrectly started in the forum ( https://forums.freebsd.org/threads/panic-when-connecting-or-disconnecting-a-c-power.81550/)- sorry about that] my Ryzen 4700-powered HP Probook running Current as of July 10 is now capable of suspend (I assume thx to drm-devel from the same date). I did a "pkg update" + "pkg upgrade" just today. BIOS is also at the latest available. Laptop boots fine with or without power connected. Whenever I connect or disconnect A/C power, it panics immediately and drops me into kdb. Since at that moment I'm dropped into the console at that moment, I only see part of the stack backtraces - two of them to be precise: The first seems to be be repeated several times; I see two instances thereof, it starts with Code: WARNING !dmr_modeset_is_locked(plane->mutex) failed at ... #0 0xf at linux_dump_stack+0x23 ... the second one has cpuid and a timestamp and then: Code: KDB: stack backtrace: --- trap 0xc, rip ... -- amdgpu_pm_acpi_event_handler() at amdgpu_pm_acpi_event_handler+0x69/frame 0x... amdgpu_acpi_event() at amdgpu_acpi_event+0x62/frame 0x... linux_handle_acpi_acad_event() at linux_handle_acpi_acad_event+0x3c/frame 0x... ... this happens on resume if I disconnect power during sleep. I think it may be relevant that I'm seeing tons of these three messages in the logs and on the text console: Code: Jul 31 18:02:30 hbeast kernel: Firmware Error (ACPI): AE_AML_PACKAGE_LIMIT, Index (0x5) is beyond end of object (length 0x5) (20210604/exoparg2-569) Jul 31 18:02:30 hbeast kernel: ACPI Error: Aborting method \_TZ.GTTP due to previous error (AE_AML_PACKAGE_LIMIT) (20210604/psparse-689) Jul 31 18:02:30 hbeast kernel: ACPI Error: Aborting method \_TZ.CHGZ._TMP due to previous error (AE_AML_PACKAGE_LIMIT) (20210604/psparse-689) ... roughly every ten seconds. I'd be grateful for any pointers or advice to get my power management fixed. I have yet to test w/o graphics driver (as someone suggested I do). regards & TIA Michael -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion'
Re: Heads up! /etc/rc.conf.site is dead.
I think people will get used to /etc/defaults fairly quickly just a note on naming: Solaris as well as HP-UX have /etc/default, not /etc/defaults. Seeing that we're introducing a change, we might just as well move to something others use as well. regards Michael -- Michael Schuster / michael.schus...@germany.sun.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: locale errors
My locale is set do de_DE.ISO_8859-1, not de_DE.ASCII If I type 2 characters ss, I mean 2 characters ss. If I type ß I mean the single character ß. This sorting behaviour is just wrong. Not every apperence of ss even in pure ASCII does mean ß. I suggest you set LC_COLLATE to C, then it sorts in the good old fashioned way its meant to be. (like this on Solaris 7: Assel aSS asen ass asse assel assen aß aßen ) and so: Grüße Michael -- michael.schus...@germany.sun.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
