Posts by Altoid

Altoid · Desktop and Multimedia

Hello:

dice wrote:

... play with mouse settings and see if this helps?

Does not make any difference, it is not a mouse problem.

Given my observations, I have concluded that this is a problem with thunar and how it interacts with compositing.
Maybe it is related to how Xfce intruments compositing?

The maintainers at gitlab.xfce.org first made a reference to my using " ... outdated versions of the various involved components (Thunar, GTK, X and xfwm4) ..."
They have told me me that no one else has reported it and had not been able to reproduce it.

On their suggestion, I also tried to get a backtrace but the gdb utility did not produce a stack on thread apply all bt full or bt.
Alternatively, running it as root completely froze my desktop and did not produce a stack either.

So there's evidently something wrong there.

So I will just get rid of thunar and stay with PCManFM.
It seems to work quite well and most importantly, does not crash under the same conditions thunar does.

Best,

A.

Altoid · Desktop and Multimedia

Hello:

An update on this post.

Altoid wrote:

I have come across a problem in thunar which consists of it crashing ...

While testing, I realised that this problem only happens only inside thunar, in or from a thunar window.
I can "drag and drop" a file or folder from the desktop into a thunar window and everything will work as intended.
ie: thunar does not crash nor does the desktop freeze.

I cross-posted it to the Xfce forum, also with no luck.

So then I posted the problem to gitlab.xfce.org.
See: https://gitlab.xfce.org/xfce/thunar/-/i … note_27697

One comment was this:

Note that, the bug reporter is using outdated versions of the various involved components (thunar, GTK, X and xfwm4), so it may be the case that this issue was fixed long ago.

thunar, GTK, X and xfwm4 are all linked by being in the same bag so to speak. ie: Xfce 4.12.
So I don't really get the idea behind this comment.

I probably won't be upgrading to Xfce 4.16.
See https://www.xfce.org/about/news/?post=1608595200 and this thread https://forum.xfce.org/viewtopic.php?id=13689.

Acting on a question in the bug report, I turned off compositing in Applications > Settings > Window Manager Tweaks > Compositor and unchecked "Enable display compositing".
The problem went away.

Then I decided to try with another file manager to see if the "drag and drop" problem was common to any other one.
My first choice was PCManFM as it was the lightest download.

I did it without uninstalling thunar and with compositing enabled.
The experiment was a 100% success, the "drag and drop" problem did not happen with PCManFM.

At first I thought that installing PCManFM may have fixed something as the install also downloaded these files:
libfm4:amd64 - libfm-modules:amd64 - libfm-extra4:amd64 - lxmenu-data:amd64 - libfm-gtk4:amd64 - gvfs-fuse:amd64
libmenu-cache-bin:amd64 - libfm-data:amd64 - pcmanfm:amd64 - libmenu-cache3:amd64 - libfm-gtk-data:amd64

But no: running Thunar again with compositing enabled still has the "drag and drop" problem.

That's about it.
I will be keeping PCManFM and seriously considering leaving Xfce and if not, least pinning it at 4.12.

Cheers,

A.

Altoid · Hardware & System Configuration

Hello:

rolfie wrote:

Try apt -f install ....

Didn't work.
Those packages do not seem to be in the Devuan Beowulf repositories.

Head_on_a_Stick wrote:

Altoid wrote:
Should I enable the Ubuntu repo?
No. You'll have to download the individual .debs from the Ubuntu repositories ...

I see ...

Seems there is a snap package which I distrust because of snap and a live version I can run from an SD card.
I think that's the best option for now.

Thanks for your input.

Best,

A.

Altoid · Hardware & System Configuration

Hello:

Head_on_a_Stick wrote:

... latest version would be best (fwts_18.03.00-0ubuntu5_amd64.deb).

Both this and the previous version (fwts_18.03.00-0ubuntu1_amd64.deb) have some dependency problems.

groucho@devuan:~/Downloads$ sudo apt install /home/groucho/Downloads/fwts_18.03.00-0ubuntu1_amd64.deb
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Note, selecting 'fwts' instead of '/home/groucho/Downloads/fwts_18.03.00-0ubuntu1_amd64.deb'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.

