You are not logged in.
Devarch wrote:You can disable FS check if it's enabled.
It is not a good idea. It is highly recommended to run it when the system requests to avoid file system errors. If you permanently disable fsck checks on the partition, errors that come up in the future may get through undetected and break your kernel or corrupt your data.
We are talking about speed up. FS check can be done manually and it's a good idea to have some full backups.
Anyway, almost all accelerations have a price. Even mitigations=off (which is good )
I run the system on top of overlayfs. So the system is immutable and does not require FS check. It costs me some additional time to shutdown but it's good for security and performace. Also it helps to protect ssd.
Devarch wrote:To speed up devuan I've disabled anacron. Sometimes it slows down shutdown.
Anacron is useful on personal PCs ...
I don't use cron.
There is a bug or some problem with it. Sometimes it blocks shutdown. Quite seldom, but annoying.
Hmm. After disabling anacron i always have this error after booting
https://i.imgur.com/lZB72tt.png
all working again after enabling anacron
I've no problem with Cinnamon or Budgie.
To speed up devuan I've disabled anacron. Sometimes it slows down shutdown. You can disable FS check if it's enabled.
all these mainstream media websites and news corporations are evil,
xD
100%
Aslo WASM is pure evil, not only "1000" scripts. I had to disable it in all browsers.
I am talking about responsiveness overall of system.
On Devuan now i using Trinity DE and its much faster than default xfce de. I have several DEs installed its can slowdown on my Devuan?
I don't think having multiple DE will slowdown your PC. It's more abour running services.
Trinity is good and very battery effective, but its network manager can not reconnect (or I did not found) and not sure whether it supports pipewire and hdpi displays.
I agree with first part but not with the second.
All *isms are wrong.
I seem to be more of a fossil than you. I do not have a working cell phone. Only one which has never had a working account for 911 emergency use only . . .
The web is deranged because it magnifies the reality that our species is deranged with greed, hatred and delusion. I vote for extinction . . .
Or one can have 3+ cell phones with different profiles for different tasks.
Welcome home, Lennart))
I have to say that this article makes me like Google more:
https://www.newsbusters.org/blogs/free- … buries-gop
@OP: I find your links to far-right propaganda websites disturbing.
“Democracy is being allowed to vote for the candidate you dislike least.” Mark Twain
Capitalism is somewhat similar to communism - different approach but the same result: mass-elite system.
Sorry
Apparmor may offer sand-boxing for programs but it has cost me performance.
Slow boot times, slow shutdowns, and very slow program launches.
Thanks. May be I should get rid of it too. Nothing is slow, but speed is a matter
The best way imo is to convert debian netisntall to whatever you need. To chimaera, daedalus, ceres.
It has beautiful GUI installer, firmware image contains wifi drivers and it's never broken.
The best way to prepare boot flash drive is to use ventoy one time only. To add an .iso to ventoy just copy it.
The best is to use many search enginees at once (except google )
What is wrong with apparmor?
You can nano /etc/apt/preferences.d/systemd
Package: systemd
Pin: release *
Pin-Priority: -1
Package: *systemd*
Pin: release *
Pin-Priority: -1
Package: systemd:i386
Pin: release *
Pin-Priority: -1
and than use as many compatible repos as you like. It should be ok. For example I have LMDE chimaera edition))
But if some package from another repo requires systemd as dependency than you are out of luck with this package.
5.19 is dangerous. It can damage intel laptop display. To avoid.
I did almost the same, decapitate gnome-keyring-daemon :
chmod -x $(type -p gnome-keyring-daemon)
But it means that it's broken.
I have tried this solution: copy old "debian" to EFI as "daedalus" than
efibootmgr --create --disk=/dev/nvme0n1 --part=1 --label="daedalus" --loader='EFI\daedalus\shimx64.efi'
It appears in refind menu and it boots new chimaera!
The default efi entry is called debian. As long as you work without Secure Boot, you may boot your install media in rescue mode and write individual efi entries for your installations, e.g.:
# grub-install --bootloader-id=devuan4 --no-uefi-secure-boot
I have used devuan4 for Chimaera and devuan5 for Daedalus.
Where should I do it? in chimaera (the only which boots)?
Devarch wrote:Now I can not boot daedalus.
Why not? What happens when you try? What do you see?
Devarch wrote:The boot manager is refind
Please post your rEFInd configuration(s) and also the full output of
efibootmgr -uv
Before I had windows (on veracrypt), daedalus and space for other linux to test: 1 partition for boot and one for encrypted root. In my very first partition, EFI partition I had many folders: refind, debian (which means devuan). When I installed ubuntu I had ubuntu folder and the same name appeared in refind's menu.
All my devuan installation are made from debian, so the folder name is debian.
So, I've installed one more debian, converted it to chimaera and all of this alongside daedalus.
Now I cannot boot daedalus. All my important staf is in daedalus. Boot partition is ok, luks with daedalus is ok. I also had old folder EFI/debian. I've renamed this folder and put it in /EFI/daedalus. It did not help. I've installed refind again and got the same result.
# efibootmgr -uv
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,DC5B,0000,0002
Boot0000* Windows Boot Manager HD(1,GPT,b152e14e-61f7-4570-b496-29920c69a074,0x800,0x200000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)䥗䑎坏S
Boot0002* debian HD(1,GPT,b152e14e-61f7-4570-b496-29920c69a074,0x800,0x200000)/File(\EFI\DEBIAN\SHIMX64.EFI)
Boot0003* rEFInd Boot Manager HD(1,GPT,b152e14e-61f7-4570-b496-29920c69a074,0x800,0x200000)/File(\EFI\REFIND\REFIND_X64.EFI)
BootDC5B* VeraCrypt BootLoader (DcsBoot) HD(1,GPT,b152e14e-61f7-4570-b496-29920c69a074,0x800,0x200000)/File(\EFI\VERACRYPT\DCSBOOT.EFI)
Changed boot menu in bios from refind to hard drive - the same
Head_on_a_Stick, hhank you for this hint.
What is wrong with using XAUTHORITY? Almost every linux distribution lets run editor as root? I use it to edit system files. Is there some security problem?
I've decided to install chimaera alongside daedalus.
Both installation have been made by converting debian installation.
The problem is that folder "debian" already existed in the 1th EFI partition.
Now I can not boot daedalus.
I have copied "debian" folder from efi partition before install to backup. I tried to copy it in EFI with different name, but it boot the new install "chimaera"!
How can I restore it?
The disk layout is:
EFI Boot-Chimaera(grub) Boot-Daedalus(grub) Luks-Chimaera Luks-Daedalus
The boot manager is refind
Devarch wrote:I still need password with doas inspite of
Sorry to ask but you did replace username with the actual username, right?
That syntax works for me with the Debian doas package provided the actual username is supplied.
yes.
I've discovered that if this line is present
permit persist keepenv setenv { XAUTHORITY=/home/username/.Xauthority DISPLAY=:0.0 LANG LC_ALL } :username
than this problem is present.
Surprisingly, if this line is removed I do not need to tap password.
But without this line I can not use geany or other staff as root.
It is strange. The package gnome-keyring has not been updated. Some packages which names starts with gnome- where updated.
I do not understand, gnome creates so much problem!
I have to move from ceres to daedalus. After ~ 2 month on cerres the system was broken completely and irreversibly. System update of cause. Now the story repeats with daedalus. It breaks every 2-3 weeks.
I also reverted to 5.18 kernel, as vmware does not work correctly with 5.19 So slow even with spectre_v2=off or mitigations=off
I have to use vmware as virtualbox neither work correctly nor KVM where virtfs is partly broken too.
Do you really have no issues after updates?
/usr/bin/gnome-keyring-daemon --daemonize --login 100% CPU
pstree gives this
init─┬─ModemManager───2*[{ModemManager}]
├─NetworkManager───2*[{NetworkManager}]
├─accounts-daemon───2*[{accounts-daemon}]
├─at-spi-bus-laun─┬─dbus-daemon
│ └─3*[{at-spi-bus-laun}]
├─at-spi2-registr───2*[{at-spi2-registr}]
├─avahi-daemon───avahi-daemon
├─bluetoothd
├─cron
├─cups-browsed───2*[{cups-browsed}]
├─cupsd
├─2*[dbus-daemon]
├─dbus-launch
├─dconf-service───2*[{dconf-service}]
├─dnscrypt-proxy───12*[{dnscrypt-proxy}]
├─dnsmasq───dnsmasq
├─elogind-daemon
├─evolution-addre───5*[{evolution-addre}]
├─evolution-calen───8*[{evolution-calen}]
├─evolution-sourc───3*[{evolution-sourc}]
├─gedit───4*[{gedit}]
├─6*[getty]
├─gjs───10*[{gjs}]
├─gnome-keyring-d───3*[{gnome-keyring-d}]
Not keen on using appimage.
I did try HOS's suggestion to disable hardware acceleration. That didn't solve the problem.
What does seem to have solved the problem is downgrading my kernel to 5:15 from 5:18 .
Personally, I prefer to unpack appimage than to change kernel for one application.
But it's just personal chose, of cause.