I have an old macbookpro 11,1 (mid-2014) and I tried to install COS on it. Installer hangs even after the 4th try. I did then Install Arch-vanilla imported COS repos. That worked!
I use systemd-boot (which is recommended by COS and Arch).
I installed linux-zen with no problems and it shows up in systemd-boot. I then installed COS-kernel (without problems) but that does not show up in systemd-boot!! Why is that?
I read about systemd-boot in arch-wiki and created an entry (based on linux-zen and arch-wiki) in /boot/loader/entries. Now it showed up in systemd-boot but it will not boot. It hangs.
Related to the hand this is likely because youre getting out of ram, because the ISO is getting copied to the chroot.
The upcoming release will have for this an fix.
Here you can find the testing repo: https://mirror.cachyos.org/ISO/testing/
I then installed COS-kernel (without problems) but that does not show up in systemd-boot!! Why is that?
Because you need to create a entry. Without an entry, it can not find it. CachyOS itself uses some kind of systemd-boot-manager to generate these, but this does not exists at archlinux
systemd-boot itself not, but we created a manager for it. It does basically the same as āgrub-hookā, which generates the grub config when installing a kernel or equal.
Boot crashed bad!
I am rather sure I did a correct entry but I think it is this old computer in combination with the kernel (maybe!?).
As I read another post about macbook pro 12,1 I think I will go to test-iso next.
Hi,
I am a complete noob in but when trying to solve my problem I came across a controversy about āinit sysā on Linux and how I donāt know anything about it I would like to know if there is a possibility that I change systemD by OpenRC or Runit in cachyOS because I suspect that systemD does not allow Ardour to work in a stable way.
I at the simple action of opening the I/O menu and choosing I/O in Ardour the app is closed, there is no condition to work with Midi+Ardour in cachyOS, why?
I checked all the .conf, I changed the fstab and noam, everything seems very well configured to hold the flow I like to use, but the Ardour simply breaks.
I say that Iāve been researching and reading.
Wiki/Arch guidelines break the Systemd.
It seems to me that it is a general problem of Arch+systemD and distro Arch based+systemD. There is simply no way to use Ardour in a professional and more complex way.
Apart from the Artix, there is an only distro Arch that can sustain the Ardour and in all the other distro even with systemD I can even burn my sound module if I want
cachySO for me is unique and it has taken my peace.
((I would like to take the opportunity to say that the system with KDE+Wayland+HDR is losing visual fluidity very little but it is. Even Wayland Iām spending a lot of resource. By passing the mouse through the icons the flow clearly and this does not happen when Uses the x11.
I also wanted to inform that the bore-prt-lto kernel is always crashing.)))
If you donāt want systemd than your options are rather limited. This warrants a broader conversation than I alone can provide. As for your difficulties with ardour, that might be less of a systemd issue and more of a desktop environment problem. Not all applications have seen as much work towards wayland compatibility and I do recall that ardour was one of the ones frequently mentioned. There might be some ways around it. I will have to investigate ways to accommodate a lack of systemd. I still have reservations as to whether that is going to be easy to maintain not using it.
thank you for your attention.
Any explanation is light.
I am starting from audio linux to try to understand how they work on privileges, the issues of processing requisition in RT and etc ā¦
I think Ardorās behavior has more to do with privileges and permission than anything else.
In Enligtement, which has a problem with OpenGl, when PixMap is activated, Ardor suffers but does not break due to glitches or flickes. Breaks because of systemD and unconfigured privileges. And even if you add groups and limits, things donāt work. In OpenRc everything is simpler and more direct.
Perhaps what I said is being corroborated by this:
"Before arch migrated to systemd, users had to be manually added to these groups in order to be able to access the corresponding devices. This way has been deprecated in favour of udev marking the devices with a uaccess tag and logind assigning the permissions to users dynamically via ACLs according to which session is currently active. Note that the session must not be broken for this to work (see General troubleshooting#Session permissions to check it).
There are some notable exceptions which require adding a user to some of these groups: for example if you want to allow users to access the device even when they are not logged in. However, note that adding users to the groups can even cause some functionality to break (for example, the audio group will break fast user switching and allows applications to block software mixing). "
Well, my problem with Ardour on cachyOS was solved by installing it on flatpak version.
I donāt think anything I said is valid because it is the cachyOS repository package that needs to be redone as well as the Clementine package.
I can now change the Audio and MIDI connections perfectly and configure which Audio and MIDI.
I did one more test.
I uninstalled the Ardor 8.6.0 flatpak and replaced it with the 8.6-1 cachyos-extra version and it has been stable so far, even after the ALSA and Pipewire update.
The version of Ardor 8.6-1.1 released as an update is the one causing the problem. It breaks Ardor when trying to change AUDIO/MIDI connections or even change the buffer size.
That is great.
I would generally suggest to use native packages before flatpak. Flatpak has often outdated runtimes, like driver, graphics stack and co.
If a native packages is not working - go with the flatpak one.
Flatpak is not really āmoreā secure then others, since also any person can package it as well as the sandbox is not properly setup at most packages.
