Posts by Altoid

Altoid · Hardware & System Configuration

Hello:

Now that I have a bit more time on my hands, I have decided to take up (once again) the troubleshooting of my Sun Ultra 24 BIOS and DSDT tables.
The BIOS in my box has a couple of annoying bugs:

1. a shutdown freeze with fans at 100%
2. a system restart after shutdown.

Both are of an absolutely aleatory nature and have never been able to reproduce them.
They just happen.

I strongly suspect that at least a part of the present situation is due to the fact that the board reports itself as being "Portable":

groucho@devuan:~$ sudo inxi -M
Machine:   Type: Portable System: Sun Microsystems product: Ultra 24 v: 0.00.01 serial: 0123456789 
           Mobo: Sun Microsystems model: Ultra 24 v: 50 serial: 3K08QG BIOS: American Megatrends v: 1.56 date: 01/21/2011 
groucho@devuan:~$

At ~ 16/19 kg. it quite obviously is not.

It IDs itself as being portable (probably) because the BIOS' ACPI FADT(Fixed ACPI Description Table) has the field PreferredPowerManagementProfile set to a value of "2" (Mobile) instead of any other value such as workstation, server etc. and this setting probably has some effect on what is going on.

But I digress ...

DSDT table modification has always been an area largely dominated by OSx enthusiasts wanting to run Apple's OS on x86 boxes, so Linux based tools are scarce.

But I have come across a Linux based application called ftws for which there are *.deb files (Ubuntu) available for download.
See: https://pkgs.org/download/fwts

I'd appreciate some guidance as to which to choose between the ones available for Ubuntu 18.04 LTS.

Thanks in advance,

A.

Altoid · Hardware & System Configuration

Hello:

Head_on_a_Stick wrote:

# wipefs -o 0x8001 /dev/sdb

Done.
Worked a charm. 8^D

gparted now reports as it should, like parted and gnome-disks do .
But then gparted does read from the drive itself, albeit data which is not correct and in doing so prevents it from being able to do anything on that drive.

Head_on_a_Stick wrote:

Altoid wrote:
It is an *.iso file I have used at one time or another.
Yes, probably.

Which brings me back to why this happened.
Any idea as to what may have caused it?

Thanks a lot for your help.

Cheers,

A.

Altoid · Hardware & System Configuration

Hello:

Head_on_a_Stick wrote:

They are created dynamically by udev.

I see ...
So udev reads data and creates the links on the fly.
That's why the pop up the instant I delete them.

Head_on_a_Stick wrote:

Can we see
wipefs /dev/sdb{,1}

Of course:

groucho@devuan:~$ sudo wipefs /dev/sdb{,1}
DEVICE OFFSET TYPE    UUID                    LABEL
sdb    0x8001 iso9660 2006-02-09-19-22-00-00  MAGIC_BOOT_DISK_V2_0
sdb    0x1fe  dos                                          
sdb1   0x438  ext4    49d1369c-ed70-4543-b0ee-ef65327e101b stuff
groucho@devuan:~$

That's it!
udev is reading the data held in the drive itself and gparted (unlike gnome-disks and parted) uses it.

The important question would be: just how did that label get wrtitten into the drive?
It is an *.iso file I have used at one time or another.

Thanks for your input.

A.

Altoid · Hardware & System Configuration

Hello:

fsmithred wrote:

... similar problem ...
... had to delete those links a few times.
... deleted /dev/sdd along with them.

Hmm ...
There is something strange going on here.

Because, just what is recreating these links the instant they are deleted?

I searched for the string with the last digits of the drive's UUID and found two files.
They were in /.local/share/gcfs-metadata.

There were also about 100 or so files of the same type, most dated 2018, 2019 and 2020.
So I got rid of them, to no avail.

The problem remains.

But hold on because the plot thickens considerably.

I then boot into my alternate (in construction) Beowulf 3.1.0 install to see if I can reach into the other installation's system files but I cannot see past /media/groucho/devuan/dev, even as root.

And here is the deal:

As I am writing this post from my alternate Boewulf installation and on a hunch decide to look further.
So I start gparted and what do I see?

I see /dev/sda (instead of /dev/sdb) with the very same filesystem (iso9660) and label (MAGIC_BOOT_DISK_V2_0) and UUID (2006-02-09-19-22-00-00) I see in my other Beowulf 3.1.0 installation.

Not only that, it turns out that (expectedly) /dev/disk/by-label/ has the same link, just to /sda instead of /sdb.
It is obviously the same drive.

What to do now?

Thanks in advance,

A.

Altoid · Desktop and Multimedia

Hello:

ralph.ronnquist wrote:

... your last posts and my edit crossed in time ...

Indeed ...

It's fixed.
Thanks again.

Cheers,

A.

Altoid · Desktop and Multimedia

Hello:

ralph.ronnquist wrote:

