Eoan re-release: Call for testing

[waveform80]

Does anything need to be done to make apt update / upgrade / dist-upgrade work correctly with this image? Every time I run them, I get nothing upgraded. Is it just because it has no updates thus far?

Should work out of the box, and being a re-spin it'll have all the updates for Eoan on that release date. I'd assume there'd be some updates appearing fairly shortly though! :)

I noticed that there is something about daily apt updates starting during the boot process - is it actually doing updates during that time? This might be why it never finds any updates when i check manually. (And I have been rebooting a LOT as I have been tinkering).

Ah, a few upgrade activities are enabled to run by default. The apt-daily systemd task is the first but by default this is only configured to download available update lists (i.e. "apt update"); you can configure this in "/etc/apt/apt.conf.d/10periodic". The next is unattended-upgrades which (if I recall correctly) is configured to install upgrades from the -security pocket by default (config in "/etc/apt/apt.conf.d/50unattended-upgrades"). So, if there's only been security updates so far they'll have been installed automatically (there'll be a log under "/var/log/unattended-upgrades" and presumably "/var/log/dpkg.log").

Dave Jones.

[waveform80]

<snip>
The good:
-Booted up with no problems. I changed the default password and did an apt update.
-All earlier USB issues are resolved in this version
-Network connectivity OK (Cable and wifi)
-Installed the ubuntu-desktop with no issues
-No problem detecting my TV screen resolution (a problem I had in the earlier release)
-Overclocking works fine

Glad to hear!

The less good:
-After rebooting, the system goes "black" for about a minute before the ubuntu login screen is displayed.
-No Bluetooth
-No sound

Unlike Raspbian, we don't enable bluetooth by default on the distro. There's a couple of reasons for this, the first being that "out of the box" it's basically a server distro (where one wouldn't expect to find a bluetooth stack by default). The second is that there's a trade-off on the Pi between bluetooth and the UART. On all bluetooth-capable Pis (3, 3+, and 4) the serial console defaults to the mini-UART which has a clock that varies with one of the processor clocks (VPU off the top of my head? Not sure). Anyway, that means that when it's enabled, that clock is locked to its lower speed (by the firmware).

For a server distro, serial is rather more important (out of the box) than bluetooth, hence we wanted to prioritize serial and an unlocked clock by default. However, that didn't quite work out as we ran into an issue with the disable-bt overlay so for the time being the hardware boot config is vaguely similar to Raspbian in that both serial and bluetooth are enabled (which implicitly locks the clock).

All of which is not to say we don't care about bluetooth; there was some work in this cycle to ensure the firmware was up to date enough to control bluetooth (and wifi) on all the supported models, including the Pi 4, and there's more work going on to make it trivial (one command) to switch between these various modes (serial+BT, BT only, serial only) but when that'll be finished I can't say yet.

I managed to get the sound to work by adding "dtparam=audio=on" and "hdmi_drive=2" to my config.txt
My workaround for the BT issue was to install pi-bluetooth (sudo apt-install pi-bluetooth) and reboot

I have been using James Chambers unofficial distribution of Ubuntu Server 18.04.3 for Raspberry Pi 4 for a long time on another SD card and everything works fine, even after upgrading it to 19.10 (https://jamesachambers.com/raspberry-pi ... nofficial/)

There's been some debate about whether we should just enable audio by default on the image. Again, it's not something that's necessarily typical "out of the box" on a server distro, but as far as I'm aware there's no trade-offs involved in simply enabling it (unlike the bluetooth case). Would be interested to hear of any counter examples though!

Dave Jones.

[waveform80]

<snip>

I did the same, but I added the text to the /boot/firmware/usercfg.txt file instead. Not sure what the difference is.

The Ubuntu boot config is basically split up three ways at this point. A rough description of each file is as follows:

• config.txt - as on Raspbian this is where everything starts. Unlike Raspbian, we consider this file "distro owned"; in other words, don't edit it because we may arbitrarily clobber its content from the package manager. In fact we already do in one circumstance, i.e. when upgrading to Eoan, although I've tried to be very careful to preserve user changes by migrating them to usercfg.txt in this case. Still, no promises!
• syscfg.txt - this gets included by config.txt; eventually the plan is to have a tool for trivially editing the contents of this file (preferably something runnable from cloud-init) and that'll be how most "typical" boot/hardware configuration gets performed; hence this file could be considered "owned by the system but potentially modified by tooling"
• usercfg.txt - this also gets included by config.txt and is where you can stick whatever boot config you like. Anything in here is safe from being clobbered by packages or tooling. This is partly provided as a migration target for things that users added to config.txt pre-Eoan, partly as a catch-all for cases that the tooling won't cover, and finally for users that are happy hacking on their own config and don't want any tooling / packages to mess with their changes.

This should all be formalized once I finish the aforementioned tooling! :)