The following information may help to resolve the situation:

The following packages have unmet dependencies:
 fwts : Depends: libfwtsiasl1 (= 18.03.00-0ubuntu1) but it is not installable
        Depends: libfwtsacpica1 (= 18.03.00-0ubuntu1) but it is not installable
        Depends: libfwts1 (= 18.03.00-0ubuntu1) but it is not installable
        Depends: fwts-efi-runtime-dkms (= 18.03.00-0ubuntu1) but it is not installable
E: Unable to correct problems, you have held broken packages.
groucho@devuan:~/Downloads$

I installed with apt install because it is supposed to solve dependencies but these don't show up with apt list.

Should I enable the Ubuntu repo? (I think not ...)

Thanks in advance,

A.

Altoid · Hardware & System Configuration

Hello:

Head_on_a_Stick wrote:

I think the latest version would be best (fwts_18.03.00-0ubuntu5_amd64.deb).

Right, thank you.

Head_on_a_Stick wrote:

... fix things with acpica-tools instead.
See https://wiki.archlinux.org/index.php/DSDT for an overview of the technique.

Thanks, I'll have a look at that.
I know how and have been able to load an alternate DSDT, modified to be able to re-compile with no errors vis-a-vis the 30+ errors the original DSDT has.
It turned out to be rather tricky because different version of the Intel compiler produce different results on errors and warnings.

For this specific BIOS I settled on the one that supports ACPI Specification Revision 6.2A.

The catch is that I have not been able to solve the problems I describe in my previous post and it seems that the fwst application may shed some light on it as it has a number of tests to run and (try) to debug the BIOS/tables.

Head_on_a_Stick wrote:

... submit a bug report with your findings so that the upstream kernel developers can make things work for everybody else.

Of course I will.
But to be honest, I don't expect anything much.

I wrote about this in 2019, a comment on a previous bug report in 2018:
https://bugzilla.kernel.org/show_bug.cgi?id=201965
No answers or fixes upstream.

A chap found a solution for a similar problem with a relatively new (?) Asus board.
He posted his findings here:
https://bugzilla.kernel.org/show_bug.cgi?id=210689
No answers either.

He then saw my post, wrote to me about his findings and got me started on this again, after a couple of years.
I used his DSDT data on mt tables but was not able to solve my problem.

I'm aware that I have the perfect combination: 10 year old + unmaintained hardware + non-existent OEM.
If you add that Sun evidently employed untrained monkeys to write this BIOS ...

rant
ie: how is it possible that a top of the line Sun WS worth US$1800/2300 in 2007 had a BIOS reporting it as "portable"?
A bug that was never fixed in later BIOS versions?
/rant

Thanks for your input.

Best,

A.

Altoid · Hardware & System Configuration

Hello:

Head_on_a_Stick wrote:

Altoid wrote:
Any idea as to what may have caused it?
... an ISO image was burned to the device at some point. The magic string laid down by that process can be very persistent.

Don't think so.

If you mean that I may have burnt an *.iso image to that HDD, I can tell you with certainty that it is not the case.
Either I mounted a that specific *.iso file with AcetoneISO, burnt it to a CD or DVD or wrote it to an SD card.

In any case, is there something that can be done so this does not happen again?

Thanks a lot for your input.

Cheers,

A.

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.

The officially official Devuan Forum!

#1376 Re: Desktop and Multimedia » Thunar crashes on "Drag and Drop" » 2021-03-17 20:44:43

#1377 Re: Desktop and Multimedia » Thunar crashes on "Drag and Drop" » 2021-03-17 12:48:52

#1378 Re: Hardware & System Configuration » [SOLVED] fwts in for Devuan Beowulf » 2021-03-16 19:53:37

#1379 Re: Hardware & System Configuration » [SOLVED] fwts in for Devuan Beowulf » 2021-03-16 19:08:10

#1380 Re: Hardware & System Configuration » [SOLVED] fwts in for Devuan Beowulf » 2021-03-16 17:23:45

#1381 Re: Hardware & System Configuration » [SOLVED] Strange gparted situation » 2021-03-16 16:06:23

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Board footer