... improved the feature beyond useful again...

Happens.
We are all in the midst of some real bad shit these days.

ralph.ronnquist wrote:

... possibility the feature has just appeared.
Perhaps you, @Altoid ...

Of course.

I'll close this post and see again.

Cheers,

A.

Edit: yes, now it is there. Thanks @ralph.ronnquist for getting it fixed. 8^)

Altoid · Desktop and Multimedia

Hello:

ralph.ronnquist wrote:

... see a "Mark SOLVED" link near the top and one near the bottom ...

I had seen it referenced before (in other posts) but could never find it, so I do it manually.
No big deal.

Today I looked again after having my second espresso and cleaning my reading glasses, but no: there is no such animal to be seen here.
I do believe you see it, but it does not mean that it is actually there. 8^D !!! (just taking the pis ...)

I'd post a screen capture to prove it.
But I have not been able to convince the powers that be to make it an easy thing to do.
Uploading a SC elsewhere and linking to it in a post as a method to clearly/quickly illustrate something (because pix=1000 words) is rather a nuisance.

Cheers,

A.

Altoid · Hardware & System Configuration

Hello:

ralph.ronnquist wrote:

interesting.
... unless something has blessed the system with some special udev rules ...
... in /etc/udev/rules.d rather than /lib/udev/rules.d.

Way over my head.

ralph.ronnquist wrote:

... residue from some past "journey" in /etc/fstab? <- took the liberty of correcting fstan

My fstab (checked it just now) is clean, no residue.
Non relevant lines are properly commented.

# /swap partition in ssd
UUID=fb103b4c-e143-4432-a3a0-4883d288bddd  none  swap  defaults  0  0

# log partition in ssd
UUID=c22304ec-0b30-428a-a6ac-500785614702 /var/log ext4 defaults,noatime  0  2
#
# -------------------------------------------------------------------------------------
# backup repository in Seagate 300Gb SATA
# was LABEL=Backup /media/backups  ext4  defaults,noatime  0  2
UUID=ca8dbded-819d-4e2b-b017-0981a75ea718  /media/backups  ext4  defaults,noatime  0  2
#
# -------------------------------------------------------------------------------------
#
# not automatically mounted - root only
# storage repository in 300Gb SAS
# was LABEL=storage  /media/storage  ext4  defaults,auto  0  2
UUID=bdf33361-5929-433e-ac7f-1a626aa6e844 /media/storage ext4 nouser,noauto  0  2
#
# -------------------------------------------------------------------------------------
#
# not automatically mounted - root only
# storage repository in IBM 73Gb SAS  
# was LABEL=stuff  /media/stuff  ext4  defaults,auto  0  2
UUID=49d1369c-ed70-4543-b0ee-ef65327e101b /media/stuff ext4 nouser,noauto  0  2
#
# -------------------------------------------------------------------------------------
#
# added to be able to use USBView 2.0
# see https://slackbuilds.org/repository/14.2/system/usbview/?search=usbview
# in pclinuxos /etc/rc.d/rc.sysinit is supposed to mount it but for some reason doesn't
#
debugfs /sys/kernel/debug debugfs mode=755 0 0

Could it be the last line?

usbview 2.0 wrote:

14.2 > System > usbview (2.0)
USBView is a GTK program that displays the topography of the devices that are
plugged into the USB bus on a Linux machine. It also displays information on
each of the devices. This can be useful to determine if a device is working
properly or not.
For this program to be useful, you will need to mount the debug filesystem
(debugfs). Add this line to your /etc/fstab:
debugfs /sys/kernel/debug debugfs noauto 0 0
Now a simple `mount debugfs` will make the USB info available to USBView.
The debugfs root directory is accessible only to the root user by default.
You can grant access to the USB device info (as well as the rest of the
debugfs tree) with the "uid", "gid", and "mode" mount options. For example:
debugfs /sys/kernel/debug debugfs noauto,mode=755 0 0

Thanks for your input.

Cheers,

A.

Altoid · Desktop and Multimedia

Hello:

Ha!
This is a blast from the past. 8^D
Incredible how time goes by and some things never change.
I'm still as curmudgeonous as ever.

Micronaut wrote:

... proprietary driver in beowulf 3.1 ...
... same thing again.
... video performance seems to be fine.

I'm running Beowulf 3.1.0:

groucho@devuan:~$ uname -a
Linux devuan 4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30) x86_64 GNU/Linux
groucho@devuan:~$

The video drivers nvidia-legacy-340xx-driver and the desktop is the default Xfce 4.12.
And I'm still getting the udev errors in dmesg:

groucho@devuan:~$ sudo dmesg | grep install | grep nvidia
[    2.270084] udevd[99]: Error running install command for nvidia
[    2.279694] udevd[109]: Error running install command for nvidia
groucho@devuan:~$

