You are not logged in.
Hello:
Well that in of itself would explain the problems.
Methinks you nailed it. 8^°
Best,
A.
Hello:
... simply using npt.
No graphical tool ...
Around 12/22 I set up a cron job at /etc/cron.daily/dev-ntpdate to set time for my box.
Not my doing, picked it up somewhere along the line but cannot remember where.
Added my comments to make sure I had an idea as to what was going on.
It logs to /var/log/syslog
------
#!/bin/sh
# added to set time via ntpdate daily
# invoke ntpdate to set time from system clock
# -4 Force IPv4 DNS name resolution
# -6 Force IPv6 DNS name resolution
# -s Log to syslog
# -t N.N Specify timeout
if [ -x /usr/sbin/ntpdate ]; then
/usr/sbin/ntpdate -4 -s -t 5 pool.ntp.org
fi
------Here is today's log entry:
--- snip ---
Jan 28 06:23:24 devuan ntpdate: CLOCK: time stepped by -2.595612
Jan 28 06:23:24 devuan ntpdate: 2026-01-28 06:23:24.808991 (-0300) -2.595612 +/- 0.002286 pool.ntp.org 170.155.148.1 s2 no-leapOnly issue I had was around mid last year due to some command (-u?) having been deprecated.
Aside from that, it has worked properly.
Best,
A.
Hello:
Have a read ...
From Forbes:
Microsoft Gave FBI Keys To Unlock Encrypted Data, Exposing Major Privacy Flaw
https://www.forbes.com/sites/thomasbrew … pted-data/
TL;DR
“If Apple can do it, if Google can do it, then Microsoft can do it.”
Matt Green, associate professor at Johns Hopkins University
From The Register:
Surrender as a service: Microsoft unlocks BitLocker for feds
If you're serious about encryption, keep control of your encryption keys
https://www.theregister.com/2026/01/23/ … microsoft/
TL;DR
"... a clear message to activist organizations and law firms that Microsoft is not building their products for you."
* the epitome of understatements if anything at all
Both articles point to a huge elephant in the room:
Who in their right mind (and having but the most basic common sense) would entrust Microsoft (et alia) to keep their encryption keys safe?
ie: available to you and to you only.
Best,
A.
Hello:
... not Devuan's fault, Devuan is unsystemded Debian.
+1
Best,
A.
Hello:
I just use my on-board sound hardware for the basics, but been following this thread to see if I learn something. 8^°
... the system in some fashion sees the UMC204HD and UMC404HD cards ...
... with the same name...
Out of curiosity ...
How does the system ID the USB sound card/s when you open a terminal and execute:
$ lsusbJust a guess, there may be a clue in the printout.
Or not.
Best,
A.
Hello:
... "YouTubes" on eating laundry detergent, that doesn't make it a good idea.
8^D !!!
Thanks for the laugh.
Best,
A.
Hello:
... a dell precision T5600 ...
... broken windows os and a defective debian install, nothing bootable.
Right ...
Q1: do you need to recover any glass from that broken window?
ie: data you may need because you don't have/cannot find a back-up.
Q2: do you (for whatever reason) want to double boot on your T5600?
If the answer is no to both, you may want to consider doing a thorough clean-up and run tests before installing Linux.
ie: nuke any/every partiton on the HDD, re-format and run a comprehensive memtest.
From your OP it would seem that you are able to boot from a USB, so I expect that you should be able to get that done without issues.
Once you have your box set up and properly tested you can go ahead and install Devuan on it.
Thrashed Windows installations always leave a lot of crud behind.
Caveat:
Your T5600 is probably BIOS/UEFI so read up on the pertinent instructions for installing Linux on it.
eg:
Things like disabling secure boot, setting SATA to AHCI and boot mode to BIOS or UEFI.
To start off see here:
https://www.dell.com/support/kbdoc/en-u … nux-system
Best,
A.
Hello:
... something to do with apparmor, but haven't a clue as to what to do ...
Get rid of apparmor and the rest of that crap?
https://dev1galaxy.org/viewtopic.php?id=5317
https://dev1galaxy.org/viewtopic.php?id=2630
https://dev1galaxy.org/viewtopic.php?id=4329
https://dev1galaxy.org/viewtopic.php?id=4750
As always, YMMV.
Best,
A.
Hello:
Sorry for the OT, will be brief.
... installed mate as another desktop environment ...
So ...
You just did ...
# apt install mate... and that was it?
No issues with XFCE?
Best,
A.
Hello:
any specific feature that makes it ...
That is the question I have been wanting to see an answer to for a good while now.
Still waiting ...
NB: I am not a fan of new/shiny just because it is out there.
Besides that, X is not dead or abandoned, not by a longshot.
At least from what I have seen lately.
And it is mature and proven code, isn't it?
No, new for the sake of newiness is not for me.
ie: I firmly believe that it is the root of all enshittification.
Best,
A.
Hello:
... best fix/workaround would be to setup a cronjob for .xsession-errors cleaning ...
This solution came from Daniel López Azaña's blog.
I just relayed the message, so to speak.
There is also a page called [crontab.guru] where you can check your [crontab] syntax, among other things.
Go have a read, it is very comprehensive and useful to have in the browser bookmarks.
Here is how I do it, works a charm:
See man [crontab] on how to edit it.
# Entries added to keep log files from growing too large
# http://www.daniloaz.com/en/how-to-prevent-the-xsession-errors-file-from-growing-to-huge-size
#
# Set logfiles to 2Mb and 200 lines max. checking for size every 23 hours
# see https://crontab.guru/#0_*/23_*_*_*
#
# File size examples:
#
# 150Mb -> 150000
# 100Mb -> 100000
# 15Mb -> 15000
# 10Mb -> 10000
# 5Mb -> 5000
# 2Mb -> 2000
#
# to test cronjob run at 2 min intervals
# example -> */2 * * * * echo "No systemd here"
#
# For /home/user/.xsession-errors
#
# ---
0 */23 * * * [ $(du -k .xsession-errors | awk '{ print $1 }') -gt 2000 ] && tail -200 /home/$(whoami)/.xsession-errors > $
# ---The above entry will keep the file under 2mb and when it grows over that limit it will clean up, keeping the last 200 lines.
2Mb of [.xsession-errors] is a lot of text.
eg:
Just now I see that my system's [.xsession-errors] file has 7249 lines and weighs in at a bare 784KiB.
Note:
I have looked at the glibberish that makes up the [.xsession-errors] file once or twice.
I could not make any sense from it and the system apparently worked properly.
And if it did not, I was never the wiser for it. 8^°
What it is useful for is to see just how much unfixed/crap code is routinely swept under the rug.
You know, all that [won't fix] stuff because [whatever].
The thing is that the main issue for most any Linux user is that the bloody file runs wild.
And if not checked, can grow to ridiculous sizes and cause problems.
Best,
A.
Hello:
... is flooding .xsession-errors ...
See these two posts (as well as the other ones in the thread)*:
https://dev1galaxy.org/viewtopic.php?pid=12265#p12265
https://dev1galaxy.org/viewtopic.php?pid=45348#p45348
TL;DR:
... xsession-errors are just a part of life so the thing is to keep the log files from growing.
* the Search function we have here at [dev1] can be, more often than not, quite useful.
Best,
A.
Hello:
... not used one of them systems in good decade ...
Have not had to deal with the UEFI crap.
I expect this box to last me at least another five/seven years without having to do much.
Who knows what I will be up to by then.
[OT]
My first SCSI drives ever were pulls from decommissioned IBM servers destined to be cut in pieces with a blowtorch.
A lot of eight 9.1Gb 68pin U160 HDDs purchased for a song from a usual suspect: the bloke in charge of the blowtorch.
On testing, only one was faulty.
Around six years later, when I upgraded box+HDDs to SAS, five (IIRC) were in perfect working order, no defects.
I actually made a profit selling them to a chap who ran a CT scanner service.
Good hardware is good hardware, there's no two ways about it.
[/OT]
... OS-prober is probably not enabled ...
... prevent the update-grub from checking for other OSs ...
Yes, that was it.
Problem solved.
Had forgotten to disable timeshift and backintime on the cloned drive so I'll have to check if and what was done.
Noticed that I had also neglected to to change display background so as not to forget which system I was working on. 8^°
Now to see about the XFCE surgery ...
Thank you for your input.
Best,
A.
Hello:
... in the grub.cfg in the EFI partition ...
Well ...
Fortunately for me, my Sun U24 WS is a BIOS boot (only) rig.
As I have no near-future plans to change this hardware, none of that UEFI crap for me.
The deed is done:
I have cloned my 120Gb SATA SSD system drive to a 300Gb SAS HDD and both have their own 'unique' UUIDs.
I can now run tests and experiment on getting rid of XFCE.
update-grub has been executed but it has not picked up the new system present in the cloned HDD.
I still have to check on that, I seem to recall that it stopped being the default action some time ago.
Thanks for your input.
Best,
A.
Hello:
Only the UUID is checked by the system when the UUID= is used in the fstab.
Filsystem uuids will end up in in grub.cfg if you use grub-mkconfig / update grub ...
Partition and disk uuids are, as you say, irrelevant ...
Good, got that straightened out.
Thank to both for your input.
Best,
A.
Hello:
... referencing them by UID.
... disks needs to be unique ...
Thought as much.
If I recall correctly, I've been doing it that way since [ascii].
What does number of partitions per drive have to do ...
Directly related to my ignorance in the matter?
But now I know that only UUIDs matter. 8^)
Thanks for your input.
Best,
A.
Hello:
Thanks for the prompt reply.
Yes, I have seen that you can use tunefs to change the UUID of a partition to a random/specific one, eg:
# tune2fs -U random /dev/sdb1 But what about those PTUUID and PARTUUID numbers?
They don't change in a source HDD / clone HDD scenario?
Thanks for your input.
Best,
A.
Hello:
Thanks for the prompt reply.
Boot from the clone drive, become root, then this command:
blkid /dev/sd* >> /etc/fstab
Right ...
... lists all disks and every partition on that disk with their respective UUID's in /etc/fstab.
Right.
$ sudo blkid /dev/sda* ## source HDD - edited for clarity ##
/dev/sda: PTUUID="0004a8f4" PTTYPE="dos"
/dev/sda1: UUID="d6841f29-e39b-4c87-9c52-3a9c3bafe2d3" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="0004a8f4-01"
/dev/sda2: PTUUID="bfb4d548" PTTYPE="dos" PARTUUID="0004a8f4-02"
/dev/sda3: UUID="f0187ff0-be52-4bbc-9461-40f744554b85" TYPE="swap" PARTUUID="0004a8f4-03"
/dev/sda5: UUID="c22304ec-0b30-428a-a6ac-500785614702" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="0004a8f4-05"
/dev/sda6: UUID="807e1ce7-72b4-48a3-8f34-65947ea9fd70" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="0004a8f4-06"
$ Yes, but ...
Doesn't the clone have the same UUIDs (filesystem/partition) as the source drive?
And as a result that data is already in each drive's identical /etc/fstab file?
From what I understand (?) the cloned drive needs a new set of UUIDs so that it is seen by the system as a different drive.
Not too sure but I expect that it would be like this:
clone /dev/sda <- needs new PTUUID
clone /dev/sda1 <- needs new UUID + PARTUUID
clone /dev/sda2 <- needs new PTUUID + PARTUUID
clone /dev/sda3 <- needs new UUID + PARTUUID
clone /dev/sda5 <- needs new UUID + PARTUUID
clone /dev/sda6 <- needs new UUID + PARTUUIDThe UUIDs of the other five drives need to remain exactly the same for both /etc/fstab files.
Thanks for your input.
Best,
A.
Hello:
The OEM* HDD in my U24 box went bad and had to be binned.
After recovering the platters, neodymium magnets and SS screws or course.
*A Seagate 250Gb ST32500NS which I had never had any trust in so it did not hold anything important.
After cleaning up/shuffling data between other HDDs I put a retired IBM-ESXS SAS 78Gb on-line to hold what was left.
Now I had a Hitachi Ultrastar SAS 300Gb 15K drive to use for cloning my system.
The idea being to see how to permanently extirpate XFCE and replace it with some other desktop environment or a WM.
Not sure yet what I'll do, this is just a test bed.
I cloned the system's Kingston 120Gb SSD (~29K hours, no problems) via clonezilla and tested by taking the SSD off-line to boot from the cloned drive. No issues to report.
So far so good.
Now, both HDDs have the same UUIDs.
As a result, they cannot live in the same box unless one of the drives gets new UUIDs.
I think (?) that is the case even if they are not in each other's /etc/fstab file.
Many years ago, I would install different versions W2000/SPSP3 on different HDDs and choose which one to boot from via the box's BIOS.
Later in Linux, I would install different distributions on two or three HDDs (one at the time, main one off-line) and GRUB from the main system drive would find it and give me the options to boot. Tricky but workable.
But now I have a clone which I want to boot from by choosing it from the GRUB screen.
Going into the setup and changing the drive priority would be a (cumbersome) option but then the issue of the duplicate UUIDs for all the partitions will surely cause problems.
So to start off, UUIDs have to be changed and that can be done with gparted but I have only done it on HDDs with a single partition.
Any pointers would be appreciated.
Best,
A.
Hello:
Thanks for all your hardwork, you and the entire Devuan team!
+1
Best,
A.
Hello:
... without playing a game, my system has been running smooth as always ...
Maybe "the proof is in the pudding"?
TL;DR:
Your box runs as well as it always has when there is no game software involved.
That being so, you may want to consider that there must be something going on with the combination [game/hardware].
Could be some game [*.conf] issue, game/hardware incompatiblity or just flaky programming*.
Not unheard of, shit happens all the time.
Best,
A.
* Except for the manual installation of 2 games that i wanted to try out ...
Hello:
An article about AI refusing commands ...
Along the same lines:
https://www.theguardian.com/technology/ … ogy-rights
What is really scary is how much crap some people are capable of spewing:
“People demanding that AIs have rights ... " WTHF?
While millions of human beings all over the world are denied basic human rights?
Best,
A.
Hello:
Merry Xmas. 8^)
A discussion thread on reddit ...
Having formed my opinion with respect to systemd many years ago (before settling on Devuan), the first thing that came to mind when I saw the title of this thread was that it should not be here but (if at all) in the [Index -> Discuss -> Off Topic] category.
More so if it is crossed linked to another thread on reddit with a title as bait-ty as the one linked.
Please don't take it personally: we have all been there at one time or another.
TL;DR
I doubt that anyone here at Dev1 hates systemd and like John Bercow*, most "couldn't give a flying flamingo" about it.
That said, I am certain that most everyone here knows all there is to know about systemd.
Which is why we run our boxes on Devuan Linux and belong to this forum.
As always, YMMV.
Best,
A.
* Speaker - UK House of Commons - 2009/2019
Hello:
Just a short note to wish one and every member of this forum a very Merry [ fill in ] and Happy [ fill
in ] *and* especially thank the maintainers / programmers / moderators and collaborators at Dev1 you for all the work you do.
Best,
Altoid
Hello:
... also updated Devuan Stable on my system.
Ahh ...
Therein lies the difference.
ie:
Devuan [stable] is now Excalibur, released 2025-11-02.
As a consequence, Daedalus is now [oldstable].
Thanks for your input.
Best,
A.