/boot/loader.conf overwritten on update without warning
-
2.0-BETA4 (i386)
built on Wed Sep 8 14:34:56 EDT 2010
FreeBSD 8.1-RELEASE
Platform nanobsd (2g)Every time I update to the latest snap my /boot/loader.conf gets overwritten. I understand that there may be necessary tweaks in there, or new functionality that I might miss otherwise, but it's quite a drag to have my customizations stomped on without any warning or notice.
Perhaps we could have a 'custom options' section at the end of the file that would survive an update and override conflicting options in the stock section?
Or if you want to be really fancy you could use a dialogue like apt-get uses, where the user would get a prompt that the file has been modified by a user or script, and then the user can choose to overwrite with the installer's version, keep the customized version, see a diff, or background pending further investigation.
At a minimum though, even just a little warning that 'the old version has been moved to /root/loader.conf.bak' would be nice.
-
It appears the boot loader also processes /boot/loader.conf.local which is apparently intended to hold "local" customisations and therefore should be preserved over upgrades.
-
That's perfect. Thank you.
-
/boot/loader.conf.local works, and overrides conflicting settings in /boot/loader.conf, but is deleted on firmware upgrade, and is therefore no more useful than editing /boot/loader.conf directly.
Any other suggestions?
-
/boot/loader.conf.local works, and overrides conflicting settings in /boot/loader.conf, but is deleted on firmware upgrade
deleted on firmware upgrade sounds like a bug to me.
But I suppose pfSense developers can do what they like. However it would be nice to have a documented way of preserving a set of boot loader commands over a firmware upgrade.
-
When you do an update on nanobsd installs, it is essentially copying a new installation to the drive, except that the contents of /cf are preserved since that is stored elsewhere on the drive. It is probably not copying your /boot/loader.conf or /boot/loader.conf.local to the new (upgraded) install.
-
@Efonne:
It is probably not copying your /boot/loader.conf or /boot/loader.conf.local to the new (upgraded) install.
I would posit from a user's point of view that it should do something to preserve those settings.
-
On a full install it will never overwrite or remove loader.conf.local, that is the correct way to set your own loader.conf settings on full installs.
The fact that nanobsd updates do is just a fact of how they function, as Efonne noted. It's not deleting that file, it's wiping out your entire partition by writing the update over it. There isn't an easy solution for that. I opened a ticket targeted post-2.0, though if someone wants to attach a patch to resolve we'll gladly get it committed.
http://redmine.pfsense.org/issues/892 -
I've added in some lines in the update code for nanobsd so that it copies /boot/loader.conf.local to the newly imaged slice during the update process:
https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/ba8e08709a2c4bbb35e1640d7ac744da7e58b6e5
Of course, for this to work you need to be updating from an image that has it. I would have included it in the post_upgrade_command file, but the directory name varies depending on which slice it is copying to (not sure if there is a reason for this, though).