Dave Jones.

[waveform80]

<snip>

Interesting - this does actually use those two pins for controlling the onboard RGB LED.
https://pinout.xyz/pinout/fan_shim

Ahh, that may well explain things. Odd choice given they're the serial pins by default (on Raspbian too!), but I guess using anything that doesn't have ALT functions would've extended the shim further down the header - trade-offs as ever.

It has been very hit/miss getting this thing working correctly on Ubuntu. I suspect that the friction fit header connection is a bit flaky. I still find that I have to "float" the board on the header pins to get it to boot sometimes.

I will try your suggestion of adding the enable_uart=0 line. Would this completely disable those pins then - even after booting (in a way that the RGB LED on the board may not work)? It has only worked intermittently for me thus far - perhaps because of this conflict.

It doesn't disable them, just leaves them as regular GPIO pins capable of being controlled like any other GPIO (when they're acting as serial pins they're in one of the "alternate" modes, probably ALT0; this is also what happens when I2C, SPI, and other buses are enabled: the relevant GPIO pins are just set to the relevant "alt" mode by the device-tree). All of which is a long-winded way of saying it should be fine with enable_uart=0 :)

The fan has begun to get a bit noisier than i would like, so I ordered a Flirc aluminum case for the Pi4 for a quieter passive cooling option, so this may all be moot, but there are some odd things going on with this little bugger (fan). (psutil doesn't seem to be able to read CPU temps on Ubuntu/RPi4 either, leading to control problems).

I should probably order one and have a play with it - but most likely after xmas! I'm not sure how psutil reads temps but reading /sys/class/thermal/thermal_zone0/temp seems to work happily (degrees C * 1000), which is one typical way of querying the system temp these days. So if you're using the automatic.py example from their repo, you could just replace the content of "get_cpu_temp" with something like:

Code: Select all

def get_cpu_temp():
    with open('/sys/class/thermal/thermal_zone0/temp', 'r') as f:
        return int(f.read()) / 1000

And that should work. I might pop them a PR for that as it might be possible to eliminate the dependency on psutil (which isn't apt packaged if I recall correctly).

Dave Jones.

[spiff72]

<snip>

Interesting - this does actually use those two pins for controlling the onboard RGB LED.
https://pinout.xyz/pinout/fan_shim

Ahh, that may well explain things. Odd choice given they're the serial pins by default (on Raspbian too!), but I guess using anything that doesn't have ALT functions would've extended the shim further down the header - trade-offs as ever.

It has been very hit/miss getting this thing working correctly on Ubuntu. I suspect that the friction fit header connection is a bit flaky. I still find that I have to "float" the board on the header pins to get it to boot sometimes.

I will try your suggestion of adding the enable_uart=0 line. Would this completely disable those pins then - even after booting (in a way that the RGB LED on the board may not work)? It has only worked intermittently for me thus far - perhaps because of this conflict.

It doesn't disable them, just leaves them as regular GPIO pins capable of being controlled like any other GPIO (when they're acting as serial pins they're in one of the "alternate" modes, probably ALT0; this is also what happens when I2C, SPI, and other buses are enabled: the relevant GPIO pins are just set to the relevant "alt" mode by the device-tree). All of which is a long-winded way of saying it should be fine with enable_uart=0

The fan has begun to get a bit noisier than i would like, so I ordered a Flirc aluminum case for the Pi4 for a quieter passive cooling option, so this may all be moot, but there are some odd things going on with this little bugger (fan). (psutil doesn't seem to be able to read CPU temps on Ubuntu/RPi4 either, leading to control problems).

I should probably order one and have a play with it - but most likely after xmas! I'm not sure how psutil reads temps but reading /sys/class/thermal/thermal_zone0/temp seems to work happily (degrees C * 1000), which is one typical way of querying the system temp these days. So if you're using the automatic.py example from their repo, you could just replace the content of "get_cpu_temp" with something like:

Code: Select all

def get_cpu_temp():
    with open('/sys/class/thermal/thermal_zone0/temp', 'r') as f:
        return int(f.read()) / 1000

And that should work. I might pop them a PR for that as it might be possible to eliminate the dependency on psutil (which isn't apt packaged if I recall correctly).

Dave Jones.

I added the enable_uart=0 line to my syscfg.txt file, and it does appear that this fixed the boot issues. I still need to do additional testing to see if the LED functions now, but at least I have a reliable boot on this thing when the fanshim is installed. Thank you!!

This is the output I see for psutil.sensors_temperatures():

Code: Select all

ubuntu@ubuntu:~/fanshim-python/examples$ sudo python3
Python 3.7.5 (default, Nov 20 2019, 09:21:52) 
[GCC 9.2.1 20191008] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import psutil
>>> psutil.__version__
'5.5.1'
>>> psutil.sensors_temperatures()
/usr/lib/python3/dist-packages/psutil/_pslinux.py:1223: RuntimeWarning: ignoring FileNotFoundError(2, 'No such file or directory') for file '/sys/class/hwmon/hwmon1/temp1_input'
  RuntimeWarning)
/usr/lib/python3/dist-packages/psutil/_pslinux.py:1223: RuntimeWarning: ignoring FileNotFoundError(2, 'No such file or directory') for file '/sys/class/hwmon/hwmon1/temp2_input'
  RuntimeWarning)
/usr/lib/python3/dist-packages/psutil/_pslinux.py:1223: RuntimeWarning: ignoring FileNotFoundError(2, 'No such file or directory') for file '/sys/class/hwmon/hwmon2/temp1_input'
  RuntimeWarning)
/usr/lib/python3/dist-packages/psutil/_pslinux.py:1223: RuntimeWarning: ignoring FileNotFoundError(2, 'No such file or directory') for file '/sys/class/hwmon/hwmon2/temp2_input'
  RuntimeWarning)
{}
>>> 