But like when I first posted (2018!), save for the (annoying) artifacts I mentioned, video is running fine.
Some time after that post, I decided to blacklist the Intel mei module:

groucho@devuan:~$ cat /etc/modprobe.d/blacklist-mei.conf
# https://wiki.archlinux.org/index.php/Kernel_module
# blacklist mei
# to prevent loading if another non-blacklisted module requests it
# effectively blacklists the module and any other that depends on it.

install mei /bin/false
groucho@devuan:~$

# https://wiki.archlinux.org/index.php/Kernel_module
# blacklist mei_me

# to prevent loading if another non-blacklisted module requests it
# effectively blacklists the module and any other that depends on it.
install mei_me /bin/false

groucho@devuan:~$

And as a result, I get an exact copy of the udev error in dmesg, albeit referred to the mei module.

groucho@devuan:~$ sudo dmesg | grep udevd | grep install 
[    2.270084] udevd[99]: Error running install command for nvidia
[    2.279694] udevd[109]: Error running install command for nvidia
[   22.662626] udevd[436]: Error running install command for mei
groucho@devuan:~$

So I think it is safe to conclude that the udevd error in dmesg is most probably related to the proprietary nature of the nvidia-legacy-340xx-driver and something that is blocked from installing in order for it to run properly under Linux.

It may be related to the nvidia licence module:

groucho@devuan:~$ sudo dmesg | grep taint
[   22.765593] nvidia: loading out-of-tree module taints kernel.
[   22.766631] nvidia: loading out-of-tree module taints kernel.
[   22.777785] nvidia: module license 'NVIDIA' taints kernel.
[   22.789691] nvidia: module license 'NVIDIA' taints kernel.
[   22.801326] Disabling lock debugging due to kernel taint
[   22.828817] nvidia: module verification failed: signature and/or required key missing - tainting kernel
groucho@devuan:~$

With respect to the artifacts, they are only produced when logging in for the first time.
ie: killing the X server and logging in again does not produce the artifacts.
They can be reproduced by rebooting the rig and then logging in.

I recently upgraded the Quadro FX580 cards' BIOS thinking that it was a BIOS mismatch issue (had different versions) but the result was that the artifacts now look rather different but they are still there.

A clue as to where they may be originating arises from the fact that another Devuan Beowulf 3.1.0 installation I have in the same box ie: different drive but same OS, same cards, same drivers, same LM but no Xfce does not have them them.

In any case, I will most probably end up moving away from Xfce.
I do not like it too much but much less when I see what is going on with the upcoming 4.16.

I'd label this thread as [Solved], but I don't have permisson to do it.

Cheers,

A.

Altoid · Hardware & System Configuration

Hello:

ralph.ronnquist wrote:

... some dangling links in some /dev/disk/by-* directory?

Indeed ...
There was one labeled MAGIC_BOOT_DISK_v2_0 in the /dev/disk/by-label/ folder, linked to /sdb.
And also another link in /dev/disk/by-uuid/ labeled 2006-02-09-19-22-00-00 and also linked to /sdb.

So I opened the folders as root and deleted them.
But after a reboot they were there again.

ie: I delete them, close Thunar and when I open the folders the links are there again.
Seems that they are regenerated instantly.

Thanks for your input.

Best,

A.

Altoid · Hardware & System Configuration

Hello:

Running up to date Devuan Beowulf:

groucho@devuan:~$ uname -a
Linux devuan 4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30) x86_64 GNU/Linux
groucho@devuan:~$

My box has five different drives, /dev/sda through /dev/sde and I have a strange thing happening with gparted (v. 0.32.0).

fdisk

[root@devuan ~]# fdisk -l
Disk /dev/sda: 111.8 GiB, 120034123776 bytes, 234441648 sectors
Disk model: KINGSTON SV300S3
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0004a8f4

Device     Boot     Start       End   Sectors  Size Id Type
/dev/sda1            2048  40974335  40972288 19.6G 83 Linux
/dev/sda2        40974336 217677823 176703488 84.3G  5 Extended
/dev/sda3       217677824 234440703  16762880    8G 82 Linux swap / Solaris
/dev/sda5        40976384  45072383   4096000    2G 83 Linux
/dev/sda6        45074432 217677823 172603392 82.3G 83 Linux

Partition table entries are not in disk order.

Disk /dev/sdb: 68.4 GiB, 73407488000 bytes, 143374000 sectors
Disk model: VPBA073C3ETS11 N
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xbc66305b

Device     Boot Start       End   Sectors  Size Id Type
/dev/sdb1        2048 143372287 143370240 68.4G 83 Linux

Disk /dev/sdc: 279.4 GiB, 300000000000 bytes, 585937500 sectors
Disk model: ST3300555SS     
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x30830f4e

Device     Boot Start       End   Sectors   Size Id Type
/dev/sdc1        2048 585936895 585934848 279.4G  5 Extended
/dev/sdc5        4096 585936895 585932800 279.4G 83 Linux

Disk /dev/sdd: 68.4 GiB, 73407488000 bytes, 143374000 sectors
Disk model: GNA073C3ESTT0Z N
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xa88df1bd

Device     Boot     Start       End  Sectors  Size Id Type
/dev/sdd1  *         2048  39063551 39061504 18.6G 83 Linux
/dev/sdd2        39065598 127748095 88682498 42.3G  5 Extended
/dev/sdd3       127748096 143372287 15624192  7.5G 82 Linux swap / Solaris
/dev/sdd5        39065600  42969087  3903488  1.9G 83 Linux
/dev/sdd6        42971136 127748095 84776960 40.4G 83 Linux

Partition table entries are not in disk order.

Disk /dev/sde: 232.9 GiB, 250056000000 bytes, 488390625 sectors
Disk model: SEAGATE ST32500N
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x85188518

Device     Boot Start       End   Sectors   Size Id Type
/dev/sde1        2048 488388607 488386560 232.9G 83 Linux
[root@devuan ~]#

blkid:

[root@devuan ~]# blkid
/dev/sda1: LABEL="devuan" UUID="d6841f29-e39b-4c87-9c52-3a9c3bafe2d3" TYPE="ext4" PARTUUID="0004a8f4-01"
/dev/sda3: LABEL="swap" UUID="fb103b4c-e143-4432-a3a0-4883d288bddd" TYPE="swap" PARTUUID="0004a8f4-03"
/dev/sda5: LABEL="log" UUID="c22304ec-0b30-428a-a6ac-500785614702" TYPE="ext4" PARTUUID="0004a8f4-05"
/dev/sda6: LABEL="home" UUID="807e1ce7-72b4-48a3-8f34-65947ea9fd70" TYPE="ext4" PARTUUID="0004a8f4-06"

/dev/sdb1: LABEL="stuff" UUID="49d1369c-ed70-4543-b0ee-ef65327e101b" TYPE="ext4" PARTUUID="bc66305b-01"

/dev/sdc5: LABEL="storage" UUID="bdf33361-5929-433e-ac7f-1a626aa6e844" TYPE="ext4" PARTUUID="30830f4e-05"
/dev/sdd1: UUID="7a33fda5-abda-451b-b6ef-c17553c78810" TYPE="ext4" PARTUUID="a88df1bd-01"
/dev/sdd3: UUID="a806d014-08c4-4d12-87d2-0bd2a2bb60b4" TYPE="swap" PARTUUID="a88df1bd-03"
/dev/sdd5: UUID="f6b70140-07ab-4ff5-b5c5-d05ca2feb03b" TYPE="ext4" PARTUUID="a88df1bd-05"
/dev/sdd6: UUID="8a8a4242-b88a-45cb-b099-59138f895c16" TYPE="ext4" PARTUUID="a88df1bd-06"
/dev/sde1: LABEL="Backup" UUID="ca8dbded-819d-4e2b-b017-0981a75ea718" TYPE="ext4" PARTUUID="85188518-01"
[root@devuan ~]#

The problem is that gparted shows me /dev/sdb as a iso9660 file system labeled MAGIC_BOOT_DISK_v2_0 with a size of 68.37GiB.

Alternatively, gnome-disk-utility 3.30.2 reports it correctly:

Size: 73 GB (73405562880 bytes)
Device: /dev/sdb1
UUID: 49d1369c-ed70-4543-b0ee-ef65327e101b
Partition Type: Linux
Contents: Ext4

And running parted from a terminal also reports it correctly:

groucho@devuan:~$ sudo parted
GNU Parted 3.2
(parted) print list
--- snip ---
Model: IBM-ESXS VPBA073C3ETS11 N (scsi)
Disk /dev/sdb: 73.4GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  73.4GB  73.4GB  primary  ext4
--- snip ---

I have at some time mounted an *.iso file by the same name as the one reported by gparted using AcetoneISO but it was some time ago and it is not mounted now.
If I mount /dev/sdb, it shows up correctly:

groucho@devuan:~$ mount
--- snip ---
/dev/sda1 on / type ext4 (rw,noatime)
--- snip ---
/dev/sda6 on /home type ext4 (rw,noatime)
/dev/sda5 on /var/log type ext4 (rw,noatime)
/dev/sde1 on /media/backups type ext4 (rw,noatime)
--- snip ---
/dev/sdb1 on /media/stuff type ext4 (rw,relatime)
groucho@devuan:~$

Anyone knows what is going on with gparted?
Scared the daylights out of me when I saw it.

Thanks in advance,

A.

Altoid · Desktop and Multimedia

Hello:

Running on an up to date Devuan Beowulf:

groucho@devuan:~$ uname -a
Linux devuan 4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30) x86_64 GNU/Linux
groucho@devuan:~$

