loving my newly-discovered ryzen hibernation on my desktop pc

but when it restarts, I can't type umlauts and other european characters accents anymore

its easy enough to fix, but I don't really understand why these keyboard mappings should disappear

anybody know why?

`setxkbmap us -variant altgr-intl -option compose:menu` is what I need to re-run

ryzen hibernation?

[tj]: the zzz thing

it used not to work with my nvidia gpu + this mainboard + cpu

and now it does

and given how hot it is, I am very happy about this little win

oh you mean suspend to ram

dch: just move into the cellar

I guess so, is it not the same?

freebsd doesn't have hibernate support

does hibernation generally mean suspend to disk

yeah

huh til

also my cellar, it has a noisy datacentre in it

we did support bios driven acpi hibernation, but no one has shipped a bios with that for a long time

so there could have been some bios thing I'd never heard of

my replacement mainboard arrives today

then I really hope my server works again

and I can do the network fiddling again

I still haven't listened to the BSDcan power talk yet, its on my list

it doesn't cover this

hibernate is weird

I'm watching people debug linux hibernate in another irc channel and I'm always confused

linux and openbsd hibernate resume is mostly a normal boot

Do I need to build ubldr separately somehow?

RDMengineer: what do you find yourself needing ubldr for?

what might stop a box switching from kernel -> userland on boot?

it hangs at `start_init: trying /sbin/init` but does respond to ctrl/alt/del, but not ctrl-t or ctrl-c tho

dch: are you looking at the "wrong" console?

dch: some kernel/userland mismatch? Also try ctrl+t for SIGINFO. It may show you what's the process it hands on.

regis: in the interim I booted off usb and added a fresh pkgbase boot env

dch: But if it's kernel/userland mismatch and the problem is with /etc/ttys or such, ctrl+t likely also won't work.

I now have a slow process of moving bits & pieces back in hoping it all works

ctrl-t definitely hosed

Oh, you mentioned ctrl+t. Sorry.

dch: Without moving bits and pieces, maybe make installworld and make distribution would work if you're able to build sources fast. Also maybe chroot from USB-booted live system, which won't run init and will have tty stuff from the live system.

well the boot env all works now, so its a matter of reinstalling packages and shuffling configs over

oh and fixing the broken ipmi

on the upside, I am getting a lot of steps in going from cellar -> 3rd floor and back again, repeatedly

and its almost certainly userland/kernel mismatch, I can see sbin/init starting and crashing

No updates needed to update system to 14.3-RELEASE-p1 - yet uname -r even after a reboot returns 14.3-RELEASE - is this normal with binary updates?

Tabmow: yes there is a difference between userland and kernel

try `freebsd-version -kru` and `uame -a`

dch: so it's only if the patch contains a kernel update will it get reflected in uname I guess?

Tabmow: yeah that looks fine

Tabmow: the 2 vulns are xz (userland) and openssh (userland)

so no need to update kernel

I'm new to compiling. I noticed that FFMpeg has a cool encoder option on their Wiki trac.ffmpeg.org/wiki/Encode/AAC, the most HQ aac_at encoder. Now, n00b as I am, I was expecting that this aac_ac was available in FFMpeg graphical configure as an option. Nope. Joy

pike: that seems to rely on Audio Toolbox, which only exists on macOS?

could be, a bit unclear "normally available only on macOS" key is normally :)

ivy, I guess you are correct. No idea what their wiki means with 'normally' Noone would do this if it was possible to use aac_at with FFmpeg andrews-corner.org/qaac.html