Project

General

Profile

Bug #560

loader.conf is empty after a firmware update.

Added by Jim Pingle about 9 years ago. Updated about 8 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
04/30/2010
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.0
Affected Architecture:

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.

Associated revisions

Revision 5f36c658 (diff)
Added by Jim Pingle over 8 years ago

Rework this loader.conf changing code a bit. Might help with ticket #560

History

#2 Updated by Jim Pingle about 9 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).

#3 Updated by Jim Pingle about 9 years ago

  • Status changed from Feedback to Resolved

#4 Updated by Chris Buechler almost 9 years ago

  • Status changed from Resolved to New

#5 Updated by Erik Fonnesbeck over 8 years ago

Is this still an issue on full installs? Note that there is a separate ticket for this on nanobsd.

#6 Updated by Jim Pingle over 8 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.

#7 Updated by Scott Ullrich over 8 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?

#8 Updated by Scott Ullrich over 8 years ago

  • Status changed from New to Feedback

#9 Updated by Jim Pingle over 8 years ago

  • Status changed from Feedback to New

I just tested it again, it's still getting wiped out somehow during the update process.

#10 Updated by R M over 8 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.

Tested with http://snapshots.pfsense.org/FreeBSD_RELENG_8_1/amd64/pfSense_HEAD/updates/pfSense-Full-Update-2.0-BETA5-amd64-20110119-1309.tgz

#11 Updated by R M over 8 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.

#12 Updated by Jim Pingle over 8 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.

#13 Updated by Scott Ullrich over 8 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.

#14 Updated by Braden McGrath about 8 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.

#15 Updated by Braden McGrath about 8 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.

#16 Updated by Chris Buechler about 8 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.

Also available in: Atom PDF