[BUG] Upgrade /etc scripts when migrate from RELEASE.

[xbeaudouin]

[MANDATORY] Describe the bug [MANDATORY] When upgrading from 13.2-RELEASE to 14.0-RELEASE, there is scripts in /etc that signifiant changes. For example PAM.

The "upgrade procedure", which is like https://gist.github.com/cedwards/1e00c3d0aa6fbb14bc5b16fca8df0c35 don't fix /etc files...

Maybe this is related to #621 where documentation of upgrade is a bit.... "terse".

[MANDATORY] Bastille and FreeBSD version (paste bastille -v && freebsd-version -kru output) bastille -v: 0.10.20231013 freebsd-version -kru of the host 14.0-RELEASE 14.0-RELEASE 14.0-RELEASE freebsd-version -ru (jail) 14.0-RELEASE 13.2-RELEASE-p4

[MANDATORY] How did you install bastille? (port/pkg/git)

pkg

[optional] Steps to reproduce?

Create a bastillebsd with freebsd 13.2-RELEASE, freebsd-update -r 14.0-RELEASE of the host, and upgrade pkg. The bastille bootstrap 14.0-RELEASE to be ready.

Stop the jail, pkg edit TARGET fstab change the mount point from 13.2-RELEASE to 14.0-RELEASE

[optional] Expected behavior

Well have a better documentation on how to do the etcupdate (or equivalent) of the jail

[optional] Screenshots n/a

[optional] Additional context n/a

[cedwards]

Thanks for reporting this. I've been researching a solution to this but don't have a patch yet.

The fix for this will also include more documentation regarding the different jail types, when to use one over the other, and the upgrade processes for each.

[manufactory]

I thought I share my workaround for manually updating the /etc/ directories of jails

1. Fetch and extract src.txz to /usr/src
2. Build an etcupdate tarball from the source etcupdate build -d /tmp/etcupdate -s /usr/src/ 14.0-RELEASE-etcupdate.tbz2 Note: When building a tarball only a logfile is stored in the workdir (-d)
3. Test applying the update, i.e., do a dry run etcupdate -n -D $jail_root -t 14.0-RELEASE-etcupdate.tbz2 Don't make the mistake that I made: $jail_root is the jail's root directory, not its /etc :)
4. Run remove -n to apply the update

[prozorecJP]

I have played with this issue and noticed that step 3 and 4 mentioned by manufactory should be done within jail. It is safer to avoid mistake although we have to copy the tarball to the jail. And we should do etcupdate resolve at the end to check any conflict doesn't exist.

[manufactory]

I agree, doing steps 3 and 4 within the jail is safer. The tarball could also be nullfs mounted into the jail to avoid copying it.

[schmitmd]

My immediate issue was that the console command wouldn't work, so I couldn't look around like I expected. This forum post got me unstuck: https://forums.freebsd.org/threads/bastille-upgrading-jail-from-13-2-to-14-0-fails.91234/

Doing a full etcupdate is more prudent than just commenting out some opie stuff but I hope it may unstick some other folks like it did me.

[Toromtomtom]

Thank you @manufactory for documenting your workaround! It worked perfectly for me. I just added a step 5 to address the warnings produced by etcupdate in step 4:

etcupdate resolve -D $jail_root

will let you resolve any conflicts that occurred during merging the files (for example, if you---like me---already manually commented out the opie lines in the /etc/pam.d/* files).

[eoli3n]

I face the same problem, i can't run console subcommand anymore since freebsd 14.0 upgrade. I don't fully understand the workaround of @manufactory :

1. fetch from where ?

I agree, doing steps 3 and 4 within the jail is safer.

How to ? Is safer because $jail_root is then / instead of /usr/local/bastille/jails/$jail_name/root/ ? Should I use the new wrapped etcupdate subcommand ? https://github.com/BastilleBSD/bastille/pull/660

[Rodrigo-NH]

Should I use the new wrapped etcupdate subcommand ? #660

Hi eoli3n. Just to make sure, it's not a new subcomand if it's not merged. What I mean is nobody will give you advice probably (or will do it unprobably) at this point. More up to your own discretion. That being said, it was useful for me already for a few jails, including as helper to discover what etc 'version' jail relates to. Expect most hits counting to condition 'C4' there if you feed the right actual etc freebsd version to the command. I'm not used to 'etcupdate' command but I suspect using the etcupdate sub command will not block you of using the regular etcupdate command after. Maybe someone else can confirm this. At least until now I see the command will perform what you see by running the -D 'dry-run' option.