The officially official Devuan Forum!

You are not logged in.

#1 Re: ARM Builds » Updating kernel (Raspberry pi 2) » 2024-03-28 18:23:57

I am not convinced that adopting the .armmp kernel is your best course.

Please see https://dev1galaxy.org/viewtopic.php?id=5255 where I  posed a similar question. I will let you read that thread and judge whether your situation is the same.   

Wireguard works well with both the .armmp kernel and the kernel optimised for RPi.

I concluded it was better to stick with the optimised kernel but it may be horses for courses!

#2 Re: Desktop and Multimedia » [SOLVED] Shotwell dependency confusion » 2023-09-14 19:43:27

I had another go at the problem today and although I do not understand the fine points of why or how, I now have Shotwell up and running.
Yesterday, apt thought that dconf-cli version 0.38 was available - but a dependency was libdconf1 0.38. My libdconf1 was already at 0.40 so apt refused to load dconf-cli. Synaptic knew dconf-cli existed but had no details of any sort for it.

Today, Synaptic agreed that dconf-cli 0.38 was the latest version but refused to load with an error message that I interpreted as that it could not find the file. I dug around in the devuan repository and found that 0.40 of dconf-cli should be available and it referenced the debian repository. I searched through the debian repository and found the 0.40 file, downloaded it and used dpkg to install it.  Synaptic is now happy that 0.40 of both dconf-cli and libdconf1 are available and installed and Shotwell installed happily.

I guess the problem was probably something to do with the database files for apt and Synaptic on my system not updating properly but I certainly don't know that. I could find nothing in preferences that would prevent that updating. I would have liked to understand what was actually wrong and cannot pretend my solution is anything other than a cludge but it works so I am happy.

Thank you all for your thoughts, suggestions and helpful info. My Shotwell version is now 0.30.17-1+b1 from stable. I will try gtkam as my next experiment.

#3 Desktop and Multimedia » [SOLVED] Shotwell dependency confusion » 2023-09-13 20:21:31

EnglishMohican
Replies: 5

I am trying to install Shotwell. So far I have tried synaptic, apt and aptitude and all of them refuse because of broken/missing/held packages. They don't quite agree on what the problem is. Synaptic says it needs either default-dbus-session-bus or dbus-session-bus, Aptitude and apt sort of agree that dconf-cli is the problem.

I found an old post that said that dbus-session-bus was provided by dbus-X11 which I do have installed.

dconf-cli is listed in the repository lists but has no data against it.

Apt flags up that my libdconf1 is at 0.40.0-4 but dconf-cli depends on libdconf1=0.38.0-2. I do not understand how it knows that when there is no data against the dconf-cli entry in Synaptic.  I tried to downgrade libdconf1 using Synaptic but it wants to remove most of the software on my laptop as part of the deal.

I am running Devuan Daedalus with xfce4, all updates applied. It was originally  Chimaera which I updated by changing the repository lists in Synaptic. This has caused one problem already - the update process dropped the ntp set of packages but did not install the ntpsec set of packages to replace it - at least that seemed to be the problem. I mention this because it could be a clue.

Mostly, I do not understand the problem. I have three package managers that tell me different problems, none of which seem totally reasonable. I would like an explanation of what the real problem is and why the package managers see it differently (just for my education) and ideally a simple means of correcting things and getting Shotwell installed.

Thank you for reading as far as this and for any help you can provide.

#4 Installation » [SOLVED] Daedalus Preview NetInstall Report » 2023-02-24 10:53:10

EnglishMohican
Replies: 0

I recently installed the preview edition of Daedalus on my laptop. All is now well - but I had a few problems along the way that I feel I should report. I know of no better place than here.  I hope that somebody wiser than I can pick the bones out of this and improve the net-install to make the process smoother and more idiot proof though I am not aware that I did anything wrong.

My laptop was originally set up to dual boot Chimaera and Windows on separate SSD partitions. Its an EFI system with AMD onboard graphics and Nvidia add-on graphics. I was finding that some programmes I wished to run were demanding more up to date support than Chimaera provided so I already had some bits from testing installed and this was making the system a mess but it was working adequately.  I decided to install Daedalus Preview onto a separate new partition which I set up before I started the install. I used "devuan_daedalus_5.0.preview-20230213_amd64_netinstall.iso" loaded onto a USB stick.

When installing, I told the installer to put Daedalus on the new empty partition. All seemed to go well with the install until I rebooted at the end. Grub came up - but only showed the new Daedalus, (missing the Chimaera and Windows options) and when I tried to run it it froze a few lines into the boot waiting for /dev to be fully populated. I gave it time! I tried the advanced boot option and that got further through the boot process but still froze before the end (about 4 seconds in?).

