Running pkg 2.5.1. Following a previous pkg command that died OOM, "make install-missing-packages" and "pkg stats" both fail with "pkg-static: sqlite error while executing PRAGMA user_version; in file pkgdb.c:2464: attempt to write a readonly database". How can I fix that, if at all possible without using pkg shell (or sqlite3) commands?

V_PauAmma_V, Did the file system that /var/db/pkg resides on become a read-only file system?

V_PauAmma_V, /var/db/pkg/ should be in the last Boot Environment too. Seems like if things went sideways that it would be possible to recover from it too. Either by booting back to the previous and then upgrading forward again or by reaching into it and carefully replacing the sqlite db files. There are some considerations there.

Do you happen to have any snapshots of it? (I do not here.)

Not readonly that I can see using "zfs list -o name,readonly zroot/var". However, I have a recent BE on that VM. When you say "some considerations", what do you mean?

(For background to my last question, there's nothing in that VM I can't easily recreate. So if even if the pkg database gets broken beyond repair, I will grumble and move on.)

Some considerations means that let's say this morning before the corruption occurred you had installed new packages foo and bar. But then, corruption occurs, and so you recover from the last BE version of the database files. The database won't know that the files for packages foo and bar have been installed.

If this is mostly a scratch VM then you could remove all of /var/db/pkg and all of /usr/local/* and then be back to a clean pristine ports state and then pkg bootstrap -f from square one and then install what ports you need again.

OK, that would probably work. Thanks.

On a fresh install of base the /usr/local directory is empty and I believe /var/db/pkg is empty too. Then pkg bootstrap gets things going.

Meanwhile if I were trying to recover a system and make it really more like it was then I would recover from the BE, generate a pkg info list of all installed packages and figure out the query to determine what list was install and what was automatically installed as a dependency. Then remove all and pull back to nothing which would show the file that are in /usr/local but no longer known by the pkg system.

Then knowing where those files came from those pkgs could be installed again, along with all of the list that you know were installed before, and that should bring things back up to a known good state too.

Oh, the BE will also have a copy of /usr/local too. So actually one could just completely recover to the last BE for /var/db/pkg and /usr/local and that seems like it would completely reset the clock for pkgs anyway. I think. Maybe. Seems plausible. I haven't tried it.

Thanks again. I should sleep before trying either, though.

Sleep is good.

hi...with pkg upgrade was update libxml2 and there is also pkg libxml2-core which is not in ports. How this hapenned, please?

hm. that's weird. prior to updating i created a mirrored encrypted swap on 2 intel enterprise SSDs

and after reobot it's gone completely from gmirror

why does it need mirrored? why not interleave

i just figured that mirrored was normal .. either way it didn't seem to survive reboot

maybe it's because i used gmirror create with gpt/device1 gpt/device2?

and you put the /dev/gmirror/ whatever in to fstab

using partition labels.. but that doesn't make sense. you'd think that would be a normal way to do it

yes

and did whatever for glabel to load on boot?

hm. now that i don't know but i'd assume yes considering my pools use partition labels as well.. but i'll double check that

on reboot /dev/mirror didn't even exist

i just recreated it manually with gmirror create and turned the swap on but obviously that isn't practical on every reboot

i don't think there is anything necessary for labels on boot is there?

if that's the case then why didn't it come up?

kern.geom.label.disk_ident.enable="0"

kern.geom.label.gptid.enable="0"

i stand corrected :/ seriously?

maybe make sure gmirror glabel are loading from loader.conf and see if that fixes it

yeah. they weren't. like i didn't even put that in there. they were in there by default

lol

but i can't reboot now to test it. i'll try it out again later. but yeah i'm sure those being set to 0 was the problem :/

hi! I just noticed that my system on boot complains about this: `WARNING: sysctl vfs.zfs.min_auto_ashift is deprecated. Use vfs.zfs.vdev.min_auto_ashift instead.'

is there a way for a userspace program to receive notification when somebody switches VT?

could anyone point me to what the solution is? I'm a total noob in FreeBSD

have you ever configured vfs.zfs.min_auto_ashift, e.g. in /etc/sysctl.conf ?

never

I do see the variable being referred to in the file

I guess I should change it there, right?

you would change the name of it (not the value, the value may remain the same)

makes snese

sense*

ty!

looks like the installer used to set that

ariadna: o/

great, rebooted and the warning has been cleared

As I understand it vfs.zfs.vdev.min_auto_ashift defaults to 12 now. Meaning that instead of editing the previous vfs.zfs.min_auto_ashift name that line can simply be removed entirely. I think. Pretty sure.

On 15.0, I don't see messages that pam_exec (with capture_stdout) previously (14.3) relayed to the (sshd/PAM) authenticating user.

I used to get (in ssh -vvv output) a "Packet Type 53" (SSH_MSG_USERAUTH_BANNER) with the message; now, nothing.

hm, I don't see pam_exec being configured to do anything on my system (but maybe looking in /etc/pam.d isn't enought)

No, this is a custom setup. I can send an informational message to some users based on conditions I choose at login.

But it's worked great in 14 (and I think 13 before that, but I can't recall when I set it up initially.) Now it's gone silent.

I'm thinking it might be related to some of the changes in sshd pre-authentication flow with the new sshd-auth binary.

hm, so you configured it for the auth service? I would ask if other pam modules do what they should, but I only see pam_unix configured for auth and have no idea how you would check that, for session you could check that pam_xdg set the XDG_RUNTIME_DIR environment variable