/boot/loader.conf.local replaced during Upgrade to 2.6
-
I just upgraded to 2.6. I believe I was on 2.5.4 before...
I am using a Zotak box that has a realtek card in it. I had to get the realtek drivers updated to improve stability. This required updating the /boot/loader.conf.local to include a line "if_re_name="/boot/modules/if_re.ko"
When I upgraded to 2.6, the /boot/loader.conf.local file was replaced it seems, as it doesn't reference the realtek driver any more, and my stability problems came back.
Not sure where to put this, topic.
I'm thinking there could be several potential improvements around this:
- do not replace user-updated /boot/loader.conf.local files
- parse /boot/loader.conf.local and keep lines that are not part of default instillation.
- give users the option of what parts of /boot/loader.conf.local to keep when upgrading
- include the updated realtek drivers and such within the standard version.
Thanks,
-
@edhayes3 said in /boot/loader.conf.local replaced during Upgrade to 2.6:
I just upgraded to 2.6. I believe I was on 2.5.4 before...
I assume it was 2.5.2? (2.5.4 doesn't exist!) You can check the upgrade log in /conf.
loader.conf.local should never be removed. There are a few things that can be removed from it because they cause conflicts with the values in loader.conf. However that isn't one of them.
You still have the file? And it has other values in it still?
Steve
-
@stephenw10 Maybe it was 2.4.5? I don't upgrade too often because of issues like this. Doesn't really matter I don't think, it's not too important to my problem.
That's really the only important thing in the file. I didn't add anything else. So whatever else is in there is by default.
-
The .local file doesn't exist by default it has to be added. It's there specifically to be retained across upgrades and config changes when the main loader.conf file might be overwritten.
So what do you have in it currently?
Steve
-
kern.cam.boot_delay=10000 if_re_load="YES" if_re_name="/boot/modules/if_re.ko"
-
I assume you added it back then. What I meant was, what was left in the file after upgrading?
-
@stephenw10
This was the file after upgrade:kern.cam.boot_delay=10000 if_re_load="YES"
-
Hmm, that should be sufficient anyway. I never bothered specifying the module name when I tested it previously. But I wouldn't have expected that to be removed.
The module/pkg itself would need to be re-installed though.Steve
-
@stephenw10 I still had problems. As suggested, needed to reinstall the drivers. Ran each of these commands from the UI.
fetch -v https://pkg.freebsd.org/FreeBSD:12:amd64/latest/All/realtek-re-kmod-196.04.txz pkg install -f -y realtek-re-kmod-196.04.txz
-
And that worked OK? You're back up and running?
-
@stephenw10 Yup.
Any chance the Realtek drivers can be added to the standard builds? I saw when 2.6 was built it was not stable with the drivers, which is why they were not included. but with so many people using realtek hardware, seems it would be a great addition/requirement. I think the worst part is that when instability happens, it's difficult/annoying for someone to diagnose if they have not been through this already. A real deterrent to firstcomers. It also deters people from upgrading. Upgrading is so important for security updates, it should be as trouble-free as possible.
-
It wasn't that it's unstable in 2.6 it's that the drivers stopped building in our build infrastructure for some reason and the errors were preventing snapshots being built. Since the only thing we've ever sold that has Realtek NICs (apu1) runs just fine with the default driver the easiest thing was to remove it at that point. I can ask about adding it back.
Steve