From Newsgroup: muc.lists.freebsd.stable

We know that 'pkg delete -afy' will delete all PKGBASE packages without asking ... but that will also render ZFS Boot Environments USELESS as there is no loader(8) anymore to show the ZFS boot menu for BE selection.

OK ls boot
boot
d zfs
d efi
loader.conf
entropy
d firmware

My proposal - always keep a MINIMUM set of files allowing to show loader(8) boot menu - so anyone - even after wiping their FreeBSD system with pkg(8) - will be able to boot into other backup ZFS Boot Environment.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable

what would be flag for "extra clean force"?
currently deleting all still leaves files and dirs around
if pkg db is on same root, that as well
i'm sure this is an edge case and can be done with (*shudder*) rm -fr rootfspath but maybe we need it
when done in a live system, that option would leave fs clean as a whistle with only kernel running and whatever userland keeps running with carpet being pulled out from under it
the -f issue is here only because some admins used it to clean ports off and now if they automatically pull that thing out of their brain they nuke their system for real. fixing that would pray for open ssh and try to write binary somewhere with running shell, kind of makeshift xmodem. i never tried that
note that accidents like this isn't really a pkg issue but unsure. at one thing we need to prevent accident. at other thing, we need to allow it
i recall some linux distro having safeguards where you need to write long line into package manager. after you typed it in, you were left with totally clean machine. it had that way chosen probably because it's rarely used. and you can't simply y, enter through it
yes, you should not come to root shells if you do this but humans are humans
so i propose a special mode that allows full nuke
what would be excluded without it, no idea. remember, rescue is hard. i recently thought about it. i did read about fs i inside loader, fs inside kernel i already knew. and tried, out of curiosity, to run rescue for rescue. had that problem with no vi. bug in manpage even. had to manually create var for vi. lot of errors about missing files, oh and had to take termcap for which i had to reboot since i wasn't actually in trouble
in the end i was able to write support scripts, have var.tar as no mtree defs nor binary. no grep, had to sh -c 'while read l; do case $l in $0) echo $l;; esac; done' for shell glob grep surrogate. and number of other hacks. tried to pretend i'm in actual trouble
rescue comes from old age and has many old tools on. tho, there's limit on amount of tools that fit before it becomes just a full system
has anyone recently tried to run rescue "bare"? also maybe officially put it into efi loader or at least have option for it
that'll bloat up loader and kernel tho. even if packed. maybe people with small ram are in trouble. but people with efi booted machines are fine. as long as they didn't have esp rw mounted
i have minimal linux experience but didn't they have things like that
if that could be solved, this solves the pkg issue too, maybe, just maybe
what does anybody think?
the discussion of "fuller" rescue did at least once pop up in some ml already as changes piss people off, i see this as being offered as special efi loader binary with fses in. i never tried if it works. kernel in loader. root in kernel. both lzma'd as even embedded cpus can uncompress nowadays. my test setup was in h3 actually
On October 16, 2025 11:04:55 AM GMT+03:00, vermaden <vermaden@interia.pl> wrote:

We know that 'pkg delete -afy' will delete all PKGBASE packages without asking ... but that will also render ZFS Boot Environments USELESS as there is no loader(8) anymore to show the ZFS boot menu for BE selection.

OK ls boot
boot
d zfs
d efi
loader.conf
entropy
d firmware

My proposal - always keep a MINIMUM set of files allowing to show loader(8) boot menu - so anyone - even after wiping their FreeBSD system with pkg(8) - will be able to boot into other backup ZFS Boot Environment.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable

Found a way to overcome that limitation ... by creating a separate /RESCUE (not /rescue) dir with copy of /boot and pkg-static(8) command.

That way one can restore /boot and reboot into different ZFS Boot Environment.

Details here in the 'Additional Independent Rescue' section at the end:
- https://vermaden.wordpress.com/2025/10/20/brave-new-pkgbase-world/

Regards,
vermaden



Temat: PKGBASE in ZFS Boot Environments World
Data: 2025-10-16 10:04
Nadawca: "vermaden" &lt;vermaden@interia.pl>
Adresat: freebsd-stable@FreeBSD.org; freebsd-pkgbase@FreeBSD.org;

We know that 'pkg delete -afy' will delete all PKGBASE
packages without asking ... but that will also render
ZFS Boot Environments USELESS as there is no
loader(8) anymore to show the ZFS boot menu for BE
selection.

OK ls boot
boot
d zfs
d efi
loader.conf
entropy
d firmware

My proposal - always keep a MINIMUM set of files allowing
to show loader(8) boot menu - so anyone - even after wiping
their FreeBSD system with pkg(8) - will be able to boot into
other backup ZFS Boot Environment.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable

i have been playing too
http://ketas.si.pri.ee/misc/recovery.1760980081.sh
On October 20, 2025 5:05:27 PM GMT+03:00, vermaden <vermaden@interia.pl> wrote: >Found a way to overcome that limitation ... by creating a separate /RESCUE (not /rescue) dir with copy of /boot and pkg-static(8) command.

That way one can restore /boot and reboot into different ZFS Boot Environment.

Details here in the 'Additional Independent Rescue' section at the end:
- https://vermaden.wordpress.com/2025/10/20/brave-new-pkgbase-world/

Regards,
vermaden

Temat: PKGBASE in ZFS Boot Environments World
Data: 2025-10-16 10:04
Nadawca: "vermaden" &lt;vermaden@interia.pl>
Adresat: freebsd-stable@FreeBSD.org; freebsd-pkgbase@FreeBSD.org;

We know that 'pkg delete -afy' will delete all PKGBASE
packages without asking ... but that will also render
ZFS Boot Environments USELESS as there is no
loader(8) anymore to show the ZFS boot menu for BE
selection.

OK ls boot
boot
d zfs
d efi
loader.conf
entropy
d firmware

My proposal - always keep a MINIMUM set of files allowing
to show loader(8) boot menu - so anyone - even after wiping
their FreeBSD system with pkg(8) - will be able to boot into
other backup ZFS Boot Environment.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2