I will check this if i fount time. At the moment i still search core181 bugs with not booting systems…
This problem should now fixed in testing tree.
1 Like
I just hit this snag while trying the update.
Jan 3 21:55:17 robot pakfire: DECRYPT STARTED: alsa
Jan 3 21:55:17 robot pakfire: DECRYPT FINISHED: alsa - Status: 0
Jan 3 21:55:17 robot pakfire: PAKFIRE UPGR: alsa: Upgrading files and running post-upgrading scripts…
Jan 3 21:55:18 robot pakfire: PAKFIRE ERROR: Returncode: 1. Sorry. Please search our forum to find a solution for this problem.
/var/log/pakfire/update-alsa.log
mv: cannot stat ‘/tmp/asound.state’: No such file or directory
mv: cannot stat ‘/etc/asound.state’: No such file or directory
Other than that the upgrade looks good, reboots fine.
I had the same problem with the stable update. Uninstalling Alsa, updating and rebooting seems to have fixed it.
2 Likes
Yes, I can testify that I had the same issue. This solution solved everything 
.
1 Like
Glad to help. Credit goes to Man Grove in an earlier post.
I should add that I have not tested Alsa and I don’t know whether it still works or not. I’m not using it with this system.
1 Like
For what little I know, Alsa should ‘handle audio.’ If this is true, in my case, it’s probably used as an ‘addon dependency’ by my QEMU to emulate virtual audio. I can confirm that the virtual audio of my QEMU (including QEMU) works for me, but I’m waiting for suggestions from other users who use Alsa to test it more thoroughly. And, of course, I invite everyone to correct or clarify what I just wrote. I find Alsa installed. So, in my case, it’s definitely installed as a dependency for other packages.
7zip
guardian
htop
libvirt
mDNS-repeater
nfs
nmap
qemu
samba
spectre-meltdown-chec
speedtest-cli
stress
tor
transmission
wio
These are all the Addons that I have intentionally installed. In my case, Alsa must necessarily be a dependency of one of these packages. I am available for further tests or suggestions.
Alsa is a dependency for qemu so would be installed when installing qemu.
2 Likes
There never was a new 182 testing, was there?
Of course there were.
When any patches fixing things are committed into the repo then the Nightly Build process automatically runs a fresh build for all impacted versions - master and next for each architecture.
The status of these can be seen in the Nightly Builds section
https://wiki.ipfire.org/devel/nightly-builds
When those versions have been updated then doing a Testing upgrade uses the latest nightly build version. The version number for Testing always has a build number in it which is related to the last commit of the branch that applied when it was built.
You can also look in the changelog.txt file to see all the commits that are included in that build version.
Testing comes out of the master branch in the directory tree.
@arne_f made a lot of commit updates related to ALSA but it looks like those did not fix whatever the problem is that you have experienced.
2 Likes
OK; Pakfire hasn’t detected a new Testing since I did the upgrade where I reported the error. Is there a different way of getting new Testing releases? I can see the Alsa update (19->20) but I’m guessing I should have seen one system update where the broken liblzma got fixed, too, right?
You have to put your system back to the previous CU and then do the Testing update.
The simplest is to re-install and restore.
Generally on my testing vm I just clone a new vm from the previous stable version and do the latest Testing update on that.
You can also push the version number back by one and then re-do the upgrade but that can not be guaranteed to be fault free.
I have done that occasionally on my testing vm systems but I would never do it on my production system.
If you are on Core Update 182 Testing then edit the file
/opt/pakfire/db/core/mine
from 182 to 181
Then refresh the Pakfire Testing page and it should re-show the update from 181 to 182 and then re-do the update.
2 Likes
Oh, I was under the impression (meaning: I seem to remember that I have experienced it) that an upgraded Testing (e.g. 181->182) could receive additional Testing versions in the same version number, but that is not normally the case? If so, my misunderstanding, sorry.
No it can’t.
The version number in that mine file is just the general Core Update number. Once it is shown as being on Core Update 182 pakfire cannot differentiate between that version of 182 and a later build update.
No problems.
2 Likes
I issued touch /tmp/asound.state in the console and the update finally ran successfully!
1 Like
Thanks @sevenqueue - touch /tmp/asound.state fixed issue for me also
A reinstall and upgrade from 181->182 (not testing, stable) produced no errors. Also, an upgrade to 183 testing worked fine.
2 Likes