Re: PKGBASE in ZFS Boot Environments World

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.
>