I have come across a problem in thunar which consists of it crashing when I want to "drag and drop" a file from a folder into another folder.
thunar crashes the instant I move the mouse to "drag" the file I am "holding" by depressing the mouse's right button.

This happens independently of the location/destination of the file.
ie: within folders in the same drive or from/to to another mounted drive.

"Drag and Drop" is not something I do very often so I cannot say when this started to happen, but it may have started after upgrade to 3.1.0.

/var/log/kern.log, /var/log/syslog and dmesg have a line (obviously the same one) for each time this happens:

Mar 13 14:13:38 devuan kernel: [25529.814724] traps: Thunar[3927] trap int3 ip:7f5fcdb41c75 sp:7ffd5aa20300 error:0 in libglib-2.0.so.0.5800.3[7f5fcdb09000+7e000]

And ~/$ .xsession-errors has this:

(Thunar:3927): Gdk-ERROR **: 14:13:38.788: The program 'Thunar' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 8499 error_code 3 request_code 141 (Composite) minor_code 8)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Any ideas as to to fix this?

Thanks in advance,

A.

Altoid · Installation

Hello:

F_Sauce wrote:

...probably find a better way ...

I'm not sure if it ended up being a better way but I think (at least) I solved the issues in the syslog and backintime-qt --debug outputs, which I think (?) were linked.

I just sort of followed what was done in this link https://github.com/jaraco/keyring/issues/391, a post by the same person who posted what I linked previously.

Apparently it all comes down to some problem in how backintime interacts with python-keyring.

I did this, not because I understood it well enough but out of faith in the solution posted by the chap who worked it out.
Hopefully I have not broken anything in the process:

1. created ~/.local/share/python_keyring/keyringrc.cfg which, as in the post linked, did not exist.

groucho@devuan:~$ cat /home/groucho/.local/share/python_keyring/keyringrc.cfg
# added 20210311
# see https://github.com/jaraco/keyring/issues/391
#
[backend]
default-keyring=keyring.backends.SecretService.Keyring
groucho@devuan:~$

By doing this, when I enter keyring get system username in a terminal I no longer receive a UI prompt to create a new kwallet keystore.
Because, why would I want to do that?
I don't use kwallet, I did not install it and do not I want to use it.
It probably came with a meta-package, can't really say.

Now it's clean, no kwallet prompt:

groucho@devuan:/$ keyring get system username
groucho@devuan:/$

After doing that and checking/double checking that I was not going to break anything, I decided to remove kwallet and all related files.
It was a huge hoard of kwhatever files...

Then I checked to see what was going on with backintime:

groucho@devuan:/$ backintime-qt4 --debug

Back In Time
Version: 1.1.24

Back In Time comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; type `backintime --license' for details.

DEBUG: [common/backintime.py:585 getConfig] config file: /home/groucho/.config/backintime/config
DEBUG: [common/backintime.py:586 getConfig] profiles: ['1']
DEBUG: [common/applicationinstance.py:73 GUIApplicationInstance.check] No PID file
DEBUG: [common/pluginmanager.py:88 PluginManager.load_plugins] Register plugin path /usr/share/backintime/plugins
DEBUG: [common/pluginmanager.py:104 PluginManager.load_plugins] Add plugin notifyplugin.py
DEBUG: [common/pluginmanager.py:104 PluginManager.load_plugins] Add plugin qt4plugin.py
DEBUG: [common/pluginmanager.py:104 PluginManager.load_plugins] Add plugin userscriptsplugin.py
DEBUG: [common/snapshots.py:953 Snapshots.has_old_snapshots] Found old snapshots: False
DEBUG: [common/tools.py:616 keyring_supported] Found appropriate keyring 'keyring.backends.SecretService'
DEBUG: [common/applicationinstance.py:73 ApplicationInstance.check] No PID file
DEBUG: [common/mount.py:50 Mount.__init__] pw-cache is not running
DEBUG: [common/mount.py:59 Mount.__init__] Call command: /usr/bin/backintime pw-cache start
DEBUG: [common/applicationinstance.py:73 ApplicationInstance.check] No PID file
--- snip ---
DEBUG: [common/applicationinstance.py:73 ApplicationInstance.check] No PID file
DEBUG: [common/tools.py:616 keyring_supported] Found appropriate keyring 'keyring.backends.SecretService'
DEBUG: [common/applicationinstance.py:73 ApplicationInstance.check] No PID file
DEBUG: [common/mount.py:50 Mount.__init__] pw-cache is not running
DEBUG: [common/mount.py:59 Mount.__init__] Call command: /usr/bin/backintime pw-cache start
DEBUG: [common/applicationinstance.py:73 ApplicationInstance.check] No PID file
groucho@devuan:/$

And lastly I checked syslog to see if I was getting any kwallet related failures:

groucho@devuan:/var/log$ tail -2500 syslog | grep kwallet| grep failed
Mar 11 11:45:40 devuan dbus-daemon[2968]: [session uid=1000 pid=2966] Activated service 'org.kde.kwalletd' failed: Failed to execute program org.kde.kwalletd: No such file or directory
groucho@devuan:/var/log$

That was the last one today at 11:45.
Nothing after six or seven reboots since mid-day today.

backintime seems to be working properly and I have not (yet) seen any problems arise.

Cheers,

A.

Altoid · Installation

Hello:

F_Sauce wrote:

Not a good answer ...

But it's an answer ... 8^D

F_Sauce wrote:

... probably find a better way ...

I have kept investigating but my knowledge in this area is very limited.

I did find this post that has some elements in common: https://github.com/bit-team/backintime/issues/990
The element in common would be the 'keyring.backends.chainer' can't be used with BackInTime along with the fact that this specific backend has priority: 10.

But I really cannot make heads / tails out of it.

Thanks for your input.

Cheers,

A.

Altoid · Installation

Hello:

As I explain in this other post https://dev1galaxy.org/viewtopic.php?id=4142, I am attempting to find out the cause of a failure reported in syslog by the dbus-daemon.
What syslog shows me (I've split it so it can be easier to read) is this:

Mar  9 06:57:35
devuan dbus-daemon[2961]:
[session uid=1000 pid=2959]
Activating service name='org.kde.kwalletd' requested by ':1.42' (uid=1000 pid=3124 comm="/usr/bin/kwalletd5 ")

Mar  9 06:57:35
devuan dbus-daemon[2961]:
[session uid=1000 pid=2959]
Activated service 'org.kde.kwalletd' failed: Failed to execute program org.kde.kwalletd: No such file or directory

This repeats itself with the same syntax and in the same manner ie: at the same time and one after the other, save for the different pid IDs which will be different each time.
It happens when I log in ie: session uid=1000.

Mar 10 14:43:03
devuan dbus-daemon[3015]:
[session uid=1000 pid=3013]
Activating service name='org.kde.kwalletd' requested by ':1.37' (uid=1000 pid=3174 comm="/usr/bin/kwalletd5 ")

Mar 10 14:43:03 devuan dbus-daemon[3015]:
[session uid=1000 pid=3013]
Activated service 'org.kde.kwalletd' failed: Failed to execute program org.kde.kwalletd: No such file or directory

My Devuan Beowulf installation (upgrade from ASCII) has libkwalletbackend5-5 installed:

groucho@devuan:~$ uname -a
Linux devuan 4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30) x86_64 GNU/Linux
groucho@devuan:~$

groucho@devuan:~$ apt list | grep kwallet | grep installed
--- snip ---
libkwalletbackend5-5/stable,now 5.54.0-1 amd64 [installed,automatic]
groucho@devuan:~$

libkwalletbackend5-5 is needed by backintime-qt4, the backintime-common GUI.

groucho@devuan:~$ aptitude why libkwalletbackend5-5
i   backintime-qt4    Depends  backintime-common (= 1.1.24-0.1)
i A backintime-common Depends  python3-keyring                 
i A python3-keyring   Suggests libkf5wallet-bin                
i A libkf5wallet-bin  Depends  libkwalletbackend5-5 (>= 5.13.0)
groucho@devuan:~$

Starting backintime-qt4 from a terminal to see if I could find anything got me this:

groucho@devuan:~$ backintime-qt4 --debug
DEBUG: [common/backintime.py:518 arg_parse] Arguments: {'debug': True} | unknownArgs: []

Back In Time
Version: 1.1.24

Back In Time comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; type `backintime --license' for details.

DEBUG: [common/backintime.py:585 getConfig] config file: /home/groucho/.config/backintime/config
DEBUG: [common/backintime.py:586 getConfig] profiles: ['1']
DEBUG: [common/applicationinstance.py:73 GUIApplicationInstance.check] No PID file
DEBUG: [common/pluginmanager.py:88 PluginManager.load_plugins] Register plugin path /usr/share/backintime/plugins
DEBUG: [common/pluginmanager.py:104 PluginManager.load_plugins] Add plugin notifyplugin.py
DEBUG: [common/pluginmanager.py:104 PluginManager.load_plugins] Add plugin qt4plugin.py
DEBUG: [common/pluginmanager.py:104 PluginManager.load_plugins] Add plugin userscriptsplugin.py
DEBUG: [common/snapshots.py:953 Snapshots.has_old_snapshots] Found old snapshots: False
DEBUG: [common/tools.py:618 keyring_supported] No appropriate keyring found. 'keyring.backends.chainer' can't be used with BackInTime
DEBUG: [common/applicationinstance.py:73 ApplicationInstance.check] No PID file
DEBUG: [common/mount.py:50 Mount.__init__] pw-cache is not running
DEBUG: [common/mount.py:59 Mount.__init__] Call command: /usr/bin/backintime pw-cache start
DEBUG: [common/applicationinstance.py:73 ApplicationInstance.check] No PID file
--- snip ---
The previous line repeats continuously till I exit the GUI.
--- snip ---
DEBUG: [common/applicationinstance.py:73 ApplicationInstance.check] No PID file
DEBUG: [common/tools.py:618 keyring_supported] No appropriate keyring found. 'keyring.backends.chainer' can't be used with BackInTime
DEBUG: [common/applicationinstance.py:73 ApplicationInstance.check] No PID file
DEBUG: [common/mount.py:50 Mount.__init__] pw-cache is not running
DEBUG: [common/mount.py:59 Mount.__init__] Call command: /usr/bin/backintime pw-cache start
groucho@devuan:~$

The available keyring.backends are these:

groucho@devuan:~$ keyring --list-backends
keyrings.alt.file.EncryptedKeyring (priority: 0.6)
keyring.backends.kwallet.DBusKeyringKWallet4 (priority: 3.9)
keyring.backends.chainer.ChainerBackend (priority: 10)
keyring.backends.kwallet.DBusKeyring (priority: 4.9)
keyrings.alt.Gnome.Keyring (priority: 1)
keyring.backends.fail.Keyring (priority: 0)
keyring.backends.SecretService.Keyring (priority: 5)
keyrings.alt.file.PlaintextKeyring (priority: 0.5)
groucho@devuan:~$

And the one with priority: 10 cannot be used by backintime-qt4.

But this is all way over my head.
Even though it seems that backintime is working properly, the printout of backintime-qt4 --debug plus the syslog errors could mean there's something amiss somewhere.

Any ideas/suggestions?

Thanks in advance,

A.

Altoid · Installation

Head_on_a_Stick wrote:

... would use either/or.
... want to use both methods then call the full path for date ...

Yes, makes sense.
Done, will use full path to the script.

Head_on_a_Stick wrote:

... should probably record both stdout and stderr:
/sbin/fstrim -a -v >> "$LOG" 2>&1

Done.
Thanks for the heads up.

Cheers,

A.

Altoid · Installation

Hello:

ralph.ronnquist wrote:

... PATH is a common cause of issues, see e.g. man 5 crontab.

--

Head_on_a_Stick wrote:

... it's a PATH issue.
... set PATH in the script or call the full path to fstrim ...

Like this?
Belt and suspenders ...

#!/bin/sh
# trim all mounted file systems which support it
# added x 20200315
#
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
LOG=/var/log/trim.log
echo "*** $(date -R) ***" >> $LOG
/sbin/fstrim -a -v >> $LOG

Thank you both for your input.

Cheers,

A.

Altoid · Installation

Hello:

I have put a script to run fstrim in /etc/cron.weekly/:

groucho@devuan:/$ cat /etc/cron.weekly/dev-fstrim
#!/bin/sh
# trim all mounted file systems which support it
# added 20200315
#
LOG=/var/log/trim.log
echo "* $(date -R) *" >> $LOG
fstrim -a -v >> $LOG
groucho@devuan:/var/log$

But it is not running, probably because fstrim needs admin credentials to run.
I can run the script as root but that needs my intervention and the idea is that it runs automagically one a week.

What is the proper way to achieve this?
An entry in /etc/sudoers.d for fstrim?

Thanks in advance.

A.

Altoid · Devuan Derivatives

Hello:

Ogis1975 wrote:

By no means.

+1

A.

Altoid · Devuan Derivatives

Hello:

jsalpha2 wrote:

Hoping that someone is working on a Linux Mint Devuan Edition.

Why on earth bother?

We have Devuan which is very flexible and a host of options for the screen.

A.

Altoid · Installation

Hello:

Altoid wrote:

I have this line in my /var/log/syslog:

Feb 22 16:35:25 devuan dbus-daemon[2963]: [session uid=1000 pid=2961] Activated service 'org.kde.kwalletd' failed: Failed to execute program org.kde.kwalletd: No such file or directory

I'm bumping this because I have not been able to find any information elsewhere and as it is whateverd related, thought the answer could come from this forum.

Thanks in advance,

A.

Altoid · Off-topic

Hello:

dice wrote:

What do you use for backups?

I use two applications: Timeshift and BackInTime.
Timeshift takes system snapshots and BackInTime takes ~/ snapshots.
Have always worked quite well.

All the snapshots get stored on a separate 300Gb SAS drive living inside the box.
This is quite obviously not the ideal solution and I've been procrastinating for the longest while.

Cheers,

A.

Altoid · Off-topic

Hello:

Altoid wrote:

Are you using the OEM cable?
Does it have a ferrite filter?

How long has this specific cable been in use ie: terminals in its sockets?
Try unplugging/plugging them a number of times and see what happens, with the PC/monitor turned off.

