Hello:

Right ...

It would seem that those of us who had something to say have already said it and in the best possible way.
Whether it made any sense or helped at all is up to the OP and how he processes it.

But beyond that, there's no need to keep picking on the chap.

I'd like to think that we are better than that.

Best,

A.

Hello:

Thanks for the heads up.
I'll check it out.

I really don't know if I need it.
Because I don't know how much the threat scenario has evolved.

If it has evolved (high probability), goes to reason that newer version would address it.

Me?  8^D
Been in this far too long for that.

Yes, I could.

But first I have to make 100% sure my nvidia cards will work properly and I will still be able to use slim and wicd, among other old stuff I have installed and then comfortably get rid of the POS that Xfce is slowly turning into to get myself a set up like what Phillip Newborough's #! Waldorf* was.

* which I think should be the default template for both Devuan desktop-live and installer-iso versions.

Yes, I know. 8^°

Thanks a lot for your input.

Best,

A.

Hello:

I have followed this thread on and off, more than anything out of curiosity and to see just how far it would go.

There's not much to add to the more than suitable/correct answers you have received, save this:

I take personal exception to the tone in your posts, which I consider both unwarranted and absolutely out of place.
I would appreciate your showing more respect to those who volunteer their time and efforts to keep both Devuan and this site working.

I'm sure my words represent the opinion of an overwhelming majority here at Dev1, so please do take them into account.

And stop behaving like a five year old.

Best,

A.

Hello:

What Devuan version are you running and what mirrors are you using?

Please post the output of uname -a and cat /etc/apt/sources.list.

Also, have a look at this page.
ie: the "Default configurations" list

Best,

O.

Hello:

+1
With all the crap permanently being crammed into the kernel (much of it without comment), compiling the kernel will eventually become a must do for many.
ie: you end up finding out about them long after the fact when you have look at dmesg or system logs, something I do often.
That's what they are there for.

Well ...

Probably because there are quite a bit of aspiring Poetterings amidst the Debian devs/maintainers.
Fortunately there are ways to avoid loading them, for the time being.

I never got around to doing that.
Too much time and energy needed.

A.

Hello:

You're welcome.

Right.

But first I'll ask you to edit your previous post so that the terminal output is seen as code.
That way it is easier to see and check separately from the text.

To do that, you have to add the code and /code tags to the start and end (respectively) of the output you copied/pasted on the screen.

Do a preview and check if it is seen like this:

Linux devuan 4.19.0-22-amd64 #1 SMP Debian 4.19.260-1 (2022-09-29) x86_64 GNU/Linux

Best,

A.

Hello:

You would be if you had taken the time to read the whole thread.  8^D

Best,

A.

Hello:

Yes.
But then you upgrade the kernel and there it is again.

At least that's what happens to me (Beowulf with backported kernel) when I upgrade the kernel.
Even though my kernel command line clearly says apparmor=0 (!)

What I always do is purge apparmor after the upgrade and before rebooting and make sure the kernel comand line has not been edited.

[root@devuan ~]# apt purge apparmor

If it is now a module, one sure way is to blacklist it.

Check if you have some other stuff called tomoyo, another gift from the Debian devs.
You have to add security=none to the kernel command line to avoid that one.

See these two three posts:

https://dev1galaxy.org/viewtopic.php?id=2630
https://dev1galaxy.org/viewtopic.php?id=4329
https://dev1galaxy.org/viewtopic.php?id=4750

Best,

A.

Hello:

You're welcome.

All the hardware works properly?

Yes, I'd say those are more or less standard.
Like this one I have in my box:

[ 1.324984] acpi PNP0A08:00: ignoring host bridge window [mem 0x000d0000-0x000dffff window] (conflicts with Adapter ROM [mem 0x000ce000-0x000d3bff])
[ 1.327999] pci 0000:00:1f.0: quirk: [io  0x0800-0x087f] claimed by ICH6 ACPI/GPIO/TCO

This type of memory conflict is due (so I have had explained to me) to a badly written BIOS.

As the kernel evolves, these messages/warnings also evolve/change.
In time, some messages end up going away.

This is all crud generated by the fact that OEMs and BIOS writers are ruled by what MS wants and nothing else.

But this should not happen, much less in a box like mine, a Sun Microsystems Ultra24 WS which was released 15 years ago (10/2007) with the most basic configuration going for ~ US$1.000, a very hefty price tag at the time. (I purchased it used in 2011, of course)

OEMs (Sun included) didn't/don't give a monkey's toss if the BIOS they slapped together from bits and pieces of other older ones does or does not comply with what ACPI says in their specifications, as long as it certifies for hardware that ships with Windows OSs.

And if they have to do it the MS way because the ACPI way does not play ball with the currently shipping Windows OS, they just do it.
Otherwise their hardware will not be "Windows Certified", which means that it won't sell.

That's about it, you have to endure it.
Till we get open source BIOSes and that will be the end of it.

But I really don't see it coming any time soon.

Best,

A.

Hello:

If everything works properly ...  8^°

But just for curiosity's sake, you can have a good look at your dmesg printout and see if there are any ACPI errors.
Run this and see what you get:

sudo dmesg | grep -i "error\|warning\|fail\|segfault\|fatal"

Bear in mind that some ACPI errors are a permenent fixture in older boards but the kernel takes care of it:

user@devuan:~$ sudo dmesg | grep -i "error\|warning\|fail\|segfault\|fatal"
--- snip ---
[  0.021101] ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: 128/64 (20200925/tbfadt-569)
[  1.318080] ACPI BIOS Error (bug): Could not resolve symbol [\_SB._OSC.SUPP], AE_NOT_FOUND (20200925/psargs-330)
[  1.318088] ACPI Error: Aborting method \_SB._OSC due to previous error (AE_NOT_FOUND) (20200925/psparse-531)
--- snip ---
user@devuan:~$ 

I don't use suspend or hibernate and as my Sun Ultra 24's BIOS is an absolute POS, I have to bear an ocassional, totally random and non-reproducible shutdown issue which I think is related to some internal temp sensor and how it interacts with the box's ventilation.

Best,

A.

Hello:

Besides following HoaS' instructions, to may find this link (or parts of it) useful.

Best,

A.

Hello:

No ...
Gods forbid.  8^°

In my opinion, the term obsolete is a (highly) relative one.

And like many other things in life, it all depends.

eg:
I have heard my (much younger) colleagues say that if you don't know CAD (I refused to ever use it) you are obsolete as an architect.
Somehow they have developed the idea that if you know how to use CAD, not only it turns you into an architect but a good one at that.

But what happens when power goes down, their software goes south just because liucence or whatever or they lose their day's work due to HDD problems?

I'll keep drawing free-hand or with my wooden T-square, triple scale and squares on my drafting table.   
And quickly draw up a set of multi direction internal/aerial views of the project, something which they never learnt how to do without CAD.

I will be able to see and explain the whole project, not just a small sector on a screen, and anyone with a set of eyes will be able to understand it.

So ...
Just who became obsolete in an instant?  8^\*

But I digress ...

Indeed, here.(?)
Some backgound also.

Seems like very good quality work, had not seen it before.
IMO, if at all possible, it would be great to add a strictly Devuan version (a meta package?) to the repository as a tool to set up Openbox/Tint2 as the default Devuan desktop.

ie: for those of us who appreciate obsolete things for their true value.

Best,

A.