It seems to be looking at the wrong locations for the temperatures.

[spiff72]

NOTE: I also confirmed that the automatic.py script works correctly now in combination with the edit you showed (i have included that already based on my research to see if it helped). The LED on the fanshim also reflects the temperature as it should.

Unfortunately, I couldn't get my modified version of the automatic.py script to work with ubuntu (it worked great under Raspian). I had created some code in that same script that lit up an 8-pixel neopixel strip like a thermometer. I get errors that I will troubleshoot later:

Code: Select all

Traceback (most recent call last):
  File "automatic-new.py", line 11, in <module>
    import neopixel
  File "/usr/local/lib/python3.7/dist-packages/neopixel.py", line 34, in <module>
    from neopixel_write import neopixel_write
  File "/usr/local/lib/python3.7/dist-packages/neopixel_write.py", line 15, in <module>
    from adafruit_blinka.microcontroller.bcm283x import neopixel as _neopixel
  File "/usr/local/lib/python3.7/dist-packages/adafruit_blinka/microcontroller/bcm283x/neopixel.py", line 3, in <module>
    import _rpi_ws281x as ws
ModuleNotFoundError: No module named '_rpi_ws281x'

[leggazoid]

https://github.com/TheRemote/Ubuntu-Ser ... Updater.sh

WiFi 5ghz fix

# Fix WiFi
sed -i "s:0x48200100:0x44200100:g" /lib/firmware/brcm/brcmfmac43455-sdio.txt
# Disable ib_iser iSCSI cloud module to prevent an error during systemd-modules-load at boot
if [ -f "/lib/modules-load.d/open-iscsi.conf" ]; then
GrepCheck=$(cat /lib/modules-load.d/open-iscsi.conf | grep "#ib_iser")
if [ -z "$GrepCheck" ]; then
echo "Fixing open-iscsi ..."
sed -i "s/ib_iser/#ib_iser/g" /lib/modules-load.d/open-iscsi.conf
sed -i "s/iscsi_tcp/#iscsi_tcp/g" /lib/modules-load.d/open-iscsi.conf
systemctl restart systemd-modules-load
fi
fi

