Package reinstallation is a start, pray and hope-thing…
-
+1
-
same problem
-
+1
Roy…
-
It's not really in the background, it's on the console. Watch the monitor or serial console for output. It's all there.
That change will probably not be reverted because that was the only way to solve some other package upgrade issues (like if you're coming from 1.2.3 and have vmware-tools installed, you have to reinstall packages there or you'll get a kernel panic.)
The real issue is when a specific package fails to reinstall. The package needs fixed more than the methodology, though perhaps a method to force the package reinstall from the GUI might also be helpful, if the "reinstalling in the background…" message sticks around too long.
-
Having a serial console open is not really an option, i could in the same way post my login and passwd at facebook, or not? ;) (being a bit sarcastic, please don't feel offended!)
I understand that certain things are only resolvable that way, but other thing would be a disable automatic reinstall, so i can reinstall via gui. That would be much better. At the moment i wait for complete reinstall, then i do the same task another time via gui because of that really unstable thing. What i can tell, at the moment it brings more problems than help. Its somewhat strange to float that way in outer space…
Would it be possible to redirect the install-output completely to the systemlog maybe? What about a special package-reinstall-log? Would that be an option?
-
I have no idea why you're trying to trying to equate watching your server's own serial console with passwords. It makes no sense.
The package reinstall progress is printed to the console when it happens at boot time, so if you want to see that output, you have to watch your console. If it's a full install, that means a monitor. If it's an embedded install, that means a serial console.
You do realize that all of this is really only a problem when upgrading between snaps, and that by the time the release rolls around, you aren't likely to hit this again (if at all) because you'll be running a release image for months (years?) after that point?
The effort it best spent on tracking down the actual packages that are failing and then fixing them, not trying to make a configurable option for something that will be a non-issue later on.
-
You're right, between snaps. But at the moment i upgrade day by day and its a big problem! The appliance is located at the othe rend of the house, i'm happy when i don't have to run the whole way down to make the update. Maybe its my lazyness, but is it such a bad wish to have some kind of logs?
The feature really cuts off some important info which i and maybe package-devs need! If some logs were generated, this fred would not exist. I'm really sorry if i have offended you! That wasn't the intention. But such logs are necessary.
thanks
-
Today i had the time to log the whole package-reinstall directly and saw several things:
Some packages are reinstalled more than 3 times! And not all packages were reinstalled.
After a while at the console a message appears "Bootup complete". I assume that the reinstallation is finished too. But at the webgui the "Package installation…" still is active after a long while. When i reload the pages, every time that thing pops up.Hope that helps anyone!
edit: the "clear_subsystem_dirty('packagelock');" didn't help, package-lock was active till reboot.
Here is the whole serial log:
-
No, you're seeing a side effect of how the messages are printed. After a package is reinstalled, the old text is "redisplayed" which on serial doesn't quite translate (especially in a log file).
So it's more like this:
Installing MAC-to-Vendor…
Cleaning up... Beginning package installation for MAC-to-Vendor...Installing OpenVPN Client Export Utility
Cleaning up... Beginning package installation for MAC-to-Vendor...
Cleaning up... Beginning package installation for OpenVPN Client Export Utility...Installing squid3
Cleaning up... Beginning package installation for MAC-to-Vendor...
Cleaning up... Beginning package installation for OpenVPN Client Export Utility...
Cleaning up... Beginning package installation for squid3...Installing TFTP
Cleaning up... Beginning package installation for MAC-to-Vendor...
Cleaning up... Beginning package installation for OpenVPN Client Export Utility...
Cleaning up... Beginning package installation for squid3...
Cleaning up... Beginning package installation for TFTP...Installing Unbound
Cleaning up... Beginning package installation for MAC-to-Vendor...
Cleaning up... Beginning package installation for OpenVPN Client Export Utility...
Cleaning up... Beginning package installation for squid3...
Cleaning up... Beginning package installation for TFTP...
Cleaning up... Beginning package installation for Unbound...But none of that is the problem. The real problem is here:
Fatal error: Cannot redeclare mactovendor_custom_php_install_command() (previously declared in /usr/local/pkg/mactovendor/mactovendor.inc:30) in /usr/local/pkg/widescreen/widescreen.inc on line 48Which was a problem with the widescreen package. The creator of the package reused functions from another package and forgot to rename them. Easy mistake (I've done it myself before). I pushed a fix here:
https://rcs.pfsense.org/projects/pfsense-packages/repos/mainline/commits/998bad0f00846f5edbb71e49461b6c07d47c43bcSo that shouldn't be an issue the next time you update.
-
ah, ok. Thanks much for the clarification! I'll see the next update what happens.
-
So now 3 updates are made and with all updates its the same thing: only some packages are reinstalled, some not. Which ones get reinstalled, varies.
Over all its a real mess.
Having a remote console doesn't help much, it gets filled with "Bump shed buckets to 64 (was 0)", so even when i'm online not one message from any package is shown. At the system-log i see some packages get reinstalled, but not all. But i have some messages like this one appearing:kernel: pid 25893 (php), uid 0: exited on signal 11 (core dumped)
The "packages are being reinstalled…"-message never disappears.
The "clear_subsystem_dirty('packagelock');" doesn't work. Only a reboot helps.