Ron wrote:

... don't think it's something nearby that's causing the problem.

Check to see what happens by moving the monitor (if at all possible) to another location.
Does ot have to be more than a couple of feet.

Ron wrote:

... replace the cable ...

See if you can borrow a quality monitor OEM cable to test.

Cheers,

A.

Altoid · Off-topic

Hello:

Ron wrote:

Does anyone have any ideas what it is ...

I agree with these previous answers.

ralph.ronnquist wrote:

Have you tried replacing the monitor cable?

Head_on_a_Stick wrote:

If it's intermittent then the problem is with the hardware (the cable ...

The description fit this (probaby) being some sort of radio interference generated by something electrically powered running nearby and being picked up by the monitor cable.

Are you using the OEM cable?
Does it have a ferrite filter?
Have you tried using another cable?

When you do have these artifacts on the screen, is there something electrical running nearby?

Cheers,

A.

Altoid · Desktop and Multimedia

Hello:

alexkemp wrote:

Clue within Beowulf Release Notes

Don't forget these two, they come up with surprising frequency :

Release Notes wrote:

Changes in su
- The behavior of su has changed. Use 'su -' to get root's path or use
the full path to commands if you use only 'su'.
---- snip ----
Pulseaudio
- If you install a desktop environment from the installer iso, you will
automatically get the debian-pulseaudio-config-override package,
which will ensure that pulseaudio is running. If you're running a
window manager, you may need to install the override package to get
sound. Alternatively, you may use the old method, described below.

- If you have no sound, make sure the following line in
/etc/pulse/client.conf.d/00-disable-autospawn.conf is commented as
shown here:
#autospawn=no
---- snip ----

Regarding the importance of Release Notes, (believe it or not) someone once actually posted this bit of interesting IT wisdom here at Dev1:

Reading distro notes: Until Devuan, never wasted one minute reading them. Either an OS is transparent, and works effortlessly, or it needs criticism.

8^7 !!!

Cheers,

A.

The officially official Devuan Forum!

#1351 Hardware & System Configuration » [SOLVED] fwts in for Devuan Beowulf » 2021-03-16 15:08:39

#1352 Re: Hardware & System Configuration » [SOLVED] Strange gparted situation » 2021-03-15 21:13:45

#1353 Re: Hardware & System Configuration » [SOLVED] Strange gparted situation » 2021-03-15 18:46:49

#1354 Re: Hardware & System Configuration » [SOLVED] Strange gparted situation » 2021-03-15 17:08:08

#1355 Re: Desktop and Multimedia » [SOLVED] Nvidia error at boot » 2021-03-15 12:38:02

#1356 Re: Desktop and Multimedia » [SOLVED] Nvidia error at boot » 2021-03-15 12:34:02

#1357 Re: Desktop and Multimedia » [SOLVED] Nvidia error at boot » 2021-03-15 12:30:26

#1358 Re: Hardware & System Configuration » [SOLVED] Strange gparted situation » 2021-03-15 11:42:52

#1359 Re: Desktop and Multimedia » [SOLVED] Nvidia error at boot » 2021-03-15 11:01:28

#1360 Re: Hardware & System Configuration » [SOLVED] Strange gparted situation » 2021-03-15 01:53:28

#1361 Hardware & System Configuration » [SOLVED] Strange gparted situation » 2021-03-14 22:08:40

#1362 Desktop and Multimedia » Thunar crashes on "Drag and Drop" » 2021-03-13 17:48:10

#1363 Re: Installation » [Solved] Interpreting/debugging dbus-daemon failure in syslog » 2021-03-12 02:17:17

#1364 Re: Installation » [Solved] Interpreting/debugging dbus-daemon failure in syslog » 2021-03-11 01:16:25

#1365 Installation » [Solved] Interpreting/debugging dbus-daemon failure in syslog » 2021-03-10 20:44:54

#1366 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-09 20:26:54

#1367 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-08 21:08:01

#1368 Installation » [SOLVED] Permissions for script in cron » 2021-03-08 19:51:15

#1369 Re: Devuan Derivatives » Linux Mint Devuan Edition? » 2021-03-08 19:15:53

#1370 Re: Devuan Derivatives » Linux Mint Devuan Edition? » 2021-03-08 19:14:53

#1371 Re: Installation » kwalletd failure in syslog » 2021-03-07 21:44:39

#1372 Re: Off-topic » Operating System Backups » 2021-03-05 14:53:47

#1373 Re: Off-topic » A problem on my monitor » 2021-03-05 11:43:44

#1374 Re: Off-topic » A problem on my monitor » 2021-02-27 18:13:05

#1375 Re: Desktop and Multimedia » Packages in Synaptic that are 'Held Back' (how to fix that?) » 2021-02-27 12:47:40

Board footer