Bug #560
closed
loader.conf is empty after a firmware update.
0%
Description
On a full install the default /boot/loader.conf contains:
autoboot_delay="3" vm.kmem_size="435544320" vm.kmem_size_max="535544320" kern.ipc.nmbclusters="0"
After a firmware update, this file is 0 bytes.
Side note: wouldn't it be best to merge new changes in here instead of blowing away the existing file? I have a firewall that now must be run with DMA disabled from loader.conf and if I don't remember to touch /tmp/no_upgrade_reboot_required and fix loader.conf before reboot, it would trash the install.
Updated by Chris Buechler over 14 years ago
- Status changed from New to Feedback
should be resolved by:
https://rcs.pfsense.org/projects/pfsense-tools/repos/mainline/commits/7bd58f242717f23919756bbaa0a82cbcd2cf6daa
needs test
Updated by Jim Pingle over 14 years ago
Would we not need /boot/loader /boot/loader.rc and /boot/loader.4th - especially over a base OS version upgrade?
If we need special knobs in loader.conf we could script those into a post-upgrade command (but we rarely need something there anyhow).
Updated by Jim Pingle over 14 years ago
- Status changed from Feedback to Resolved
Looks like the latest fix from Scott is good:
Updated by Chris Buechler over 14 years ago
- Status changed from Resolved to New
this reportedly isn't fixed. http://forum.pfsense.org/index.php/topic,27257.0.html
Updated by Erik Fonnesbeck about 14 years ago
Is this still an issue on full installs? Note that there is a separate ticket for this on nanobsd.
Updated by Jim Pingle about 14 years ago
I believe it still is, as a VM I keep updated has an empty loader.conf when it should the default entries.
It's a different issue, though, in that I think somehow the builder is putting an empty loader.conf in the update, but the full/proper one is on the .iso and gets carried over from there.
Updated by Scott Ullrich almost 14 years ago
I just downloaded http://snapshots.pfsense.org/FreeBSD_RELENG_8_1/i386/pfSense_HEAD/updates/pfSense-Full-Update-2.0-BETA4-20101127-0055.tgz and do not see a /boot/loader.conf .. The issue seems resolved?
Updated by Scott Ullrich almost 14 years ago
- Status changed from New to Feedback
Updated by Jim Pingle almost 14 years ago
- Status changed from Feedback to New
I just tested it again, it's still getting wiped out somehow during the update process.
Updated by R M almost 14 years ago
I'm seeing a slightly different behaviour which may be unique to having serial console enabled after a an update.
After an update, the previous contents from loader.conf is replaced with just a single one line entry console="comconsole" which is checked from the interface to enable com output on a headless box.
Either way, the previous values added to loader.conf are not being carried over after an update.
Updated by R M almost 14 years ago
Apologies. Please disregard my previous comment.
Wrongly perceived the issue to be that values entered manually in loader.conf never get sucked back in after an upgrade when in fact that is the intended behaviour not to carry manual values over during updates. It has been conveyed to me by Jim P (http://redmine.pfsense.org/issues/1221#note-5) that it's not really a problem since manual changes are never supposed to go in loader.conf, but loader.conf.local instead since it was easier to handle it that way.
After having essentially posted a comment unrelated to the issue at hand, I'm providing this response to clear up any possible confusion that my last comment may have caused.
Updated by Jim Pingle almost 14 years ago
I discovered another vector for loader.conf being emptied - it's included in the kernel archives (kernel_Dev.gz, kernel_SMP.gz, kernel_uniprocessor.gz, kernel_wrap.gz, kernel_wrap_Dev.gz). So when a kernel is unpacked, the empty loader.conf from the kernel archive clobbers whatever is on the filesystem.
Updated by Scott Ullrich almost 14 years ago
- Status changed from New to Feedback
This should be resolved. I fixed the bug in the kernel upgrade code that was causing this.
Updated by Braden McGrath over 13 years ago
Just upgraded from 1.2.3 Embedded to 2.0-RC1 Embedded. Loader.conf was NOT blank, but the changes I had put in there were gone.
Knowing now that loader.conf*.local* is the preferred spot for customizations, this makes sense. Is there code in the flash/upgrade process to preserve the .local version? On embedded, you guys are disabling DMA on ATA/ATAPI. While this is admittedly safer, it's bad juju on an established Embedded machine that is already using DMA. Why? Because after upgrade, all of the packages get reinstalled... which causes a boatload of disk access, which is painful if it's still using PIO.
If the root of the bug is that loader.conf is empty after an upgrade, this bug is resolved in RC1, my loader.conf was "decustomized" but the sane defaults were in there.
Updated by Braden McGrath over 13 years ago
Just upgraded from 1.2.3 Embedded to 2.0-RC1 Embedded. Loader.conf was NOT blank, but the changes I had put in there were gone.
Knowing now that loader.conf.local is the preferred spot for customizations, this makes sense. Is there code in the flash/upgrade process to preserve the .local version? On embedded, you guys are disabling DMA on ATA/ATAPI. While this is admittedly safer, it's bad juju on an established Embedded machine that is already using DMA. Why? Because after upgrade, all of the packages get reinstalled... which causes a boatload of disk access, which is painful if it's still using PIO.
If the root of the bug is that loader.conf is empty after an upgrade, this bug is resolved in RC1, my loader.conf was "decustomized" but the sane defaults were in there.
Updated by Chris Buechler over 13 years ago
- Status changed from Feedback to Resolved
overwriting the changes is normal and unavoidable, just make sure your customizations are in .local and you can make that change prior to upgrading so it'll take effect after upgrading. .local is always retained and not modified.