You are not logged in.
Hello:
... Chimaera ...
Right.
... kernel version is not really relevant here, is it? ...
No.
But I like to see what the output says, just habit.
deb http://deb.devuan.org/merged chimaera main contrib non-free deb http://deb.devuan.org/merged chimaera-updates main contrib non-free deb http://deb.devuan.org/devuan chimaera-proposed-updates main contrib non-free deb http://deb.devuan.org/merged chimaera-security main contrib non-free deb http://deb.devuan.org/merged chimaera-backports main contrib non-free
Seems correct.
I would not use devuan chimaera-proposed-updates, because proposed.
Obviously, YMMV.
I think the explanation could be here.
Devuan has a network of package repository mirrors in place. The mirror network is accessible using the FQDN "deb.devuan.org" via http NOT https. Country Codes (CC) are currently unavailable but a specific mirror from the list can be accessed using the corresponding BaseURL.
The list is here.
There is/maybe some issue with FQDN "deb.devuan.org" and how/when it connects to debian.bio.lmu.de.
You could be able to solve the problem by following the suggestion above.
ie: ... a specific mirror from the list can be accessed ...
Best,
A.
Hello:
... boot in console mode then "startx".
... no "X" involved yet.
The first thing I'd do would be to check the logs.
/var/log/Xorg.0.log in particular.
I use a pair of older nvidia cards (Quadro FX580) with three monitors and legacy 340.108 drivers from nvidia.
Although it is supposed to be able to work without it, I have never been able to do it without a properly configured xorg.conf.
To the extent of using the same xorg.conf for the last seven years or so and over three different distributions.
With Devuan since 2017.
Best,
A.
Hello:
... remind my colleagues of the ancient optimization algorithm ...
... assembly of the kernel for specific conditions ...
+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.
... an example ...
... modules in the kernel waiting for apparmor and tomoyo.
... have neither one nor the other, why load them ...
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.
... already played enough in the compilation ...
I never got around to doing that.
Too much time and energy needed.
A.
Hello:
Thanks ...
You're welcome.
Sorry, doesn't take long ...
No need.
Absolutely no one is born knowing. 8^)
The code and /code bits have to be put between brackets ie: [ ], like all the other ones you see at the top following "Post a reply - ".
Find your post with the terminal output, click on Edit and add the flags.
You can also select multiple lines (ie: paint) and click on the flag you want to use and all that you painted will start and end with the proper flag.
Best,
A.
Hello:
THanks ...
You're welcome.
output here ...
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/LinuxBest,
A.
Hello:
Linux newbie ...
Right.
Most important when asking for assistance is to provide as much information as possible.
Devuan is mostly what people ask about here.
But it could be Devuan Chimaera 4.0 (stable) or Devuan Beowulf 3.0 (oldstable) or maybe an older version.
It would be a start in the right direction but not enough.
No one here can see your deskop (eventually but not just yet) so they will need to know a bit more than that ... 8^°
So, for starters, please post the terminal printout result of this:
~$ uname -aAnd these:
~$ apt list | grep installed | grep desk~$ sudo dmesg | grep -i "error\|warning\|fail\|segfault\|fatal\|not"All the information you post will enable those who can help you to actually be able to do it.
Best,
A.
Edit: grammar, syntax, etc.
Hello:
Is it really needed to have boot command security=none ?
... was not aware of this extra step.
You would be if you had taken the time to read the whole thread. 8^D
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.
Best,
A.
Hello:
so, solution here is remove apparmor?
What is wrong with apparmor?
Please take a few minutes and read the thread and the content of the links posted.
As I see it, both questions have already been answered.
As always, YMMV.
Best,
A.
Hello:
What about
apt remove apparmor
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:
... manually install some x32 packages, my Devuan Ceres x64 is broke.
Devuan Ceres is unreleased/unstable. ie: where developers refine and stabilize the latest package versions.
It will break because that is what it does best.
In my opinion, your best bet is to reinstall from nought or use a stable release to avoid this type of issues.
Best,
A.
Hello:
Thanks ...
You're welcome.
... most ... ... are related to missing firmware.
All the hardware works properly?
... couple are related to ACPI ...
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/TCOThis 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:
... fantastic if Devuan could inherit and revive ...
I beg to differ, it would be anything but fantastic.
Please don't take it personally but I find it really hard to get my head around what you are proposing.
Devuan quite definitely does not need to inherit other people's projects or invest time and manpower to revive anything.
Much less something that no one else seems to have any interest in.
What the Devuan project needs, in the face of its present situation, is to manage to stay alive.
Like I recently posted elsewhere:
I'm quite sure there are a great many areas where your expertise could be very useful to the Devuan project.
The most delicate part of the balance the Devuan project has achieved is related the dependency it has on Debian.
eg:
As most of us know, Debian's systemd brainchild (pun intended) has left Debian and now works for MS.Now, if in spite of his having left Debian, Poettering's accolytes decide to continue to push things even further and eventually manage to alter that delicate balance, the Devuan project will undoubtedly be in great danger.
ie: Debian software which now can run on Devuan thanks to the efforts of the Devuan developers/maintainers could directly cease to be available or be too time-expensive for the project's team to adjust them to the systemd-less Devuan.
Eventually, Devuan would have no applications to run and cease to exist.
And, as you surely grasp, that is something that would affect all Devuan based distributions.
The Devuan project cannot under any circumstance afford to undertake this sort of thing.
Makes no sense at all.
What the $%#" for, to what end?
As if it does not already have more than enough on it's developer's/maintainer's plates.
Like I said: the Devuan project, first and foremost, needs to be able to survive.
And that, by itself, is a huge undertaking.
And if it can be pulled off, it will truly be a huge accomplishment.
Best,
A.
Hello:
... noticed that ACPI 2.0 is disabled by default.
Should I enable it ...
... computer shuts down, hibernates, and suspends normally ...
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:
... refers to Arch's udev hook.
Debian does not use the same methods as Arch ...
Indeed ...
I noted that after posting but forgot all about it.
Sorry about that.
... so the statement is irrelevant.
Quite so.
But I'm sure it had not escaped you that the OP had already answered my post.
And in doing so, gracefully pointed out the difference between Debian and Arch to me.
Nevertheless, thanks for your input. 8^D
Best,
A.
Hello:
Welcome to Dev1. 8^)
Devuan has saved the day many times for me ...
Indeed.
I dare say for all of us here.
... able to contribute back in some way to further advance the adoption of Devuan.
I'm quite sure there are a great many areas where your expertise could be very useful to the Devuan project.
The most delicate part of the balance the Devuan project has achieved is related the dependency it has on Debian.
eg:
As most of us know, Debian's systemd brainchild (pun intended) has left Debian and now works for MS.
Now, if in spite of his having left Debian, Poettering's accolytes decide to continue to push things even further and eventually manage to alter that delicate balance, the Devuan project will undoubtedly be in great danger.
ie: Debian software which now can run on Devuan thanks to the efforts of the Devuan developers/maintainers could directly cease to be available or be too time-expensive for the project's team to adjust them to the systemd-less Devuan. ..
Eventually, Devuan would have no applications to run and cease to exist.
And, as you surely grasp, that is something that would affect all Devuan based distributions.
In my opinion (YMMD) the Devuan project does not need to find a way for Debian based distibutions to be easily converted to Devuan.
The Devuan project, first and foremost, needs to be able to survive.
And that, by itself, is "... a massive undertaking".
If the Devuan project can manage that, everything else will fall in place by itself.
... input or suggestions are very welcome
Done.
Best,
A.
Edit: spelling/syntax
Hello:
... not trying to stir up anything ...
No ...
Gods forbid. 8^°
... do like obsolete software ...
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 ...
... still find the 11.1.0 ISO of SharpBang from last October ...
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.
Hello:
I never had the pleasure of using #!
Then see if you can get yourself an install or live *.iso.
Just to try it out and see how very good it was.
The Waldorf version may be a bit dated but should without issues run on common 4/5 year old hardware.
ie: not bleeding edge stuff.
It was (at the time) a real eye opener for me and led me straight to Devuan.
... would appear to me that both the Star and Crowz derivatives of Devuan are similar to what #! was?
No idea, have never tried/installed them.
I may have downloaded them both (when I was looking for a new distribution to replace Mint/PCLinuxOS, etc. and burned the *.iso to a stick.
But if after all the routine checks (file and media) it did not boot the first time around, I would discard it from the list.
I stopped looking when I found Devuan.
And I will stay with it even if the powers that be insist on Xfce.
I'll just see how I can manage to do things the #! way.
Or maybe the Devuan maintainers could eventually write up a script to set up a #! type desktop in Devuan.
ie: an Openbox meta package of sorts.
I seem to recall PCLinuxOS (?) had a meta package for installing PegasusMail which pulled in all the necessary files and configurations to set it up along Wine.
Very neat, simple and straightforward as you did not have to wrangle with Wine.
Best,
A.
Hello:
... doesn't fix all of it unfortunately.
Indeed ...
It only fixes (not a fix, just a way of avoiding it) the having screwed things up by using CSE in the first place.
There are so many things they could be dedicating time to fix.
But no, skinny bars and CSE it is.
--> Seems they have their own Poeterings at xfce HQ's.
O.
Hello:
More GTK3 ...
... intractable CSD ...
... skinny bars ...
... less usable and fuglier cluster ...
Quite so ...
... IMO ...
And also mine.
I opine that it should not be the default for Devuan.
O.
Hello:
... on the condition that this project does not "die".
If you are referring to Devuan, I doubt it will die.
What is dead to me and (from what I have read) quite a few xfce users is xfce in any form after 4.12.2.
The path the developers have taken, the useless bloat and all the unfixed issues (compositor leading the way) made me decide not to upgrade further.
Not to mention the Poetteringesque attitude from the developers.
https://forum.xfce.org/viewtopic.php?pid=56141#p56141
https://forum.xfce.org/viewtopic.php?pid=56143#p56143
https://forum.xfce.org/viewtopic.php?pid=56144#p56144
Still have to decide what to use, the strongest/more suitable option I see being Openbox if and when I upgrade to Chimaera.
I think it should be the default Devuan desktop from Chimaera onwards.
ie: with a desktop as similar as possible to what Philip Newborough's CrunchBang project was.
Unfortunately, CrunchBang developement was ended by it's developer back in 02/2015. It was (YMMV) one of the best distributions at the time.
Best,
A.
Hello:
OMG I hope not.
+1
Best,
A.
Hello:
... from installing debian on a day to day laptop and over a dozen eee ...
The same stuff I have.
A Sun Ultra24 and an Asus 1000HE with 2Gb RAM and 500Gb HDD.
Gnome keyring optionally protects you from lazy login security risk on regular laptop.
I see.
Please excuse my ignorance in this specific matter (there are others but I digress ...)
I have gnome-keyring in my U24's Devuan installation but I see that I also have a few other keyrings.
debian-archive-keyring
devuan-keyring
python-keyring
python-keyrings.alt
python3-keyring
python3-keyrings.altUntil my issues with Back-in-Time, all this keyring thing had always been transparent to me, to the extent that I don't really know what it does.
The cron job running BiT sends a warning every so often (can't reproduce) but the job gets done with no problems and that is why I'm looking at gnome-keyring now.
I have read that BiT has to see at least one of these is installed: python-keyring-kwallet, python-secretstorage and python-gnomekeyring.
Of those three, my installation has python-secretstorage but has a problem if gnome-keyring is not there.
Maybe I should purge gnome-keyring and install python-gnomekeyring?
If gnome-keyring bothers you, remove it ...
Not really bother, just that with the exception of gnome-disks which I use every so often, I am sort of allergic to gnome so I'd rather avoid it.
But gnome-disks does not depend on gnome-keyring.
Thank you for your input.
Best,
A.
Hello:
Any ideas as to how I can troubleshoot this?
I rolled back and reinstalled gnome-keyring.
The same gnome-keyring that, along with gvfs-backends is a recommends of pcmanfm.
And that fixed it:
groucho@devuan:~$ keyring get system username
groucho@devuan:~$ keyring get system username opens up a window asking for a PW.
Edit:
The window name is Unlock Login Keyring and the contents reads:
------
Enter password to unlock your login keyring
The login keyring did not get unlocked when you logged in to your computer.
Password: . .
------
I had previously tried using the gnome-disks application without gnome-keyring installed and it worked perfectly well: I was asked for a PW to mount a drive.
There were no problems with gnome-keyring not being installed.
But why is this so?
Anyone has a clue about this?
Why isn't gnome-keyring a dependency if it is needed?
Which would beg the question: why is gnome-keyring needed if there are a few other keyrings installed?
debian-archive-keyring
devuan-keyring
python-keyring
python-keyrings.alt
python3-keyring
python3-keyrings.altI searched yet some more and found a lead here:
... realized that the problem was not limited just to Docker, any services using libsecret were broken. As I use KeePassXC with libsecret integration I took a look in the settings and it turns out the integration was disabled. I purged the gnome-keyring package again, killed the gnome-keyring service and enabled the KeePassXC integration and it all worked as usual.
I'd appreciate some insight on this.
ie: why must I have gnome-keyring installed.
Thanks in advance.
Best,
A.