Problems after Core Update 158 -> 160

Hello firewall friends.

I made the update in two steps. At first from 158 → 159 then reboot, then from 159 → 160 and reboot.
After that I saw that the WUI still told me to be on 159.
I found this trouble topic
I had no DNS problems as in the topic above and after

pakfire update --force
pakfire upgrade
reboot

The WUI shows now 160 but during the boot process this is shown:
[ … ]
Starting Squid Proxy Server… [ FAIL ]
[ … ]
Starting ALSA…
alsa-lib parser.c:2372:(load_toplevel_config) Unable to find the top-level configuration file ‘/usr/share/alsa/ucm2/ucm.conf’.
alsa-lib main.c:1405:(snd_use_case_mgr_open) error: failed to import hw:0 use case configuration -2

For me it seems as if the update came not in the planned sequence. All the installed add-ons were already updated before the last ‘pakfire upgrade’ was executed.

Now the problem is that the Squid web proxy isn’t reachable on port 800. The alsa update to version 1.2.5.1 seems to make problems, too. But since I don’t use any sound-services it isn’t so important (at least for me).

What should I do to resolve the two failures? Anyone can help me?
I am thinking about to do a rollback to core 158.

Regards, Marc

For the phenomenon that the Squid web proxy does not start at boot time I am not alone: Forum topic1 (since 29 Mar core 155) and topic2 (since 29 May core 156).
I probably didn’t noticed this because my IPFire-server was never rebooted after the update to core 158 for 77 days. Don’t know why @ Neopegasus has a schedule reboot ones a week (maybe he thinks it is a good idea - but that’s only neccessary for a Windoof server :smile: )
Yesterday I started the web proxy manually via the web GUI. So this problem is solved for me.

Now there is still this ALSA startup failure. Maybe I just disable it completely.
Please: I wish that the web GUI gets an entry for ALSA on page Status->Services under ‘Addon - Services’ to do this as easily as for CUPS.

1 Like

I fixed the startup script /etc/init.d/alsa and added the option ‘-U’ for alsactl restore

@mroland, hi Mroland, i have been using reboot once a week because in my field of work ( NVR) they thend to get buggy and strange behavior after like 5 to 6 months working 24/7, a lot of times i need to go to clients ( if they are to afraid to do it) to just perform a reboot, so whenever it was possible i had program a one’s a week reboot and the system turn to a drop forgot system, meaning they never called you for problem with buggy system.

All in all when I move frome tomato router( was also getting buggy after 1 month) to Ipfire i just kept that way of setting.

Thanks for advice, I never tried my Ipfire running from constantly to see if it gets buggy, but ass i said it’s just a habits, anything i install that stay 24/7 and have the option of reboot himself at least ones a month get it activated :slight_smile:

Best regards

Neopegasus

In another thread
https://community.ipfire.org/t/web-proxy-not-starts-itself/6443/2
you ask how to raise this to the developers.

Normally the best way is to raise a bug.

https://wiki.ipfire.org/devel/bugzilla

In this case I believe that a bug has already been raised on this topic.

https://bugzilla.ipfire.org/show_bug.cgi?id=12623

If this bug is covering your issue then please add your information to the bug. If it is not covering your issue then please raise a new bug as per the wiki link above.

Your IPFire People email address and password work on the IPFire Bugzilla to authorise your logon.

When you want to provide the log info I would suggest first getting your IPFire to have the problem, ie squid not starting at reboot and then copying the required log info. That way the required info will be near the end of the log that you provide.

I suspect the required logs will be /var/log/messages and /var/log/squid/cache.log.

2 Likes