[spiff72]

Does this mean we can download the update script linked above to fix 5ghz wifi (among other things)?

[spiff72]

This thread seems to have gone silent.

Is there anything that I need to do to keep this "fixed" version current? I see that there is a 19.10.1 version available here:
https://ubuntu.com/download/raspberry-pi

My about screen still shows 19.10 (no .1) - but the software updater reports that I am up to date.

Do i need to start over from scratch to get onto the "normal" track again? Or is this one really up to date? I have gotten a few updates via apt update/upgrade etc.

Thanks!

[washran]

Is anybody noticing systemd-modules-load fails to load? See below...

Dec 21 23:14:07 ubuntu systemd[1]: systemd-modules-load.service: Main process exited, code=exited, status=1/FAILURE
-- Subject: Unit process exited
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--
-- An ExecStart= process belonging to unit systemd-modules-load.service has exited.
--
-- The process' exit code is 'exited' and its exit status is 1.
Dec 21 23:14:07 ubuntu systemd[1]: systemd-modules-load.service: Failed with result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--
-- The unit systemd-modules-load.service has entered the 'failed' state with result 'exit-code'.
Dec 21 23:14:07 ubuntu systemd[1]: Failed to start Load Kernel Modules.
-- Subject: A start job for unit systemd-modules-load.service has failed
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--
-- A start job for unit systemd-modules-load.service has finished with a failure.
--
-- The job identifier is 6509 and the job result is failed.
Dec 21 23:14:07 ubuntu sudo[14666]: pam_unix(sudo:session): session closed for user root

[washran]

I upgraded to Focal Fossa. The systemd-modules-load works fine. I know this is a testing system. I cannot get the wifi to work right without it petering out. I tried the wifi fix. Still not correcting the issues. I guess we need a Focal Fossa group?

[phase]

@waveform80

do you foresee a desktop image released in the future
how long away if and when ...do you think this will be...???

[leggazoid]

Does this mean we can download the update script linked above to fix 5ghz wifi (among other things)?

The script is for a home-brew version of Ubuntu 18.04 that works on a Raspberry Pi 4. The individual(s?) working on this seem to have worked out more details than the official ubuntu 19.10 team. If only the official team would examine all the fixes and duplicate those with the new kernel, maybe that sounds easier than it actually is.



Here are the instructions for using the script with a 4.19 kernel.

The build script is meant to be ran in a *throwaway* Ubuntu 18.04.3 Virtual Machine (VM). Here are the reasons you shouldn’t ignore this:

Absolutely no steps have been taken to make the process “secure” or “safe” for your main machine
It assumes the home directory is safe to build in (it’s not on a main system)
It installs hundreds of development packages that you only need to build the image (would bog down a main system)
It chroots into at least 4 different images during the build and chroots leak (causing instability/security concerns)
If things go wrong with the type of commands used in the script your system can get borked *real quick* (like instantly)
Now assuming you have your fresh throwaway VM ready download the build script:

cd ~
wget https://raw.githubusercontent.com/TheRe ... el64bit.sh
chmod +x BuildPiKernel64bit.sh
Now is a good time to read through the build script to understand what it is doing. It will download several images and update them in a chroot and then extract the firmware. It then sets up all of the changes/fixes in the target image.

Once you feel you are ready to proceed run the build script with:

./BuildPiKernel64bit.sh
The script’s final output will be “ubuntu-18.04.3-preinstalled-server-arm64+raspi4.img” along with the xz compressed version and an updates.tar.xz file which is meant to bring a normal 18.04.3 installation up to date.

[leggazoid]

Does this mean we can download the update script linked above to fix 5ghz wifi (among other things)?

''

Try setting country code in /etc/wpa_supplicant/wpa_supplicant.conf

mine has this line...

country=US