I solved the grub problem by using the rescue option on the install disc to reach the original Chimaera OS in rescue mode - doing a grub-mkconfig and then a grub-install. That let me back into Chimaera from where I managed to use a chroot to install the nvidia packages onto the Daedalus partition (that solved the first boot freeze) and then the AMD firmware which I believe was the cause of the second freeze. This gave me a working Daedalus. End of Panic.

This took a number of attempts over two days so much confusion and maybe missing vital steps from this report. I am not recommending these solutions but I now have clues for the next time.

Thank you for Devuan. I have used it for several years now and am generally very satisfied with it.

#5 Re: ARM Builds » [SOLVED] Apt demands armmp dependencies in place of RPi kernel images. » 2022-09-25 08:42:52

Thank you both. Knowing the foundation is concrete makes for a much happier build!

#6 Re: ARM Builds » [SOLVED] Pi Zero - No output on hdmi. » 2022-09-17 09:45:02

I downloaded and tried the image you provided. It gave exactly the same results as the earlier one. However, I then made a fresh copy and tried again but with the Pi connected to the family TV. It worked - I had console output and reached a login prompt. So it is something to do with the monitor I used before.

To investigate further, I downloaded the current Raspberry Pi OS and tried that with the monitor plugged into the Pi again. It worked - but I saw nothing until a cursor arrow appeared and then X started.
So it appears that the RPiOS can find the monitor while Devuan cannot - though it may be X that does the finding rather than the core system. I have not tried X with Devuan.

Getting this far reminded me that this monitor is an old Philips Monitor that has a DVI input rather than a true HDMI input. There is a socket converter permanently plugged in so I just use a standard HDMI cable and had forgotten the subtlety.

The monitor does work normally with an RPi4 and Devuan runs X very nicely - but I set this up long enough ago not to be able to remember the process. I am sure there were not many hurdles though

I always intended to use the Pi0 headless  and was pursuing this problem more as a matter of principle than need. It now looks as though it is too niche to be worth pursuing further.  Unless anybody wants to pursue this, I consider this solved.

Thank you c0rnelius for your help.

#7 ARM Builds » [SOLVED] Apt demands armmp dependencies in place of RPi kernel images. » 2022-09-16 19:48:07

EnglishMohican
Replies: 3

I recently installed wireguard on my Raspberry Pi running Devuan. I managed in the end but only after some troubled moments. The problem is that wireguard wants to install wireguard-dkms - which wants to install dkms - which depends on linux headers. It appears that the linux headers installed on the Pi as part of devuan_chimaera_4.0.0_armhf_rpi2.img.zip dont match the requirement, so apt starts to install one of the armmp header files from Debian together with the matching armmp linux-image.

At that point I stopped it and built the modules from source - which was what the dkms was all about and got everything running but getting rid of the partly installed armmp stuff did get scary.

That experience leaves me with two questions:-

1. I assume that the chimaera armhf-rpi2 image is targeted specifically at the Pi and includes some or all of the kernel optimisations included in the Raspberry Pi OS. As such it should run better than a generic kernel. Am I right? Does it include the optimisations?

2. What is the state of Debian's multi-platform linux-images? Are they the horse designed by committee, that became known as a camel? Can device trees encapsulate all of the differences between different boards using an arm processor or do we lose a lot as simplifications have to be made?

Opinions? Experiences? Facts?

#8 ARM Builds » [SOLVED] Pi Zero - No output on hdmi. » 2022-09-16 16:54:33

EnglishMohican
Replies: 2

I am converting a Raspberry Pi Zero W from Raspbian to Devuan.

I downloaded devuan_chimaera_4.0.0_armel_rpi0.img.zip from the arm download page, checked the sha256 value (it was fine) and loaded it onto an SD card. I modified the "change this to Credentials.txt" file appropriately and booted the pi.

The attached hdmi monitor wakes up but only displays a plain black screen but no boot messages, no init messages and no login prompt.

I can ssh into the pi perfectly well.  Looking at the log files:-
    dmesg mentions a framefbuffer and a console but shows no errors. No mention of hdmi.
    boot(.log) shows no errors but no mention of hdmi.
    kern.log has mention of vc (videocore?) but mostly in relation to video capture. It also appears to reserve video memory. No mention of hdmi.

Going back to the raspbian SD card, everything works including the monitor so the hardware is ok.

Searching the forums, I see reference to /sys/devices/platform/drm/ - and a number of directories below that one of which has hdmi in the name. There is no drm directory in the pi's /sys/devices/platform directory. But it is not there on a Pi2 that I converted earlier - but that does not have a monitor plugged in. The suggestion was that it should be possible to read the edid for the monitor from that location.

I suspect that my pi does not know it has an hdmi connector or a monitor connected to it.

I also found a post saying that some firmware should be copied to /lib/firmware/brcm to solve this problem - but try as I might, I cannot find that post again, and it was not very specific about which firmware to copy.

Any help, suggestions or pointers welcome. Preferably, I would like to understand what is wrong - not just fix it.

Thank you

Board footer

Forum Software