Emby: Error in getting File 41.deb #3929
Comments
|
Hi, could it be you are running a Raspberry OS 32 bit with forced kernel mode 64 bit? That's basically causing the issue as you are trying to install 64bit executable on a 32bit OS and it's simply not able to install missing dependency. Just setting Just run |
|
Many thanks for your reply! 👍 :) Well... And yes, its armhf. :-/ |
|
Just do BTW: on DietPi you can do backups using |
|
In my config.txt is no arm_64bit=1. I've tried the backup from dietpi-backup but wasnt able to make a backup on my FAT32 USB stick... EDIT: Now I have a ext4 HDD on one USB and doing now a backup :) Also I wanted BerryBoot for having different OS's on my MMC, like for testing. :) Btw; The "regular" DietPi is 64 Bit? |
|
Strange that you don't have
The question is not if DietPi is 64 bit. It's more if the used base image is 32 or 64 bit. 😉 Because DietPi is not an own OS or distribution. It's a cool set of scripts on top of a base image. In case of Raspberry Pi, DietPi is using Raspberry OS as base line. At the moment Raspberry OS is available as 32 bit version only. The Raspberry Foundation is working on a 64bit Raspberry OS, but this is still in Beta with limited or missing functionality. Something the Raspberry Foundation si still working on. However it's already supported by DietPi. 32bit default https://dietpi.com/downloads/images/DietPi_RPi-ARMv6-Buster.7z |
|
Lol, I'm typing too slow 😄. Berryboot even has a testing DietPi Buster 64-bit image: https://sourceforge.net/projects/berryboot-updated-images/files/Raspberry-Pi/Testing/Raspberry-Pi-4/ I'm having a look into the Berryboot image. |
|
Okay... If my DietPi is running I could try to test the 64Bit, but im fresh to ux-systems :D EDIT: Would be nice, MichaIng :) |
|
using 64bit image is like flashing a new SD card. The versions are completely independent from each other, as they are using complete different sources and complete different software packages However don't expect miracles from 64bit version. Usually there is not that much benefit and you could stay with the 32bit image without issues. |
|
Okay... EDIT: Its offtopic, but can if have something to do with the 6Bit thingy, that Docker dont runs too as expected? |
|
64 bit is running on the RPi3B+ as well 😉 |
|
I had a look into the Berryboot image and still don't understand everything, but what I can say:
The big problem with all this is that all usual and documented OS/kernel (and in case drive) features and configuration do not work, especially also building kernel modules, which breaks our WireGuard implementation and I think Docker as well as it wants to load kernel modules, but none are present on the regular path. Just to verify: The idea of a multi-boot system and extended bootloader capabilities is great, but when an OS is invoked with a complete different kernel implementation and configuration that causes limitations. In our case it is a larger issue since our scripts expect config.txt to work to configure the system for the chosen/installed software titles, but as well the APT repository packages do so (in case of RPi repo packages at least) but at least expect kernel modules at /lib/modules. |
|
It's part of Berryboot config menu
|
|
vcgencmd get_mem gpu shows gpu=160M uname -a shows: and lsmod shows: Okay, then I will edit the config.txt in BerryBoot now and report back. |
|
[pi3] 64-bit stuff for Pi 3kernel=kernel_rpi64.img results in not booting anymore... :-/ |
|
These defaults for not make sense, there is not point, just a lot of broken installers, when booting any 32-bit OS with a 64-bit kernel. The question is, if this "kernel_rpi64.img" is even able to run in 32-bit mode 🤔 or if the "kernel_rpi0123_aufs.img" is able to boot an RPi 4 (not an issue here, but in general). Okay, so the obsolete kernel package files have been reinstalled already. You "should" be actually able to purge it: |
|
Different approach, as I now understood that you install a Berryboot base image, only the bootloader + kernel, and import/install the actual OS from there. To boot a 32-bit OS (correctly), you need to use the 32-bit Berryboot: https://sourceforge.net/projects/berryboot/files/berryboot-20190612-pi0-pi1-pi2-pi3.zip/download |
|
"EDIT: It is not. Try to use kernel_rpi0123_aufs.img instead." I made a Backup but I will make a new complete MMC image one. |
Jep, that will be the issue, as it ships the 64-bit kernel only. They should have named it The image I linked above is the correct one to boot the 32-bit DietPi image in intended 32-bit mode: |
|
After the Backup on my Notebook I can try to make a Backup of DietPi with BerryBoot himself, "install" then berryboot-20190612-pi0-pi1-pi2-pi3.zip and restore the copy from the "old" BerryBoot. |
Then you would need to copy the kernel modules as well. Those are part of the |
|
I "ported" my working DietPi (btw: The BEST experience I have so far with my Pi's! Great work! :) ) and I hope it sounds good! mihihi I will try now to install Emby again and report back then. |
|
|
|
Oops... the installation is running now on a backup Ive made with BB! Me dumb! :D (The installation runs flawless in the background so far happy) But as it is the wrong OS (i forgot to set the "main" OS as favorite), I need to do it twice, so it will take some time... Im looking forward that Docker will work then too... :) UPDATE: Emby is working now on my Backup OS! |
|
Wherever DietPi-CloudShell autostart comes from, run Yes, the kernel is from older 4.19 branch and I just heard from Berryboot dev that the 32-bit images are not supported/maintained anymore. From what I found, it is quite easy to manually enable and build a 32-bit RPi image based on the current stable 5.4 kernel branch, but not sure about Berryboot internals. There is no kernel upgrade feature within the Berryboot GUI, is it? |
|
Puh... Hmmm... Btw: Donation is made! :) |
That's bad as 64bit is still Beta and not all thinks are working, still a way to go for the Foundation |
|
There is something I mention now: Well... as I want to install Docker later anyway its maybe not a big deal but I wanted to mention it... |
That's maybe related to your backup restore? By default Docker is not installed, but in your case the
Yes, a step that has been made too early IMO, but I can understand it when developer time is limited and maintaining code and support for two architectures and older RPi models could simply cost too much time, so the decision was to go forward and support what will be used in the future and at least does work already, although with some limitations. Important to note is, if I didn't overlook something, that for the Berryboot kernel, headers are missing anyway, so WireGuard and other module builds will fail, similar to how it is with the RPi 64-bit image. |
|
Hi guys, do you like to keep the issue open or can it be closed? |
|
Oops... i forgot to send this comment yesterday... Luckily I dont needed to restore my backup to the "new" old 32bit BerryBoot. Over night i left my Pi untouched because of syncing and for about some minutes I wanted to reinstall Docker and run in this problem:
Sorry to bother ya again... :-/ Btw: the "Cloudshell-Problem" is fixed with the "dietpi-autostart 0" command :) |
|
Those files should not exist anymore, likely as well a leftover of the backup restore? Not sure why those should be no "regular files", but please remove them: There is a single file now But the error should be below these "notifications". You can use the page down or arrow down buttons to scroll the output. It's sadly a known whiptail bug that the scollbar is missing that would indicate this. Another thing I find strange is the ugly whiptail border, which looks like no UTF-8 locale is selected. Could you paste: |
and Maybe this ugly is because of my Kitty setting... I did: Oh and this is still present at booting: Meanwhile Ive tried: And here what was cuttet in the screenshot: Next step I did: |
|
Update:
Is this now one step forward or backward? :D |
Such btw means that the directory Okay so now you're further, but Docker package install itself failed. Please try to run it manually and paste the output: |
|
Here it comes: `dietpi@BerryBootDietPi:~$ sudo apt install docker-ce -y N: Ignoring '98-dietpi-no_translations' in directory '/etc/apt/apt.conf.d/' as it is not a regular file The strange thing... In Midnight Commander I can see the 3 files have a ~ in front so ~98-dietpi-no_translations if this important for you... If I decide to make a fresh install of DietPi, can I somehow keep and import my already configured stuff like for samba, webmin, plex aso? |
|
I guess docker.list source file was not created and therefore apt could not find the package |
Not sure where this might come from, maybe when those are opened by an editor and then editor is killed or drive unplugged? Remove them: Quoting is important here, else Let's try to do that manually: |
|
It drive me nuts.. :D And at first the dash command results in: So I checked the directory with MC and found a ~docker.list Shall i better make a screenshot? Strange... |
|
fixed format for better reading. Pls if possible don't do screenshots |
|
I guess We have to do some research where such files might come from, some file system magic, but obviously known since all programs fail to write the file without tilde Meanwhile, could you check, to verify if the root file system is still And indeed, for pasting code or console output here, best is to use the Markdown fenced code syntax: becomes unformatted, space-preserving monotype "code" box 😃: |
|
I was experimenting until deep in the night and felt asleep before I was able to post this...hihihi Thank you, Joulinar. Well... after observing and checking whats going wrong with the installation of docker I found out, that my system have many ~ files matching the names, docker fails to write or configure something. Here the FS: And: Yes I know, I need a new cable... hihihi
I read, that it can have something to do with docker 19 here: So atm Im trying to downgrade it to OH and I found out, that I dont have this directory: |
|
for me docker is working fine on RPi3B+ using 32bit image This is not needed Can you post following BTW: RootFS looks quite interesting. Doesn't looks like |
|
I didnt changed something on the Filesystems... I tried to install it again but I run again in this: journalctl -u docker.service gives this info: Ive checked the /etc/docker/daemon.json but I didnt found something like "value pair"... UPDATE: So I have a Kernel problem? Well... as v19 works well on yours, I will try it again with installing it from your dietpi-software... :) |
|
there is a missing comma should looks like this I guess it's because you have an additional value |
|
Well, as Ive deleted it, I was able to get one step ahead as I posted above... I think will learn about "apt clone" for some settings and try it again then with a fresh system. EDIT: ` And for some last additional info, trying to start dockerd gives: Anyway... |
|
You are missing |
|
Hmm, strange that the installer did not install it, if it's required? Probably depends on the container, e.g. for network forwarding. Try |
|
actually But I guess Docker installation failed as show above |
|
The dependency should have been installed first, before reaching the configuration step where the service was started. Very strange. Also the broken config file is strange. We only inject the settings, if the config file exists already, and then all with trailing comma. Else, only if the file not exists, we create it and then correctly skip the last comma, else JSON syntax is wrong: https://github.com/MichaIng/DietPi/blob/master/dietpi/dietpi-software#L12147-L12162
Okay, I think we have the culprit, which is likely also responsible for the added Docker storage driver setting (some buggy Docker init script adding it when seeing aufs root fs). Interesting is the history of this file system type: https://wikipedia.org/wiki/Aufs
That does not sound like a robust root file system to me, at least not one that is well supported. Another issue is that there are some parts of DietPi which expect ext4 as root file system. I'm aiming to liberate this, but first of all with F2FS and Btrfs as it requires to detect and select an additional set of tools for automated first boot file system expansion and at least one other thing I currently don't remember. However that is more minor, a question which file system we ship our own images with where everything must work of course. It seems that Berryboot requires the OS image to be on/mounted as aufs file system. And that seems to be generally incompatible with Docker: https://raspberrypi.stackexchange.com/a/112582 |
|
I'm gonna mark this as closed. We know now that Berryboot ships images with the Aufs file system, which breaks a few limitations and additionally the config.txt, kernel, firmware etc on the image are not used, hence cannot be directly configured from within the OS, which is what our scripts rely on. So while I generally like the idea of Berryboot, the way it works currently cannot be easily supported by us, the amount of rework required is by far to much for our small team. But as long as someone can live with the limitations, the core OS boots and is functional. |
Hi! :)
First: Great Development and it really makes fun to work with DietPi! :)
Now to my Problem:
Emby will not install from the Software Menu.
[ INFO ] DietPi-Software | APT install for: ./41.deb, please wait...
E: Unable to correct problems, you have held broken packages.
[FAILED] DietPi-Software | APT install for: ./41.deb
[ INFO ] DietPi-Bugreport | Packing upload archive, please wait...
Details:
Linux BerryBootDietPi 5.4.73v64 #2 SMP PREEMPT Tue Nov 3 16:11:05 CET 2020 aarch64 GNU/LinuxSteps to reproduce:
Expected behaviour:
Actual behaviour:
E: Unable to correct problems, you have held broken packages.
[FAILED] DietPi-Software | APT install for: ./41.deb
[ INFO ] DietPi-Bugreport | Packing upload archive, please wait...
Extra details:
sudo apt-get install /tmp/DietPi-Software/41.deb
in the "Open subshell" and get this error:
Note, selecting 'emby-server:arm64' instead of '/tmp/DietPi-Software/41.deb'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
emby-server:arm64 : Depends: zlib1g:arm64 (>= 1:1.1.4) but it is not installable
E: Unable to correct problems, you have held broken packages.
Additional logs:
Have it something to do with 64bit needed?
I have an other Problem too with DietPi and Docker but this is not primary on my list and I will try Docker again in some days.
But I stumbled about 64bit and Docker too...
The text was updated successfully, but these errors were encountered: