Hello:

I had deleted the edited file and returned to the back-up I saved.
So I re-edited it now.

$ cat /etc/initramfs-tools/conf.d/resume
# changed 06122024
# see https://dev1galaxy.org/viewtopic.php?pid=53266#p53266
# this box does not use hibernation / resume

RESUME=none

# RESUME=UUID=f0187ff0-be52-4bbc-9461-40f744554b85
$ 

But now it works.

# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.1.0-28-amd64
live-boot: core filesystems dm-verity devices utils udev blockdev dns.
#

I'm sure I had written / spelled it correctly.

But if it did not work, there was obviously something amiss.
Maybe the added comments?
Not so sure now.  8^/

Thank you very much for your input.

Best,

A.

Hello:

This post caught my eye.

Don't want to hijack the thread but seems relevant.
So just one question, if I may.
Please let me know if it warrants a separate thread.

That is exactly what my box has and the UUID is the swap file.
But it happens that I do not keep my system on all day, just shut down and reboot.
ie: there is no hibernation image present, never set it up to hibernate.

At some point my dmesg printout reads:

--- snip ---
[   24.068315] PM: Image not found (code -22)
--- snip ---

Q:
Does the system look for a hibernation image at boot time because the line in /etc/initramfs-tools/conf.d/resume is not set to =none and there is a valid (swap file) UUID present?

If I edit /etc/initramfs-tools/conf.d/resume and set RESUME=none, on updating I get this:

# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.1.0-28-amd64
/usr/sbin/mkinitramfs: 5: /etc/initramfs-tools/conf.d/resume: none: not found
I: The initramfs will attempt to resume from /dev/sdb3
I: (UUID=f0187ff0-be52-4bbc-9461-40f744554b85)
I: Set the RESUME variable to override this.
live-boot: core filesystems dm-verity devices utils udev blockdev dns.
# 

The system looks for a swap file and not finding one with a UUID of none, finds one and uses it.
What to do?

Best,

A.

Hello:

@Ron
See https://www.linux.org/threads/clearing- … ost-250695

That said, I run a Chimaera VM with pi-hole and unbound inside my Daedalus box.
There is a DNS cache but it is mine.
It can be flushed though the UI.

Best,

A.

Hello:

I used to think more or less along the same lines.
But after reflecting on the matter (on and off fashion) I came to the conclusion that he may be an asshole, an idiot of sorts too.

---> But he is quite clearly a capable developer / programmer. <---
Just why do you think he is working for YouKnowWho?

I'd try to avoid continuing to underestimate Poettering, at your+everyone else's peril.

What I once labelled as being an asshole+idiot was the result of my frustration at what was going on.
But then I realised that it was my reaction (questionable and angry ad hominem manner) against the fact that he had evidently been working to infect Debian with the infamous systemd* for quite a long time, maybe years.

You do not come up with such complex shit overnight, no matter how capable you are.

After that, he outed himself by openly going to work for MS, where he now continues with the classic +30 year old Embrace Extend and Extinguish process we are all familiar with, process that he surely started from inside Debian much before systemd was ever heard of.   

* nothing but an MS registry for the Linux ecosytem

And here we are.

Best,

A.

Hello:

The changelog file in pluma_1.26.1-2.1_amd64.deb does not seem to mention it (?): 

### pluma 1.26.1

 * Translations update
 * Fix out-of-bounds write
 * Fix double activation of extensions
 * pluma-plugins-engine: fix memory leak

### pluma 1.26.0

 * Translations update
 * filebrowser-plugin: fix segfault on open-terminal action
 * update copyright to 2021
 * build: fix shebangs
 * warning: declaration of  shadows a global declaration
 * pluma: Use EXIT_SUCCESS macro instead of int value (portability)
 * help: update help for sort plugin
 * sort plugin: Port sort plugin to the new GtkSourceView api.
--- snip ---

Cannot be tested in Daedalus; GDebi won't install -> non-satisfiable dependency: gir1.2-pluma-1.0 (=1.26.1-2.1).

Best,

A.

Hello:

Sure, no problem with that.

Thanks for that info.

Of course, always.

But ...
On one hand, I have not heard from anyone (yet) with the same issue and on the other, I have not been able to reproduce it.
Not has it happened again.

What I know for sure is that I had not ever seen it happen before the last two Firefox *esr updates.
ie: the versions without the upper left hand View recent browsing across windows and devices icon.

Can that new crap feature be disabled?

And then it may be a fluke, a hardware problem or worse, allucinations. 8^°
No idea, but I don't like it.

Thanks for your input.

Best,

A.

Hello:

That is quite correct.

But sudo does have a great many proper use scenarios.
eg: every time I want to have a look at what dmesg is printing out or run updatedb.

Here are a couple of snippets from an article by one of the admins in the PCLinuxOS Magazine back in 2012:

* undelining is mine.

I'd say that allowing members of group sudo to execute any command is a huge risk.
Not a convenience.

Of course and as always, YMMV.

Best,

A.

Hello:

It should.

In my case, I first made sure I purged all / everything exim4 related from my system, rebooted to make sure and then and installed DMA.
Had no issues, my system mail works perfectly well and a little old thingue called coolmail* sits in a corner on my desktop and lets me know when any system mail gets delivered to my box.

It got/gets installed by default in all (?) Devuan editions.

System mail was, till my exim4 incident, something absolutely transparent to me.
No idea it was called exim4, much less how complex it was.

Think a Norton 500 instead of a single speed rear-coaster brake cycle to go for your order of onion bhajis four blocks from your house.

I have put forth here at Dev1 that it would be a good idea to replace exim4 with DMA as the default MTA in all Devuan releases, with the exception of (maybe) server. ie: desktop-live, netinstall, desktop and minimal-live.

The logic behind that idea is that if a user knows about and needs whatever advantage exim4 has with respect to DMA, they will install it.
Otherwise, their system's MTA will be absolutely transparent to them. ie: it will just work as intended.

The plus will be that they will have avoided the possibility of hassle and wasted resources.

* See here: https://dev1galaxy.org/viewtopic.php?pid=30487#p30487

Best,

A.

Hello:

Look again:

~$ apt list | grep dma
--- snip ---
dma/stable,now 0.13-1+b1 amd64 [installed]
dma/stable 0.13-1+b1 i386
--- snip ---
~$

See:
https://pkginfo.devuan.org/cgi-bin/poli … a&x=submit
https://pkginfo.devuan.org/cgi-bin/pack … =0.13-1+b1

Best,

A.

Hello:

Exim4 had a huge lot of issues at one point and it could be that (depending on your installed version / upgrade cycle) you are suffering them now.

You may want to have a read at this thread (specifically the last two posts) to get an idea of what may be going on in your box.

https://dev1galaxy.org/viewtopic.php?pid=30412#p30412
https://dev1galaxy.org/viewtopic.php?pid=30469#p30469

That said and unless you really need something as complex as exim4 running in your box, you may want to consider using a simpler, much lighter and less complicated MTA such as Dragonfly.

See this thread and the DragonflyBSD web page.

Best,

A.