How much free space is needed in the microSD to do this test upgrade?
Thanks.
Havenāt taken a precise measurement. You want 1GB free to play it safe.
Hi,
I have a Vero4K and tried updating from the 18.8-157 nightly.
Before updating I commented out the nightly source to be on the safe side.
The sources I used are here.
I then updated via sudo apt-get update && sudo apt-get dist-upgrade (log).
The Vero4K boots up and I can watch videos (even though the video library is about 2 months old).
But basically all addons are not working (eg. YouTube and Twitch) and I think it is because it is of python2/3 differen between Kodi 18 and 19.
So I tried using the nightly again and I have broken packages (log).
Either my system is now broken or this is anticipated?
The Kodi Log from that boot is here.
As far as I can tell is that my suspensions were correct about python2/3.
So basically my questions are:
- Is it expected that the nightly is not compatible?
- Are my packages broken?
- Is there a way to run python3 addons (there are errors with the kodi package six)?
Nightlies are extremely experimental and Kodi is only in its first alpha. You should stick with stable builds if you want a functional system.
ehh. Stupid mistake! Sorry for that. All is okay. There was wrong path (actually - I wrote wrong directory name). Thanks to you I read my output once again carefully 
and I saw that my drive is /MediaDrive, not /MediaCenter 
However something was not perfectlly fine, because after update I had to edit smb.conf and add that /MediaDrive section to have access to that partition.
Well that was part of my confusion.
You should NOT edit smb.conf (which is also written in the file) but you should make changes in smb-local.conf.
Overall you seem to have a quite manual setup. If you would have used the OSMC automount for the drives and the default OSMC smb.conf it would all be automatic.
1 Like
Iām on a Raspberry Pi 3B, and this upgrade seems to have killed my WiFi. Looking in the logs shows an exception stack trace from the kernel in what appears to be a Broadcom driver (at least, I think), so I think the new kernel may have broken things. However, Iām also on an WPA2 Enterprise university network that I had to manually set up on the commandline, so itās possible that a newer connman broke my connection.
Iām downgrading at the moment to see if the same stack trace appears under Stretch, and will investigate further/post my logs tomorrow.
Updated an RPi 2 using command line as well as the OSMC menu. Both went fine. The command line did ask for for confirmation (think it was the SSH config), the OSMC method went without interruption. The update took quite some time due to slow RPi and SD card used, plus itās an OS upgrade so this is somewhat expected. The only observation I could make was that the library view changed from wide to list mode.
Sam has said that itās possible to run everything from a USB drive without upgrading the Vero4K to 4.9/Buster. Since Iāll be home this week, Iāll give that a go.
I also came across a script to check if all kernel options required by Docker are enabled. moby/check-config.sh at master Ā· moby/moby Ā· GitHub
1 Like
@pinn73 Youāll probably be relieved to hear that I got the same error as you on 4.9/Buster when installing docker-ce.
@sam_nazarko AFAICT, this looks like a kernel issue. When I run the command from cli, I see this:
osmc@osmc:~$ sudo /usr/bin/dockerd -H unix:// --containerd=/run/containerd/containerd.sock
INFO[2020-09-27T19:34:09.600649842Z] Starting up
INFO[2020-09-27T19:34:09.620010175Z] parsed scheme: "unix" module=grpc
INFO[2020-09-27T19:34:09.620170675Z] scheme "unix" not registered, fallback to default scheme module=grpc
INFO[2020-09-27T19:34:09.620318342Z] ccResolverWrapper: sending update to cc: {[{unix:///run/containerd/containerd.sock 0 <nil>}] <nil>} module=grpc
INFO[2020-09-27T19:34:09.620401550Z] ClientConn switching balancer to "pick_first" module=grpc
INFO[2020-09-27T19:34:09.626077842Z] parsed scheme: "unix" module=grpc
INFO[2020-09-27T19:34:09.626464925Z] scheme "unix" not registered, fallback to default scheme module=grpc
INFO[2020-09-27T19:34:09.626740800Z] ccResolverWrapper: sending update to cc: {[{unix:///run/containerd/containerd.sock 0 <nil>}] <nil>} module=grpc
INFO[2020-09-27T19:34:09.626895925Z] ClientConn switching balancer to "pick_first" module=grpc
INFO[2020-09-27T19:34:09.662061592Z] [graphdriver] using prior storage driver: overlay2
WARN[2020-09-27T19:34:09.671996883Z] Your kernel does not support cgroup memory limit
WARN[2020-09-27T19:34:09.672117550Z] Unable to find cpu cgroup in mounts
WARN[2020-09-27T19:34:09.672179425Z] Unable to find blkio cgroup in mounts
WARN[2020-09-27T19:34:09.672223175Z] mountpoint for pids not found
failed to start daemon: Devices cgroup isn't mounted
So it seems like itās failing on cgroups. The cgroups on the system are:
osmc@osmc:~$ ls -l /sys/fs/cgroup/
total 0
lrwxrwxrwx 1 root root 11 Sep 27 18:54 cpu -> cpu,cpuacct
lrwxrwxrwx 1 root root 11 Sep 27 18:54 cpuacct -> cpu,cpuacct
drwxr-xr-x 2 root root 40 Sep 27 18:54 cpu,cpuacct
dr-xr-xr-x 2 root root 0 Sep 27 19:40 cpuset
dr-xr-xr-x 2 root root 0 Sep 27 19:40 debug
dr-xr-xr-x 2 root root 0 Sep 27 19:40 freezer
dr-xr-xr-x 2 root root 0 Sep 27 19:40 schedtune
drwxr-xr-x 2 root root 40 Sep 27 18:54 systemd
dr-xr-xr-x 5 root root 0 Sep 27 19:40 unified
so no blkio, devices or pids, though cpu seems to be there.
Hereās an ls of /sys/fs/cgroup on a Debian 4.19 box:
dr-xr-xr-x 2 root root 0 Sep 19 18:59 blkio
lrwxrwxrwx 1 root root 11 Sep 19 18:59 cpu -> cpu,cpuacct
lrwxrwxrwx 1 root root 11 Sep 19 18:59 cpuacct -> cpu,cpuacct
dr-xr-xr-x 2 root root 0 Sep 19 18:59 cpu,cpuacct
dr-xr-xr-x 2 root root 0 Sep 19 18:59 cpuset
dr-xr-xr-x 5 root root 0 Sep 19 18:59 devices
dr-xr-xr-x 2 root root 0 Sep 19 18:59 freezer
dr-xr-xr-x 5 root root 0 Sep 19 18:59 memory
lrwxrwxrwx 1 root root 16 Sep 19 18:59 net_cls -> net_cls,net_prio
dr-xr-xr-x 2 root root 0 Sep 19 18:59 net_cls,net_prio
lrwxrwxrwx 1 root root 16 Sep 19 18:59 net_prio -> net_cls,net_prio
dr-xr-xr-x 2 root root 0 Sep 19 18:59 perf_event
dr-xr-xr-x 5 root root 0 Sep 19 18:59 pids
dr-xr-xr-x 2 root root 0 Sep 19 18:59 rdma
dr-xr-xr-x 5 root root 0 Sep 19 18:59 systemd
dr-xr-xr-x 5 root root 0 Sep 19 18:59 unified
1 Like
Iāll check shortly.
1 Like
Unless we discover any significant issues, I plan to push Debian 10 (Buster) and Kodi 18.8 2020-10-18T18:00:00Z.
8 Likes
For those of us testing, do we need to change our sources to get the actual update, or will buster be the correct source at which to point?
If you followed the instructions in the OP that gives you the same sources list as the final buster release. Additionally, as of a day or so ago anyone who was setup on the stretch development branch will automatically be updated to buster as well.
1 Like
So sorry for the delay - finally retried this update and pulled the logs: https://paste.osmc.tv/kijerocexi
Some notes:
- I verified that the kernel call trace did not appear pre-upgrade
- I tried connecting to the university open network in My OSMC, and that worked. Maybe I need to blow away my manual connman connection and associate from scratch?
- Ethernet also worked
-
UR_Connectedis the WPA2 Enterprise network,UR_RC_Guestis unsecured
Note that when I said ādowngradingā earlier, I meant restoring from backup. So this is a clean upgrade from a system thatās always been stretch and never buster.
Difficult to say right now. Iāve found a few similar issues:
https://www.raspberrypi.org/forums/viewtopic.php?p=1510664
and this one (though Fedora)
https://bugzilla.kernel.org/show_bug.cgi?id=202521
There is mention of wpa_supplicant 2.8 being involved but youāre on 2.7. Unfortunately, the solution in the Raspbian thread probably wonāt apply to OSMC.
If possible, it would be best if you could install a Debian Buster image on your Pi 3, rather than upgrading it from Stretch, and then configure connman from scratch. I think @sam_nazarko would need to supply you with an image file.
We donāt have images for Buster on Pi unfortunately. Only the upgrade path is supported.
Re-reading the Raspbian thread, thereās mention of using the wext driver. It was getting a bit late and I wrongly assumed that because I couldnāt modinfo the wext driver it wasnāt there ā but I was wrong. (You can read about wext here .)
So as a quick hack for now, please edit (using sudo) /lib/systemd/system/wpa_supplicant.service and add -Dwext to the start line:
ExecStart=/sbin/wpa_supplicant -Dwext -u -s -O /run/wpa_supplicant
Then run:
sudo systemctl daemon-reload
sudo systemctl restart wpa_supplicant
See if that helps.
First attempt to check for update hung forever after cache was updated. Had to reboot. Next try was a success. All seems to work as expected.
Have been running this on the 4k+ for Ā±2 weeks (with 4.9 kernel) no issues.
1 Like