Installing Bullseye over Buster on Elive Beta

Feellng adventurous today.
So I'm switching my (uptodate) Elive workhorse to Bullseye by changing all 'Buster' entries in '/etc/apt/sources.d/*list' to 'Bullseye'.
I did need to change the security entry from 'buster/updates' to 'bullseye-security'.

On top I had to upgrade my kernel to a 10.14.0-0-bpo2-amd64 one, to be able resolve dependencies. :thinking:

Will repost if the machine reboots properly (or not :face_with_head_bandage: )

Adendum

After a reboot everything was fine (as far as I can tell for now) except that the sound card wasn't recognized.
Doing ' killall pulseaudio; pulseaudio -k ; rm -r ~/.config/pulse/* ; rm -r ~/.pulse*'
and subsequently:
'pulseaudio --start'
and a reboot, solved that. :magick:

So now I'm running Elive on a fully upgraded Bullseye with no problems .... Yay!! :w00t:

A nice pro is that I now have the latest 'plank' version (0.11.89), which now has options to show a 'clock' as well as battery levels.

2 Likes

Subsequent encountered glitches:

  1. There is a slight error therein that in Buster '/usr/bin/python' points to 'python2' which got removed during the upgrade.
    A solution could be to re-install that version again or ...... install 'python-is-python3' from the repos to set python3 as the system default.

In the latter case I'm supposing there aren't any very old python scripts (specifically depending on python2.7) left on my system....there shouldn't be, AFAIK. :work:

  1. Unsurprisingly '/etc/elive-version' does not get updated to reflect the changes i.e 'buster' is still there, as is the old kernel bpo version.
  • Not a big deal. :smiley_cat:
  1. When doing 'apug' the package 'syasokoban' is kept back but is marked with 'upgradeable'.
    Doing a manual install shows that the version on the previous Buster is actually i386 where the Bullseye version is offered as amd64.
  • Manually installing the new 3.8.23+2.0.2+git1789c9ea6-7bullseye1 version offers to remove the previous 1386 version but throws a dpkg error (1) on 'syasokoban-data' and does not get installed.
    A subsequent 2nd install (now not requiring the removal of the old version anymore) does work as it should.
  • Maybe this could happen to other i386 apps too. :thinking:
1 Like

Same in my first attempt, I don't know what's the cause but I just wanted to go with a new ISO build for my next test (this requires a good amount of work so its not going to happen soon)

wohoo!! you found how to make it working :slight_smile:

sounds like we need a small howto about the steps to upgrade from buster to bullseye since more people can be interested doing so :slight_smile: sounds not hard and maybe all the packages has already been imported, e24+ should be more stable too

this is correct, this file is generated when the isos are built (based on data made on that moment) and updated when the installer is run, but not handled at all from packages (unlike /etc/debian_version for example which is), I'm not saying this is good or bad but simply it was not implemented like that, maybe it could be, but since your* elive is not installed in the common way (booting the iso and running the installer) I think is better to keep it this way (simply because the live mode and the installer has many dynamic features that adapts the resulting system to install, so this means more stable/featured, not necessarily but..)

not really, the updated version on bullseye includes a 64bit build but not on buster, not a big deal, but maybe tricky with apt as you have experienced (probably better to just doing a remove && install of the package itself with its -data too)

Feel motivated for a howto since is good to have? :slight_smile: I will help writing a cli combo from root for after the upgrade based on your notes:

killall -9 pulseaudio
rm -f /home/*/.config/pulse/cookie /home/*/.pulse/*
apr --purge syasokoban
api syasokoban python-is-python3
apug
# reboot your computer now

That about sums it up until now.

  • Even all other 3rd party stuff that I had installed like as flatpaks or from sourcecode/github in /opt/ or any other installer, still work fine.

In my case the bpo kernel came along in the backports repository, which I hadn't enabled yet (together with the 'security' repo) on the first run.
Anybody else can use them (correctly named) straight away and will have no need to change to another kernel first.

I used the 'apug' to update and upgrade ..... which I had to do a few times over (3 times I think) before all was done. I'm not in the clear whether ```'sudo apt-get full-upgrade'`` would actually solve stuff like the the sysokaban replacement....I personally doubt that totally deprecating and removing python2 in favor of python3 would be done that way. :thinking:

On a side note:
Applications I use like 'plank' and 'rofi' as well as 'vokoscreen-ng' work a lot better in their newly updated iterations.

plank in action, now including a built-in time- and battery-widget

and rofi (customized) in action

1 Like

There is another 'glitch' I haven't found the solution to (or at least what's causing it) yet:

  1. My keyboard 'mute' key mutes/un-mutes fine but the 'volume-up/down' keys do not get a binding to anything. :thinking:

Any pointers greatly appreciated.

And another one bites the dust! :w00t:

Never mind, I found the culprit and thus the solution.

In Keybindings 'XF86AudioRaiseVolume' and ' XF86AudioLowerVolume' are set through the 'setvolume 5 up/down' command respectively.
Apparently in the new version that syntax needs to be respectively:
'setvolume +5%' and 'setvolume -5%'

So changing those lines in '~/.e16/bindings.cfg' will bring about the needed functionality. :magick:

KeyDown    - XF86AudioRaiseVolume exec setvolume +5%
KeyDown    - XF86AudioLowerVolume exec setvolume -5%
KeyDown    - XF86AudioMute exec setvolume mute

On a side note:
The GUI app 'pavucontrol' has these commands set as they should as well as 'alsamixer' in the sense that they do control sound output levels as they should without any tampering

  • It looks like it's only the 'setvolume' command that hasn't been updated for the newer 'pulseaudio' which, essentially is part of the 'elive-tools' package and thus needs changing for Bullseye by its maintainer @thanatermesis or change the '/usr/share/e16/bindings.cfg' file or adding to the above file. :work:
killall -9 pulseaudio
rm -f /home/*/.config/pulse/cookie /home/*/.pulse/*
# until this is fixed upstream:
sed -i -e "s/5\ up/+5%/g; s/5\ down/-5%/g" ~/.e16/bindings.cfg
apr --purge syasokoban
api syasokoban python-is-python3
apug
# reboot your computer now

sounds like using the kernel from bullseye instead the one from buster should be a good step

nah, the sokoban you had installed was specifically on 32bit, that's why it was not upgraded probably, because you had a specific arch installed one

yeah I think so! i found many small glitches in buster :thinking: , I'm sure cairo-dock should work better too

hum, not really, you can use "+5%", "5%+" and also "5 up" (worked for me in cli right now), maybe you had some issue with your audio card or the volume settings before :thinking: , try again the old conf because I don't think is needed this change :thinking: setvolume (tool from elive) didn't changed that

~ ❯❯❯ setvolume 5 down
ERR: volume must be a number
~ ❯❯

Omitting the % sign works fine too, though.

As a thought:
Maybe the terms 'up'and "down" should be deprecated in 'bindings.cfg', thus avoiding any possible mishaps like mine.....Murphy's law!

Which is the one that is shipped with Elive by default.
At least I've never played or installed it.... it was just there.

nope... "down" is part of the setvolume arguments, it should be entirely accepted :thinking: as you can see in the line 730 of /usr/bin/setvolume

mmh, try to add a "set -x" as the second line of the tool and run it again from commandline to see "what" you have exactly before the ERR message, sounds like the command used for volume is different in your case from "setvolume -5%" and "setvolume 5 down" (they should be the same command used), I cannot test it because it works for me

Mmmh ok first try this: remove the quotes between "$action" in the lines 781 and 784, see if this solves the issue @triantares

That solves the issue totally.
I removed the quotes in both cases ..... where frankly I would never have put them there in the first place, come to think about it.

I have moved to bullseye. Things went OK but I had a few snags.

The names of the bullseye sources were not exactly correct in /etc/apt/apt.conf.d/debian.list it was 'bullseye-security' for debian-security and I had some other sources I used that I had to find the correct names.

The kernel is now "5.14.0-0.bpo.2-amd64".

But once I was ready to apug there were some problems. I had an error message from apt that said : "debhelper : Depends: dh-autoreconf (>= 17~) but it is not going to be installed".
I solved it by firstly do : apt upgrade --without-new-pkgs and then : apt full-upgrade dh-autoreconf+ (recursively)

I had many cycle of doing " apug"/reboot and finally it looks good.
I'm right on "bullseye".

But I have no sound and the recommended solution does not work for me.
after :

killall -9 pulseaudio
pulseaudio -k
rm -f /home/*/.config/pulse/cookie /home/*/.pulse/*
apr --purge syasokoban
api syasokoban python-is-python3
apug
reboot

I still have no sound. My audio is :

Audio:     Device-1: Advanced Micro Devices [AMD/ATI] driver: snd_hda_intel v: kernel bus ID: 03:00.1 chip ID: 1002:1637
           class ID: 0403
           Device-2: Advanced Micro Devices [AMD] Raven/Raven2/FireFlight/Renoir Audio Processor vendor: ASUSTeK driver: N/A
           alternate: snd_pci_acp3x, snd_rn_pci_acp3x bus ID: 03:00.5 chip ID: 1022:15e2 class ID: 0480
           Device-3: Advanced Micro Devices [AMD] Family 17h HD Audio vendor: ASUSTeK driver: snd_hda_intel v: kernel
           bus ID: 03:00.6 chip ID: 1022:15e3 class ID: 0403
           Sound Server: ALSA v: k5.14.0-0.bpo.2-amd64

I have no error messages in the syslog that I can associate with audio.
Some digging will be necessary :crazy_face:

:+1:

Here are the modules loaded for the sound on my laptop :

~/.config ❯❯❯ lsmod|grep snd
snd_hda_codec_realtek   159744  1
snd_hda_codec_generic    98304  1 snd_hda_codec_realtek
ledtrig_audio          16384  1 snd_hda_codec_generic
snd_hda_codec_hdmi     73728  1
snd_hda_intel          57344  0
snd_intel_dspcfg       28672  1 snd_hda_intel
snd_intel_sdw_acpi     20480  1 snd_intel_dspcfg
snd_hda_codec         176128  4 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek
snd_hda_core          110592  5 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek
snd_rn_pci_acp3x       20480  0
snd_pci_acp3x          20480  0
snd_hwdep              16384  1 snd_hda_codec
snd_pcm_oss            65536  0
snd_mixer_oss          28672  1 snd_pcm_oss
snd_pcm               143360  5 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_pcm_oss,snd_hda_core
snd_timer              49152  1 snd_pcm
snd                   110592  10 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek,snd_timer,snd_pcm_oss,snd_pcm,snd_mixer_oss

I moved to bullseye w/o upgrading the kernel. No issues. This MBA doesn't seem to have a functional audio card anyway (not even detected on macOS) so I didn't have that problem. Except I did have to delete debhelper to prevent it requiring upgrading one of its deps for some reason - upgrading it with api worked, but apug failed with requiring >= 17 of a dep, even though 20 was installed after the api???
Could be that I didn't upgrade the kernel tho.

All in all works fine!

It depends a bit on when you did this upgrade.
In the sense that as of today the elive repositories (including Bullseye) aren't being resolved i.e found.
So your problem might just be that and hopefully "repaired" in due time.

Considering the audio was a Debian problem .... maybe my first course of action could work for you (the script line is an interpretation of that by @Thanatermesis , which I personally haven't tested).
From the first post:

So do give that a go and wait out to when the Elive repositories come up again.

On a hopefully superfluous sidenote:

As mentioned before in the Howto, upgrading to Bullseye is 'testing' and not considered stable or safe ........ so expect bugs.

Could you be more explicit here?
'debhelper' is quite important.

And please keep a watchfull eye on upgrades requiring the elive repos.

It could be the kernel there, as I personally did a kernel upgrade to 5.10 (non bpo) on Buster before upgrading to Debian ...... which might be essential/helpful in hindsight. :thinking:

I found this info in the systemd log :

jan 06 17:34:33 EliveOrDead pulseaudio[24082]: Error opening PCM device hdmi:1: Argument invalide
jan 06 17:34:33 EliveOrDead pulseaudio[24082]: Caching failure to open output:hdmi-stereo
jan 06 17:34:33 EliveOrDead pulseaudio[24082]: Skipping profile output:hdmi-stereo+input:analog-stereo - will not be able to open output:hdmi-stereo
jan 06 17:34:33 EliveOrDead pulseaudio[24082]: Skipping profile output:hdmi-stereo+input:iec958-stereo - will not be able to open output:hdmi-stereo
jan 06 17:34:33 EliveOrDead pulseaudio[24082]: Looking at profile output:hdmi-surround
jan 06 17:34:33 EliveOrDead pulseaudio[24082]: Checking for playback on Digital Surround 5.1 (HDMI) (hdmi-surround)
jan 06 17:34:33 EliveOrDead pulseaudio[24082]: Trying hdmi:1 with SND_PCM_NO_AUTO_FORMAT ...
jan 06 17:34:33 EliveOrDead pulseaudio[24082]: card is not a string
jan 06 17:34:33 EliveOrDead pulseaudio[24082]: _toplevel_:2:0:Argument invalide
jan 06 17:34:33 EliveOrDead pulseaudio[24082]: /home/bt/.asoundrc may be old or corrupted: consider to remove or fix it
jan 06 17:34:33 EliveOrDead pulseaudio[24082]: function snd_config_hook_load returned error: Argument invalide
jan 06 17:34:33 EliveOrDead pulseaudio[24082]: hooks failed, removing configuration

and there seems to be a solution for Arch here: https://bbs.archlinux.org/viewtopic.php?id=259991

I just have to figure out a way to downgrade "alsa-ucm-conf" that seems to be "alsa-firmware-loaders" in debian and it should work. See also https://github.com/alsa-project/alsa-ucm-conf/issues/54

It looks like your HDMI sound is being enabled in place of your speakers (if this is a laptop) i.e connecting your TV might give you sound. :stuck_out_tongue_winking_eye:
This is clearly a 'pulse' mis-configuration, not a kernel-module or firmware issue.

Try using 'alsamixer' and the F6 to toggle the soundcard and enable the speakers....

NB.
Both 'solutions' you see there are more than a year old so should definitely NOT be considered valid anymore!

I can't remember if I removed debhelper or something that depended on it.
Either way, it's an Elive install I don't really care about anyway and nothing broke sooo

Thanks for the info, I didn't check the date !
I found a solution. I deleted my ~/.asoundrc and launched alsamixer.
I selected my sound card and exited alsamixer. But I couldn't save my setting with " alsactl store" since alsactl is in sbin and needs root permission. So I "sudo -i" and selected my card with alsamixer, exited and save the settings with "alsactl store" . By default alsactl save in /var/lib/alsa/asound.state .
You can then copy the file to your home in .asoundrc and take the ownership of the file.
Then I stopped pulseaudio : pulseaudio -k
and restarted it : pulseaudio --start -D

I now have sound but the cairo-dock sound applet was not showing it. I killed cairo-dock and restarted it and now the applet show my sound correctly.

All is OK now! And I will enjoy a fresh new Elive E16 with more recent stuff from bullseye.

Thank you! :+1:

The .asoundrc is overwritten at each logon and alsa sound is not restored.
I have write protected the .asoundrc file and
added "pulseaudio --start -D" in the ".e16/startup-applications.list".
That seems to fix it for the moment.

Regards,
Bernard