from:"gary"


On 2024-02-27 14:13, Jeffrey Walton wrote:

On Tue, Feb 27, 2024 at 2:12 PM Gary Dale  wrote:

On 2024-02-27 10:25, Kushal Kumaran wrote:

On Tue, Feb 27 2024 at 10:15:59 AM, Gary Dale  wrote:

[...]
Can anyone explain how Trixie is handling crontabs now?

This behavior has existed forever.  I'm on bookworm, though, so no idea
if anything is changing in trixie.

The debian wiki suggests that the handling of cron/anacron is evolving.

That sounds like a euphemism for "being killed off" by Systemd and its timers.

Jeff


There are a lot of things going on these days that don't seem quite 
ready for prime time.


Examples include systemd networking, which remains woefully ill-equipped 
to deal with bonding and wifi.


Wayland may have some good things to say about it but when I try it, it 
messes up my desktop. I have my desktop scaled to 150% to help with my 
old eyes, but Wayland doesn't seem to apply it to text, which is where I 
really need it.


I'm hoping Plasma 6 will address the Wayland issues at least.

Re: where are the crontab files in Trixie?


On 2024-02-27 10:32, Greg Wooledge wrote:

On Tue, Feb 27, 2024 at 10:15:59AM -0500, Gary Dale wrote:

I'm running Debian/Trixie on an AMD64 system. I have an old wifi adapter
that Linux has problems with that works once I run:

/usr/sbin/modprobe brcmfmac
echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id

However when I add those lines to the root's crontab using # crontab -e as

@reboot /usr/sbin/modprobe brcmfmac
@reboot echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id

the second line fails. I get an e-mail stating "/bin/sh: 1: cannot create
/sys/bus/usb/drivers/brcmfmac/new_id: Directory nonexistent"

Having two separate @reboot lines might run them both in parallel,
rather than sequentially.  It might be better to combine them into
one shell command, or one script.

Something like this, perhaps:

 @reboot /usr/sbin/modprobe brcmfmac && echo 13b1 0bdc > 
/sys/bus/usb/drivers/brcmfmac/new_id

Or put the commands into a shell script, then run the script from crontab.


Yep. That works.  Thanks.

Re: where are the crontab files in Trixie?


On 2024-02-27 10:25, Kushal Kumaran wrote:

On Tue, Feb 27 2024 at 10:15:59 AM, Gary Dale  wrote:

I'm running Debian/Trixie on an AMD64 system. I have an old wifi
adapter that Linux has problems with that works once I run:

/usr/sbin/modprobe brcmfmac
echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id

However when I add those lines to the root's crontab using # crontab -e as

@reboot /usr/sbin/modprobe brcmfmac
@reboot echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id

the second line fails. I get an e-mail stating "/bin/sh: 1: cannot
create /sys/bus/usb/drivers/brcmfmac/new_id: Directory nonexistent"

I'm not sure if the modprobe is working or if the module is being
loaded without it. It's likely that debian detects the need for the
module and loads it.


Is it possible that the command is being run before the module is
loaded.  Consider putting both into a single command, perhaps by writing
a script that does both things.


Anyway, that got me down the rabbit hole to try to find where the
crontab file is.

  ls -l /root/cron*
ls: cannot access '/root/cron*': No such file or directory

also

# whereis crontab
crontab: /usr/bin/crontab /etc/crontab
/usr/share/man/man1/crontab.1.gz /usr/share/man/man5/crontab.5.gz

so it's not in the location that you'd expect. Nor can I find it in
/etc/. The various cron files there don't contain the lines I;m
looking for.


Editing/creating crontab files using "crontab -e" creates it in
/var/spool/cron/crontabs.




Can anyone explain how Trixie is handling crontabs now?

This behavior has existed forever.  I'm on bookworm, though, so no idea
if anything is changing in trixie.

The debian wiki suggests that the handling of cron/anacron is evolving.

Re: where are the crontab files in Trixie?


On 2024-02-27 10:26, The Wanderer wrote:

On 2024-02-27 at 10:15, Gary Dale wrote:


Anyway, that got me down the rabbit hole to try to find where the
crontab file is.

   ls -l /root/cron*
ls: cannot access '/root/cron*': No such file or directory

also

# whereis crontab
crontab: /usr/bin/crontab /etc/crontab /usr/share/man/man1/crontab.1.gz
/usr/share/man/man5/crontab.5.gz

so it's not in the location that you'd expect.

I'm not sure whereis is suitable for finding things like this. As its
man page states, it's for finding "the binary, source, and manual page
files for a command" - not the data files which the command may work with.

locate crontab also fails to find it, as does  find / -name crontab



Nor can I find it in /etc/. The various cron files there don't
contain the lines I;m looking for.
Can anyone explain how Trixie is handling crontabs now?

The first paragraph of crontab(1) states:


Each user can have their own crontab, and though these are files in
/var/spool/cron/crontabs,they are not intended to be edited
directly.

So, while I don't use per-user crontabs myself and so don't have
experience with this personally, I would suggest looking in that
directory - but not necessarily editing the files there, except via
'crontab -e' as you have already done.


Thanks. I missed that when I was reading the comments.  I need to 
enlarge the text more, I guess.

where are the crontab files in Trixie?

I'm running Debian/Trixie on an AMD64 system. I have an old wifi adapter 
that Linux has problems with that works once I run:


/usr/sbin/modprobe brcmfmac
echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id

However when I add those lines to the root's crontab using # crontab -e as

@reboot /usr/sbin/modprobe brcmfmac
@reboot echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id

the second line fails. I get an e-mail stating "/bin/sh: 1: cannot 
create /sys/bus/usb/drivers/brcmfmac/new_id: Directory nonexistent"


I'm not sure if the modprobe is working or if the module is being loaded 
without it. It's likely that debian detects the need for the module and 
loads it.


Anyway, that got me down the rabbit hole to try to find where the 
crontab file is.


 ls -l /root/cron*
ls: cannot access '/root/cron*': No such file or directory

also

# whereis crontab
crontab: /usr/bin/crontab /etc/crontab /usr/share/man/man1/crontab.1.gz 
/usr/share/man/man5/crontab.5.gz


so it's not in the location that you'd expect. Nor can I find it in 
/etc/. The various cron files there don't contain the lines I;m looking for.


However, running crontab -e as root definitely shows the file I expect 
to see.  Specifically:


# Edit this file to introduce tasks to be run by cron.
#
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
#
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').
#
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
#
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
#
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h  dom mon dow   command
@reboot /usr/sbin/modprobe brcmfmac
@reboot echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id

Looking at systemd-timers doesn't show anything obvious either.

Can anyone explain how Trixie is handling crontabs now?

Re: running Jami in Trixie - possible locale issue


On 2024-02-26 22:47, Greg Wooledge wrote:

On Mon, Feb 26, 2024 at 10:10:45PM -0500, Gremlin wrote:

On 2/26/24 20:28, Gary Dale wrote:

$locale
locale: Cannot set LC_CTYPE to default locale: No such
file or directory
locale: Cannot set LC_MESSAGES to default locale: No
such file or directory
locale: Cannot set LC_ALL to default locale: No such file or 
directory

LANG=iu_CA.UTF-8
LANGUAGE=en_GB
LC_CTYPE="iu_CA.UTF-8"
LC_NUMERIC=en_CA.UTF-8
LC_TIME=en_CA.UTF-8
LC_COLLATE=en_CA.UTF-8
LC_MONETARY=en_CA.UTF-8
LC_MESSAGES="iu_CA.UTF-8"
LC_PAPER="iu_CA.UTF-8"
LC_NAME="iu_CA.UTF-8"
LC_ADDRESS="iu_CA.UTF-8"
LC_TELEPHONE="iu_CA.UTF-8"
LC_MEASUREMENT=en_CA.UTF-8
LC_IDENTIFICATION="iu_CA.UTF-8"
LC_ALL=

$locale -a
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or 
directory

C
C.utf8
en_CA.utf8
en_US.utf8
fr_CA.utf8
POSIX



Find out where LC_CTYPE and LC_MESSAGES is being set, they need changed.

No, you're not reading it correctly. Look at LANG. Look at the double
quotes around LC_CTYPE and LC_MESSAGES (among others). LC_CTYPE and
LC_MESSAGES are *not* set. They are deduced from LANG.

It's LANG that has the weird setting. All of the other iu_CA entries
are double-quoted, so they are derived from it.


If it was me, I would set /etc/default/locale to
# File generated by update-locale
LANG=C.UTF-8

and remove all references/assignments to any LC_ in all shell
config files.

then reboot and do a locale -a

Rebooting doesn't do anything useful here. Simply logging out and back
in would be sufficient.

But there are two points of view here:

1) Why is Gary using locales that are not generated?

2) Why is Gary using *these specific* locales?

I think you're approaching it from the point of view of "your settings
are wrong, but you don't know where the settings are coming from, so
find out, and fix them". Which is one valid POV.

Another valid POV is "the settings are set the way Gary wants them, but
the locales aren't generated, so generate them, and then it'll work".

Only Gary can tell us which of these is the right approach. Maybe he's
a fluent Inuktitut speaker. All I can say is that it's hard to believe
that someone would *accidentally* have LANG set to iu_CA.UTF-8. Usually
that's the kind of thing one would remember doing.


The only unusual thing I've done was trying to set the locale to en_CA 
rather than en_US. However my installation dates back a long time and 
Linux has changed a lot over the years. At one point, I believe support 
for Canadian English was spotty so I had a en_GB locale added. The iu_CA 
is weird and seems to vanish when I set the default locale to C.


But no, I've never gone beyond dpkg-reconfigure locales and the GUI 
settings for locales - other than yesterday trying to force en_CA in 
.bash_profile, which I have now removed.

Re: running Jami in Trixie - possible locale issue


On 2024-02-26 22:47, Greg Wooledge wrote:

On Mon, Feb 26, 2024 at 10:10:45PM -0500, Gremlin wrote:

On 2/26/24 20:28, Gary Dale wrote:

$locale
locale: Cannot set LC_CTYPE to default locale: No such
file or directory
locale: Cannot set LC_MESSAGES to default locale: No
such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=iu_CA.UTF-8
LANGUAGE=en_GB
LC_CTYPE="iu_CA.UTF-8"
LC_NUMERIC=en_CA.UTF-8
LC_TIME=en_CA.UTF-8
LC_COLLATE=en_CA.UTF-8
LC_MONETARY=en_CA.UTF-8
LC_MESSAGES="iu_CA.UTF-8"
LC_PAPER="iu_CA.UTF-8"
LC_NAME="iu_CA.UTF-8"
LC_ADDRESS="iu_CA.UTF-8"
LC_TELEPHONE="iu_CA.UTF-8"
LC_MEASUREMENT=en_CA.UTF-8
LC_IDENTIFICATION="iu_CA.UTF-8"
LC_ALL=

$locale -a
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
C
C.utf8
en_CA.utf8
en_US.utf8
fr_CA.utf8
POSIX



Find out where LC_CTYPE and LC_MESSAGES is being set, they need changed.

No, you're not reading it correctly.  Look at LANG.  Look at the double
quotes around LC_CTYPE and LC_MESSAGES (among others).  LC_CTYPE and
LC_MESSAGES are *not* set.  They are deduced from LANG.

It's LANG that has the weird setting.  All of the other iu_CA entries
are double-quoted, so they are derived from it.


If it was me, I would set /etc/default/locale to
#  File generated by update-locale
LANG=C.UTF-8

and remove all references/assignments to any LC_ in all shell
config files.

then reboot and do a locale -a

Rebooting doesn't do anything useful here.  Simply logging out and back
in would be sufficient.

But there are two points of view here:

1) Why is Gary using locales that are not generated?

2) Why is Gary using *these specific* locales?

I think you're approaching it from the point of view of "your settings
are wrong, but you don't know where the settings are coming from, so
find out, and fix them".  Which is one valid POV.

Another valid POV is "the settings are set the way Gary wants them, but
the locales aren't generated, so generate them, and then it'll work".

Only Gary can tell us which of these is the right approach.  Maybe he's
a fluent Inuktitut speaker.  All I can say is that it's hard to believe
that someone would *accidentally* have LANG set to iu_CA.UTF-8.  Usually
that's the kind of thing one would remember doing.


The only unusual thing I've done was trying to set the locale to en_CA 
rather than en_US. However my installation dates back a long time and 
Linux has changed a lot over the years. At one point, I believe support 
for Canadian English was spotty so I had a en_GB locale added. The iu_CA 
is weird and seems to vanish when I set the default locale to C.


But no, I've never gone beyond

Re: running Jami in Trixie - possible locale issue


On 2024-02-26 22:10, Gremlin wrote:

On 2/26/24 20:28, Gary Dale wrote:

On 2024-02-26 17:31, Gremlin wrote:

On 2/26/24 17:18, Gary Dale wrote:

On 2024-02-26 16:03, Gremlin wrote:

On 2/26/24 14:36, Gary Dale wrote:
I'm running Debian/Trixie on an AMD64 system. I've installed jami 
from testing but it fails to start. When I run it from the 
command line, I get:


$jami &
[1] 7804
$ Using Qt runtime version: 6.
4.2
"notify server name: Plasma, vendor: KDE, version: 5.27.10, spec: 
1.2"

"Using locale: en_GB"
terminate called after throwing an instance of 'std::runtime_error'
  what():  locale::facet::_S_create_c_locale name not valid

[1]+  Aborted (core dumped) jami
garydale@transponder:~/mnt/archives/2024/Lions Cl


There might be something wrong with my locales but 
dpkg-reconfigure locales doesn't fix it. After running it, I 
still get this output:


$locale
locale: Cannot set LC_CTYPE to default locale: No such file or 
directory
locale: Cannot set LC_MESSAGES to default locale: No such file or 
directory
locale: Cannot set LC_ALL to default locale: No such file or 
directory

LANG=iu_CA.UTF-8
LANGUAGE=en_GB
LC_CTYPE="iu_CA.UTF-8"
LC_NUMERIC=en_CA.UTF-8
LC_TIME=en_CA.UTF-8
LC_COLLATE=en_CA.UTF-8
LC_MONETARY=en_CA.UTF-8
LC_MESSAGES="iu_CA.UTF-8"
LC_PAPER="iu_CA.UTF-8"
LC_NAME="iu_CA.UTF-8"
LC_ADDRESS="iu_CA.UTF-8"
LC_TELEPHONE="iu_CA.UTF-8"
LC_MEASUREMENT=en_CA.UTF-8
LC_IDENTIFICATION="iu_CA.UTF-8"
LC_ALL=

Please note that I have not selected iu_CA.utf8 nor en_GB in my 
locales.


Any ideas on how to fix this?

Thanks.



Edit /etc/locale.gen and enable the locale(s) you wish to use.
Then as root

locale-gen
dpkg-reconfigure locales

Nope. /etc/locale.gen was already correct. Running the commands 
then rebooting leaves me with the same error messages.


I also set up a ~/.bash_profile to set LANG to en_CA.UTF-8 but that 
also had no effect. The exact contents are:


LANG="en_CA.UTF-8"
export LANG




You are making a mess, when about to make a mess stop until you have 
researched your issue.


Start at the beginning not at the end..

Did you reboot or logout and login

dpkg-reconfigure locales is suppose to set /etc/default/locales 
correctly, it runs update-locale if I remember correctly.


cat /etc/locale.gen

# This file lists locales that you wish to have built. You can find 
a list
# of valid supported locales at /usr/share/i18n/SUPPORTED, and you 
can add
# user defined locales to /usr/local/share/i18n/SUPPORTED. If you 
change

# this file, you need to rerun locale-gen.
#

C.UTF-8 UTF-8
# aa_DJ ISO-8859-1
^^

snip

cat /etc/default/locale
#  File generated by update-locale
LANG=C.UTF-8

locale -a


I'm not making a mess, I'm trying to fix an existing mess. And yes, 
I've rebooted so many times today that I felt like I was running 
Windows.


Sure you have made a mess, the debian installer didn't select locales 
and assign them at random.


I am thinking the following will BARF also.

localectl list-locales


Sorry, but I've never touched locales except through apt/dpkg. I think 
the problem more likely relates to older locales not being properly 
removed by the upgrade/modification processes.


$ localectl list-locales
C.UTF-8
en_CA.UTF-8
en_US.UTF-8
fr_CA.UTF-8






cat /etc/default/locale
LANG=en_CA.UTF-8
LANGUAGE=en_CA:en
LC_TIME=en_CA.UTF-8

# locale -a
C
C.utf8
en_CA.utf8
en_US.utf8
fr_CA.utf8
POSIX

Also:

$locale -a
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or 
directory

C
C.utf8
en_CA.utf8
en_US.utf8
fr_CA.utf8
POSIX




Find out where LC_CTYPE and LC_MESSAGES is being set, they need changed.

If it was me, I would set /etc/default/locale to
#  File generated by update-locale
LANG=C.UTF-8

and remove all references/assignments to any LC_ in all 
shell config files.


then reboot and do a locale -a


existing file before doing any changes:

$ cat /etc/default/locale
LANG=en_CA.UTF-8
LANGUAGE=en_CA:en
LC_TIME=en_CA.UTF-8

I have no idea where LC_CTYPE and LC_MESSAGES are being set. Nor do I 
understand why the LANG should be set to C rather than en_CA. However, 
when I made that change and rebooted, the errors vanished.


$ locale -a
C
C.utf8
en_CA.utf8
en_US.utf8
fr_CA.utf8
POSIX

$ locale
LANG=en_US.UTF-8
LANGUAGE=en_US
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=en_CA.UTF-8
LC_TIME=en_CA.UTF-8
LC_COLLATE=en_CA.UTF-8
LC_MONETARY=en_CA.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT=en_CA.UTF-8
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=


I can now successfully run jami!

Thanks.

Re: running Jami in Trixie - possible locale issue


On 2024-02-26 21:29, Max Nikulin wrote:

  env | grep 'LC_\|LANG'
    systemctl --user show-environment | grep 'LC_\|LANG'



 $ env | grep 'LC_\|LANG'
LANGUAGE=en_GB
LC_MONETARY=en_CA.UTF-8
LANG=iu_CA.UTF-8
LC_MEASUREMENT=en_CA.UTF-8
LC_TIME=en_CA.UTF-8
LC_COLLATE=en_CA.UTF-8
LC_NUMERIC=en_CA.UTF-8

$ systemctl --user show-environment | grep 'LC_\|LANG'
LANG=iu_CA.UTF-8
LANGUAGE=en_GB
LC_TIME=en_CA.UTF-8
LC_COLLATE=en_CA.UTF-8
LC_MEASUREMENT=en_CA.UTF-8
LC_MONETARY=en_CA.UTF-8
LC_NUMERIC=en_CA.UTF-8

They agree.

The en_GB seems to be coming from Plasma 5's Region & Language settings. 
However I see the message that it is "unsupported", which seems 
appropriate. When I change it to American English, the en_GB disappears 
from the available settings. When I try to "Add More...", I'm only given 
the options of "C" and "American English", neither of which I want. 
However the Spellcheck options do allow for English (Canada).

Re: running Jami in Trixie - possible locale issue


On 2024-02-26 20:43, Greg Wooledge wrote:

On Mon, Feb 26, 2024 at 08:28:01PM -0500, Gary Dale wrote:

$locale
locale: Cannot set LC_CTYPE to default locale: No such file
or directory
locale: Cannot set LC_MESSAGES to default locale: No such
file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=iu_CA.UTF-8
LANGUAGE=en_GB
LC_CTYPE="iu_CA.UTF-8"
LC_NUMERIC=en_CA.UTF-8
LC_TIME=en_CA.UTF-8
LC_COLLATE=en_CA.UTF-8
LC_MONETARY=en_CA.UTF-8
LC_MESSAGES="iu_CA.UTF-8"
LC_PAPER="iu_CA.UTF-8"
LC_NAME="iu_CA.UTF-8"
LC_ADDRESS="iu_CA.UTF-8"
LC_TELEPHONE="iu_CA.UTF-8"
LC_MEASUREMENT=en_CA.UTF-8
LC_IDENTIFICATION="iu_CA.UTF-8"
LC_ALL=

You've got three different locales mentioned here:

iu_CA.UTF-8
en_GB
en_CA.UTF-8


# locale -a
C
C.utf8
en_CA.utf8
en_US.utf8
fr_CA.utf8
POSIX

Out of the three that you're trying to use, only one has been generated.

Either generate the two that you're missing, or stop using them.


I'm trying to stop using them. That's the point. How do I get rid of 
them? They show up no matter how many times I reconfigure my locales.

Re: running Jami in Trixie - possible locale issue

2024-02-26 Thread Gary Dale


On 2024-02-26 17:31, Gremlin wrote:

On 2/26/24 17:18, Gary Dale wrote:

On 2024-02-26 16:03, Gremlin wrote:

On 2/26/24 14:36, Gary Dale wrote:
I'm running Debian/Trixie on an AMD64 system. I've installed jami 
from testing but it fails to start. When I run it from the command 
line, I get:


$jami &
[1] 7804
$ Using Qt runtime version: 6.
4.2
"notify server name: Plasma, vendor: KDE, version: 5.27.10, spec: 1.2"
"Using locale: en_GB"
terminate called after throwing an instance of 'std::runtime_error'
  what():  locale::facet::_S_create_c_locale name not valid

[1]+  Aborted (core dumped) jami
garydale@transponder:~/mnt/archives/2024/Lions Cl


There might be something wrong with my locales but dpkg-reconfigure 
locales doesn't fix it. After running it, I still get this output:


$locale
locale: Cannot set LC_CTYPE to default locale: No such file or 
directory
locale: Cannot set LC_MESSAGES to default locale: No such file or 
directory

locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=iu_CA.UTF-8
LANGUAGE=en_GB
LC_CTYPE="iu_CA.UTF-8"
LC_NUMERIC=en_CA.UTF-8
LC_TIME=en_CA.UTF-8
LC_COLLATE=en_CA.UTF-8
LC_MONETARY=en_CA.UTF-8
LC_MESSAGES="iu_CA.UTF-8"
LC_PAPER="iu_CA.UTF-8"
LC_NAME="iu_CA.UTF-8"
LC_ADDRESS="iu_CA.UTF-8"
LC_TELEPHONE="iu_CA.UTF-8"
LC_MEASUREMENT=en_CA.UTF-8
LC_IDENTIFICATION="iu_CA.UTF-8"
LC_ALL=

Please note that I have not selected iu_CA.utf8 nor en_GB in my 
locales.


Any ideas on how to fix this?

Thanks.



Edit /etc/locale.gen and enable the locale(s) you wish to use.
Then as root

locale-gen
dpkg-reconfigure locales

Nope. /etc/locale.gen was already correct. Running the commands then 
rebooting leaves me with the same error messages.


I also set up a ~/.bash_profile to set LANG to en_CA.UTF-8 but that 
also had no effect. The exact contents are:


LANG="en_CA.UTF-8"
export LANG




You are making a mess, when about to make a mess stop until you have 
researched your issue.


Start at the beginning not at the end..

Did you reboot or logout and login

dpkg-reconfigure locales is suppose to set /etc/default/locales 
correctly, it runs update-locale if I remember correctly.


cat /etc/locale.gen

# This file lists locales that you wish to have built. You can find a 
list
# of valid supported locales at /usr/share/i18n/SUPPORTED, and you can 
add

# user defined locales to /usr/local/share/i18n/SUPPORTED. If you change
# this file, you need to rerun locale-gen.
#

C.UTF-8 UTF-8
# aa_DJ ISO-8859-1
# aa_DJ.UTF-8 UTF-8
# aa_ER UTF-8
# aa_ER@saaho UTF-8
# aa_ET UTF-8
# af_ZA ISO-8859-1
# af_ZA.UTF-8 UTF-8
# agr_PE UTF-8
# ak_GH UTF-8
# am_ET UTF-8
# an_ES ISO-8859-15
# an_ES.UTF-8 UTF-8
# anp_IN UTF-8
# ar_AE ISO-8859-6
# ar_AE.UTF-8 UTF-8
# ar_BH ISO-8859-6
# ar_BH.UTF-8 UTF-8
# ar_DZ ISO-8859-6
# ar_DZ.UTF-8 UTF-8
# ar_EG ISO-8859-6
# ar_EG.UTF-8 UTF-8
# ar_IN UTF-8
# ar_IQ ISO-8859-6
# ar_IQ.UTF-8 UTF-8
# ar_JO ISO-8859-6
# ar_JO.UTF-8 UTF-8
# ar_KW ISO-8859-6
# ar_KW.UTF-8 UTF-8
# ar_LB ISO-8859-6
# ar_LB.UTF-8 UTF-8
# ar_LY ISO-8859-6
# ar_LY.UTF-8 UTF-8
# ar_MA ISO-8859-6
# ar_MA.UTF-8 UTF-8
# ar_OM ISO-8859-6
# ar_OM.UTF-8 UTF-8
# ar_QA ISO-8859-6
# ar_QA.UTF-8 UTF-8
# ar_SA ISO-8859-6
# ar_SA.UTF-8 UTF-8
# ar_SD ISO-8859-6
# ar_SD.UTF-8 UTF-8
# ar_SS UTF-8
# ar_SY ISO-8859-6
# ar_SY.UTF-8 UTF-8
# ar_TN ISO-8859-6
# ar_TN.UTF-8 UTF-8
# ar_YE ISO-8859-6
# ar_YE.UTF-8 UTF-8
# as_IN UTF-8
# ast_ES ISO-8859-15
# ast_ES.UTF-8 UTF-8
# ayc_PE UTF-8
# az_AZ UTF-8
# az_IR UTF-8
# be_BY CP1251
# be_BY.UTF-8 UTF-8
# be_BY@latin UTF-8
# bem_ZM UTF-8
# ber_DZ UTF-8
# ber_MA UTF-8
# bg_BG CP1251
# bg_BG.UTF-8 UTF-8
# bhb_IN.UTF-8 UTF-8
# bho_IN UTF-8
# bho_NP UTF-8
# bi_VU UTF-8
# bn_BD UTF-8
# bn_IN UTF-8
# bo_CN UTF-8
# bo_IN UTF-8
# br_FR ISO-8859-1
# br_FR.UTF-8 UTF-8
# br_FR@euro ISO-8859-15
# brx_IN UTF-8
# bs_BA ISO-8859-2
# bs_BA.UTF-8 UTF-8
# byn_ER UTF-8
# ca_AD ISO-8859-15
# ca_AD.UTF-8 UTF-8
# ca_ES ISO-8859-1
# ca_ES.UTF-8 UTF-8
# ca_ES@euro ISO-8859-15
# ca_ES@valencia UTF-8
# ca_FR ISO-8859-15
# ca_FR.UTF-8 UTF-8
# ca_IT ISO-8859-15
# ca_IT.UTF-8 UTF-8
# ce_RU UTF-8
# chr_US UTF-8
# ckb_IQ UTF-8
# cmn_TW UTF-8
# crh_UA UTF-8
# cs_CZ ISO-8859-2
# cs_CZ.UTF-8 UTF-8
# csb_PL UTF-8
# cv_RU UTF-8
# cy_GB ISO-8859-14
# cy_GB.UTF-8 UTF-8
# da_DK ISO-8859-1
# da_DK.UTF-8 UTF-8
# de_AT ISO-8859-1
# de_AT.UTF-8 UTF-8
# de_AT@euro ISO-8859-15
# de_BE ISO-8859-1
# de_BE.UTF-8 UTF-8
# de_BE@euro ISO-8859-15
# de_CH ISO-8859-1
# de_CH.UTF-8 UTF-8
# de_DE ISO-8859-1
# de_DE.UTF-8 UTF-8
# de_DE@euro ISO-8859-15
# de_IT ISO-8859-1
# de_IT.UTF-8 UTF-8
# de_LI.UTF-8 UTF-8
# de_LU ISO-8859-1
# de_LU.UTF-8 UTF-8
# de_LU@euro ISO-8859-15
# doi_IN UTF-8
# dsb_DE UTF-8
# dv_MV UTF-8
# dz_BT UTF-8
# el_CY ISO-8859-7
# el_CY.UTF-8 UTF-8
# el_GR ISO-8859-7
# el_GR.UTF-8 UTF-8
# el_GR@euro ISO-8859-7
# en_AG UTF-8
# en_AU ISO-8859-1
# en_AU.UTF-8 UTF-8
# en

Re: running Jami in Trixie - possible locale issue

2024-02-26 Thread Gary Dale


On 2024-02-26 16:03, Gremlin wrote:

On 2/26/24 14:36, Gary Dale wrote:
I'm running Debian/Trixie on an AMD64 system. I've installed jami 
from testing but it fails to start. When I run it from the command 
line, I get:


$jami &
[1] 7804
$ Using Qt runtime version: 6.
4.2
"notify server name: Plasma, vendor: KDE, version: 5.27.10, spec: 1.2"
"Using locale: en_GB"
terminate called after throwing an instance of 'std::runtime_error'
  what():  locale::facet::_S_create_c_locale name not valid

[1]+  Aborted (core dumped) jami
garydale@transponder:~/mnt/archives/2024/Lions Cl


There might be something wrong with my locales but dpkg-reconfigure 
locales doesn't fix it. After running it, I still get this output:


$locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or 
directory

locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=iu_CA.UTF-8
LANGUAGE=en_GB
LC_CTYPE="iu_CA.UTF-8"
LC_NUMERIC=en_CA.UTF-8
LC_TIME=en_CA.UTF-8
LC_COLLATE=en_CA.UTF-8
LC_MONETARY=en_CA.UTF-8
LC_MESSAGES="iu_CA.UTF-8"
LC_PAPER="iu_CA.UTF-8"
LC_NAME="iu_CA.UTF-8"
LC_ADDRESS="iu_CA.UTF-8"
LC_TELEPHONE="iu_CA.UTF-8"
LC_MEASUREMENT=en_CA.UTF-8
LC_IDENTIFICATION="iu_CA.UTF-8"
LC_ALL=

Please note that I have not selected iu_CA.utf8 nor en_GB in my locales.

Any ideas on how to fix this?

Thanks.



Edit /etc/locale.gen and enable the locale(s) you wish to use.
Then as root

locale-gen
dpkg-reconfigure locales

Nope. /etc/locale.gen was already correct. Running the commands then 
rebooting leaves me with the same error messages.


I also set up a ~/.bash_profile to set LANG to en_CA.UTF-8 but that also 
had no effect. The exact contents are:


LANG="en_CA.UTF-8"
export LANG

running Jami in Trixie - possible locale issue

2024-02-26 Thread Gary Dale

I'm running Debian/Trixie on an AMD64 system. I've installed jami from 
testing but it fails to start. When I run it from the command line, I get:


$jami &
[1] 7804
$ Using Qt runtime version: 6.
4.2
"notify server name: Plasma, vendor: KDE, version: 5.27.10, spec: 1.2"
"Using locale: en_GB"
terminate called after throwing an instance of 'std::runtime_error'
 what():  locale::facet::_S_create_c_locale name not valid

[1]+  Aborted (core dumped) jami
garydale@transponder:~/mnt/archives/2024/Lions Cl


There might be something wrong with my locales but dpkg-reconfigure 
locales doesn't fix it. After running it, I still get this output:


$locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=iu_CA.UTF-8
LANGUAGE=en_GB
LC_CTYPE="iu_CA.UTF-8"
LC_NUMERIC=en_CA.UTF-8
LC_TIME=en_CA.UTF-8
LC_COLLATE=en_CA.UTF-8
LC_MONETARY=en_CA.UTF-8
LC_MESSAGES="iu_CA.UTF-8"
LC_PAPER="iu_CA.UTF-8"
LC_NAME="iu_CA.UTF-8"
LC_ADDRESS="iu_CA.UTF-8"
LC_TELEPHONE="iu_CA.UTF-8"
LC_MEASUREMENT=en_CA.UTF-8
LC_IDENTIFICATION="iu_CA.UTF-8"
LC_ALL=

Please note that I have not selected iu_CA.utf8 nor en_GB in my locales.

Any ideas on how to fix this?

Thanks.

Re: Can't list root directory

2024-02-17 Thread Gary Dale

On 2024-02-01 02:37, Loren M. Lang wrote:

On January 31, 2024 1:28:37 PM PST, hw wrote:

On Wed, 2024-01-31 at 09:27 -0500, Gary Dale wrote:

On 2024-01-30 15:54, hw wrote:

On Mon, 2024-01-29 at 11:42 -0500, Gary Dale wrote:

I'm running Debian/Trixie on an AMD64 workstation. I've lost the ability
to see the root directory even when I am logged in as root (su -).

This has been happening intermittently for several months. I initially
thought it might be related to failing NVME drive that was part of a
RAID1 array that is mounted as "/" but I replaced the device and the
problem is still happening.
[...]

What happens when you put the device you replaced back?

How could putting a known-failing device back in help? The problem
existed before I replaced it and continues to exist after the replacement.

It sounded like you were able to list the root directory (at least
sometimes) before you did the replacement. Manually failing the
device (perhaps after adding it back first) could make a difference.

I've seen such indefinite hangs only when an NFS share has become
unreachable after it had been mounted. You could use clonezilla to
make a copy and then perhaps convert the file system to btrfs.

Do you still have the problem when you remove one of the NVME storage
things? Perhaps you have the equivivalent of a bad SATA cable or the
mainboard doesn't like it when you access two of those at the same
time, or something like that. Even simple network cables can behave
very strangely, and NVME may be a bit more complicated than that.

Running fsck on every boot to work around an issue like this is
certainly a bad idea. Doesn't fsck report anything? If it really
makes a difference in itself rather than creating some side effect
that leads to the root directory being readable, it should report
something. Perhaps you need to increase its verbosity.

If there's no report then it would look like a side effect and raise
the question what side effect it might be. Does fsck run before the
RAID has been brought up or after? Is the RAID up when booting is
completed? What does mdadm say about the device(s)? Can you still
list the root directory when you manually fail either drive? What
exactly are the circumstances under which you can and not list the
root directory?

You need to do some investigating and ask questions like those ...

Also, instead of doing "ls -l /" which will stat() every child folder under root, try "/bin/ls
-f /" and see if that is successful. That will only do a readdir() on root itself. Also, it might be
interesting to get a log of "strace ls -l /" to confirm exactly where the hang happens.

-Loren

Thanks loren. /bin/ls -l works. The strace shows the hang is on
/keybase. The strace did a really bad hang - ctrlC wouldn't kill it.
I've set the fsck count to 1 again, so I can reboot and take a look at it.

Re: Can't list root directory

2024-02-02 Thread Gary Dale


On 2024-01-31 12:02, Max Nikulin wrote:

On 29/01/2024 23:42, Gary Dale wrote:

"ls -l /" just hangs


It may dereference symlinks, call stat, etc. to colorize output. May 
it happen that you have automount points or something related to 
network mounts?


Does "echo /*" hangs?

Even bash prompt may do some funny stuff. I would try it from "dash".

Can you install strace? E.g. copy files while booted from a live media.

Thanks everyone for the suggestions. I'll retune the array to not fsck 
every boot and see if the problem recurs so I can try your suggestions.

Re: Can't list root directory

2024-01-31 Thread Gary Dale


On 2024-01-29 12:55, Hans wrote:

Hi Gary,

before loosing any data, I suggest, to boot from a liuvefile linux. Please use
a modern livefile like Knoppix or Kali-Linux.

If it is not a BIOS problem, you should see the device again and are able to
mount it. If /root is on a seperated partition, you can do some filesystem
checks, like e2fsck or else.

Ans: Most important, with a livefile system you can mount an external harddrive
and backup all files. Thus , even when the /dev/nvme*** is died or partly
broken, you can maybe restore /root on another partition.

Second: Please check ACL, although I do not believe the reason for these, it
is worth to look at this. Maybe you or someone else has chenged it accidently.

Third idea: Is the harddrive full? In the past I has the problem, not to be
able to do anything. The reason: My harddrive was completely full (some
temporary file was the reason). Deleting this big file was the trick.

Just some ideas, maybe it could help.

Good luck!

Best

Hans


There is no problem seeing the root folder when I boot from a live distro.

fsck never finds any significant issue.

An ACL issue would be permanent. This comes and goes.

I actually doubled the size of the root device when I put in the new 
NVME drive. When I set up the RAID array, I'd bought a 500G second drive 
to mirror the 256G original drive. When I replaced the 256G drive, I was 
able to expand the array to 500G (less a small amount for the EFI 
partition). The partition has lots of free space.


As I said, running an fsck seems to fix the issue temporarily. I now run 
an fsck on every boot.

Re: Can't list root directory

2024-01-31 Thread Gary Dale


On 2024-01-29 11:42, Gary Dale wrote:
I'm running Debian/Trixie on an AMD64 workstation. I've lost the 
ability to see the root directory even when I am logged in as root (su 
-).


This has been happening intermittently for several months. I initially 
thought it might be related to failing NVME drive that was part of a 
RAID1 array that is mounted as "/" but I replaced the device and the 
problem is still happening.


I had been able to fix it by booting to SystemRescue and running an 
fsck on the device but it didn't work this time. The device checks out 
OK (even when using fsck -/dev/mdx -f) but I still can't list the 
root. "ls -l /" just hangs, as do any attempts to see the root 
directory in a graphical file manager. In dolphin this means there is 
nothing in the folders - and since that is the default starting point 
I have to manually enter a folder name (e.g. /home/me) in the location 
bar to be able to see anything - but even then the folders panel 
remains empty.


Even running commands like df -h hang because they can't access the 
root folder. However the system is otherwise running normally.


Strangely, in the past simply booting to a rescue shell then exiting 
would also work. I'd usually try to do an fsck on the raid device but 
that would always fail because it was mounted.


The only thing I noticed that was unusual was I rebooted after 
installing the latest Trixie updates this morning. That took about 10 
minutes to shut down - 6 of which were spent waiting for a drkonqi 
process to finish. There was also a systemd message really late in the 
shutdown about /dev/md0 but that's not the root device.


I'm used to Linux taking its time to shutdown lately so I don't think 
this was related. The systemd shutdown just seems to be easily delayed.


Any ideas on how I can restore my ability to see the root directory?

OK, got it working again. I used tune2fs to do an fsck on every boot. 
This being an NVME device, it's barely noticeable.

Re: Can't list root directory

2024-01-31 Thread Gary Dale


On 2024-01-30 15:54, hw wrote:

On Mon, 2024-01-29 at 11:42 -0500, Gary Dale wrote:

I'm running Debian/Trixie on an AMD64 workstation. I've lost the ability
to see the root directory even when I am logged in as root (su -).

This has been happening intermittently for several months. I initially
thought it might be related to failing NVME drive that was part of a
RAID1 array that is mounted as "/" but I replaced the device and the
problem is still happening.
[...]

What happens when you put the device you replaced back?

How could putting a known-failing device back in help? The problem 
existed before I replaced it and continues to exist after the replacement.

Can't list root directory

2024-01-29 Thread Gary Dale

I'm running Debian/Trixie on an AMD64 workstation. I've lost the ability 
to see the root directory even when I am logged in as root (su -).


This has been happening intermittently for several months. I initially 
thought it might be related to failing NVME drive that was part of a 
RAID1 array that is mounted as "/" but I replaced the device and the 
problem is still happening.


I had been able to fix it by booting to SystemRescue and running an fsck 
on the device but it didn't work this time. The device checks out OK 
(even when using fsck -/dev/mdx -f) but I still can't list the root. "ls 
-l /" just hangs, as do any attempts to see the root directory in a 
graphical file manager. In dolphin this means there is nothing in the 
folders - and since that is the default starting point I have to 
manually enter a folder name (e.g. /home/me) in the location bar to be 
able to see anything - but even then the folders panel remains empty.


Even running commands like df -h hang because they can't access the root 
folder. However the system is otherwise running normally.


Strangely, in the past simply booting to a rescue shell then exiting 
would also work. I'd usually try to do an fsck on the raid device but 
that would always fail because it was mounted.


The only thing I noticed that was unusual was I rebooted after 
installing the latest Trixie updates this morning. That took about 10 
minutes to shut down - 6 of which were spent waiting for a drkonqi 
process to finish. There was also a systemd message really late in the 
shutdown about /dev/md0 but that's not the root device.


I'm used to Linux taking its time to shutdown lately so I don't think 
this was related. The systemd shutdown just seems to be easily delayed.


Any ideas on how I can restore my ability to see the root directory?

Is there a problem with Linux-image-6.1.0-16?

2023-12-21 Thread Gary Dale

Several days ago my main server upgraded to kernel 6.1.0-16 but various 
other devices that are also running Bookworm seem stuck at 6.1.0-13. 
They are all using the same architecture. Some are using the same mirror 
as the server that upgraded. I haven't set any special policies on upgrades.


Can anyone explain what's going on?

Re: IMPORTANT: do NOT upgrade to new stable point release

2023-12-11 Thread Gary Dale


On 2023-12-09 13:09, Dan Ritter wrote:


https://fulda.social/@Ganneff/111551628003050712

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057843

The new kernel release is reported to contain an ext4 data
corruption bug. It's prudent not to upgrade, or if you have
started to upgrade, not to reboot, until a new kernel release
is prepared.


-dsr-

Pleased to note that 6.1.0-15 seems to have hit the mirrors now. I 
assume this is the fixed version.

Re: IMPORTANT: do NOT upgrade to new stable point release

2023-12-10 Thread Gary Dale


On 2023-12-10 11:56, Andrew M.A. Cater wrote:

On Sun, Dec 10, 2023 at 11:50:18AM -0500, Gary Dale wrote:

On 2023-12-09 14:18, Michael Kjörling wrote:

On 9 Dec 2023 20:54 +0200, from ale...@nanoid.net (Alexis Grigoriou):

I just upgraded to Bookworm this morning. I did reboot a couple of
times but there seems to be no problem (yet). Is there anything I
should look for or do other than rebooting?

If you upgraded this morning, then I would expect that you are okay
for now.

Per #5 in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057843
the bug is present in kernel Debian package version 6.1.64-1. If you
are on 6.1.55-1 (current Bookworm stable per last night) you _likely_
aren't affected. If you are on 6.1.55-1 (or earlier), just hold off on
upgrades for now; and if you need to upgrade something else, take
great care for now to ensure that no Linux kernel packages get
upgraded to any version < 6.1.66, and preferably not < 6.1.66-1.

For versions, check:

* uname -v
* dpkg -l linux-image-\*

In that bug report thread, #21 lists 6.1.66 as fixed upstream, and #28
indicates that 6.1.66-1 includes the fix from upstream, and that it is
being published.


Any idea when the fixed version will hit stable? With headless servers, it's
a pain to downgrade to a previous kernel version.


Give them a little while: release team are working on it right now as I type

I'm fairly sure they're pushing it out more or less immediately once they're
sure that it's built correctly and synced to all the appropriate places to
be further synced to mirrors

"Now" is almost exactly Sun 10 Dec 16:55:43 UTC 2023

Andy
(amaca...@debian.org)

Thanks. I logged into each of my headless servers and removed the 
problematic kernel then rebooted them so they are all at 6.1.0-13 now.

Re: IMPORTANT: do NOT upgrade to new stable point release

2023-12-10 Thread Gary Dale




On 2023-12-10 12:24, Greg Wooledge wrote:

On Sun, Dec 10, 2023 at 05:09:15PM -, Curt wrote:

On 2023-12-10, Andrew M.A. Cater  wrote:

"Now" is almost exactly Sun 10 Dec 16:55:43 UTC 2023

You mean in the Zulu Time Zone (as I am all at sea)?

Use "date -u" to see current UTC time.  That should be sufficient to
let you know how long it has been since Andrew's "now".

You're getting too complicated. The date stamp on his e-mail will 
display the correct local time (as you have set it) so I can see that he 
wrote it 30 minutes ago. That relative time is universal across time zones.

Re: IMPORTANT: do NOT upgrade to new stable point release

2023-12-10 Thread Gary Dale


On 2023-12-09 14:18, Michael Kjörling wrote:

On 9 Dec 2023 20:54 +0200, from ale...@nanoid.net (Alexis Grigoriou):

I just upgraded to Bookworm this morning. I did reboot a couple of
times but there seems to be no problem (yet). Is there anything I
should look for or do other than rebooting?

If you upgraded this morning, then I would expect that you are okay
for now.

Per #5 in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057843
the bug is present in kernel Debian package version 6.1.64-1. If you
are on 6.1.55-1 (current Bookworm stable per last night) you _likely_
aren't affected. If you are on 6.1.55-1 (or earlier), just hold off on
upgrades for now; and if you need to upgrade something else, take
great care for now to ensure that no Linux kernel packages get
upgraded to any version < 6.1.66, and preferably not < 6.1.66-1.

For versions, check:

* uname -v
* dpkg -l linux-image-\*

In that bug report thread, #21 lists 6.1.66 as fixed upstream, and #28
indicates that 6.1.66-1 includes the fix from upstream, and that it is
being published.

Any idea when the fixed version will hit stable? With headless servers, 
it's a pain to downgrade to a previous kernel version.

CUPS classes wrecking printing

2023-12-09 Thread Gary Dale

I've running Debian/Bookworm (stable) on an AMD64 system - a laptop. 
It's a fresh install of Debian from about 6 months back that has been 
kept up to date.


Each December I am involved in an event that requires me to use 3 
photo-printers to print a lot of 4x6 photos. It takes 2 or 3 printers to 
get the throughput so people aren't waiting for their photos.


I've been doing this for a decade using various photo printers. I've 
always just set up a CUPS "photo" class and added the printers to it. 
Then I'd use lpr -P photo  to send the 
output to whichever printer was free. I even did it last year using the 
same laptop and printers and things worked.


This year, because it was a new OS install, I had to connect the 
printers and install them again. This required the gutenprint drivers 
for two of the printers while the newest seems to work "driverless".


All the printers were tested individually and printed the CUPS test page 
perfectly.


However when I sent something to the "photo" class, whichever printer 
received the job just printed a page of bands of colour. I could send a 
picture to an individual printer OK but not send it to the "photo" class.


I got through the event by skipping the lpr -P photo... command and 
manually selecting a printer from Gwenview when I was viewing the 
picture earlier in the workflow (to verify it was worth printing). This 
was not ideal and I only got through it because this year's event was 
less than half its usual size.


This was not an lpr problem because I also couldn't print to the class 
from Gwenview. CUPS classes seem to be broken.

Re: balenaEtcher installation problems

2023-11-10 Thread Gary L. Roach




On 11/9/23 18:22, Jeffrey Walton wrote:

On Thu, Nov 9, 2023 at 8:47 PM Gary L. Roach  wrote:

Operating System: Debian GNU/Linux 12
KDE Plasma Version: 5.27.5
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
Kernel Version: 6.1.0-13-amd64 (64-bit)
Graphics Platform: Wayland
Processors: 4 × AMD FX(tm)-4350 Quad-Core Processor
Memory: 31.2 GiB of RAM
Graphics Processor: AMD CAICOS
Manufacturer: MSI
Product Name: MS-7974
System Version: 1.0

I have been trying to install balenaEtcher for 2 days but can't get rid of the 
following errors :

ERROR:ozone_platform_x11.cc(247)] Missing X server or $DISPLAY
[10145:1109/120137.666202:ERROR:env.cc(226)] The platform failed to initialize. 
 Exiting

I have tried everything I could find with google searches to no avail. My 
$DISPLAY variable is blank which may be the source of the problem.But what 
should it contain?

I know that the information I am giving is a bit sketchy but is the best I can 
do at this point. There are lots of fixes listed on the internet but none of 
them work. I am using the .deb file down loaded from the balena web page and 
installing it with dpkg -i .

Any help will be sincerely appreciated.

Try `export DISPLAY=":0.0"`.

Jeff


I just solved the problem. I was missing 4 dependencies. One must use 
the .deb file not the appimage file and run dpkg -I  and 
install the missing items.


I hope this helps others

Thanks

Gary R

balenaEtcher installation problem

2023-11-09 Thread Gary L. Roach


Hi all

Operating System: Debian GNU/Linux 12
KDE Plasma Version: 5.27.5
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
Kernel Version: 6.1.0-13-amd64 (64-bit)
Graphics Platform: Wayland
Processors: 4 × AMD FX(tm)-4350 Quad-Core Processor
Memory: 31.2 GiB of RAM
Graphics Processor: AMD CAICOS
Manufacturer: MSI
Product Name: MS-7974
System Version: 1.0

I have been trying to install the balenaEtcher software package 
*balenaEtcher-1.18.11-x64.AppImage *for 2 days without success. I keep 
getting the following error:


*ERROR:ozone_platform_x11.cc(247)] Missing X server or $DISPLAY
[10145:1109/120137.666202:ERROR:env.cc(226)] The platform failed to 
initialize.  Exiting*


I have been searching the internet for solutions and have found many 
listings but none of them work. My $DISPLAY variable is empty which may 
be the source of the problem but what should it hold? I am using the 
.deb file downloaded from the balena web sight. Sorry if this 
information is a bit sketchy but is the best I can do at this point.


Any help on this problem will be sincerely appreciated. i really need a 
package that can handle burning .iso files to SD cards and this seems to 
be the best out there.


Gary R

*
*

balenaEtcher installation problems

2023-11-09 Thread Gary L. Roach


Operating System: Debian GNU/Linux 12
KDE Plasma Version: 5.27.5
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
Kernel Version: 6.1.0-13-amd64 (64-bit)
Graphics Platform: Wayland
Processors: 4 × AMD FX(tm)-4350 Quad-Core Processor
Memory: 31.2 GiB of RAM
Graphics Processor: AMD CAICOS
Manufacturer: MSI
Product Name: MS-7974
System Version: 1.0

I have been trying to install balenaEtcher for 2 days but can't get rid 
of the following errors :


*ERROR:ozone_platform_x11.cc(247)] Missing X server or $DISPLAY
[10145:1109/120137.666202:ERROR:env.cc(226)] The platform failed to 
initialize.  Exiting*


I have tried everything I could find with google searches to no avail. 
My $DISPLAY variable is blank which may be the source of the problem.But 
what should it contain?


I know that the information I am giving is a bit sketchy but is the best 
I can do at this point. There are lots of fixes listed on the internet 
but none of them work. I am using the .deb file down loaded from the 
balena web page and installing it with dpkg -i .


Any help will be sincerely appreciated.

Gary R.

Re: network bonding on Debian/Trixie

2023-10-17 Thread Gary Dale


On 2023-10-16 21:20, Igor Cicimov wrote:



On Tue, Oct 17, 2023 at 12:12 PM Gary Dale  wrote:

On 2023-10-16 18:52, Igor Cicimov wrote:

Hi,

On Tue, Oct 17, 2023, 8:00 AM Gary Dale 
wrote:

I'm trying to configure network bonding on an AMD64 system
running
Debian/Trixie. I've got a wired connection and a wifi
connection, both
of which work individually. I'd like them to work together to
improve
the throughput but for now I'm just trying to get the bond to
work.
However when I configure them, the wifi interface always
shows down.

# ip addr
1: lo:  mtu 65536 qdisc noqueue state
UNKNOWN
group default qlen 1000
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 inet 127.0.0.1/8 <http://127.0.0.1/8> scope host lo
    valid_lft forever preferred_lft forever
 inet6 ::1/128 scope host noprefixroute
    valid_lft forever preferred_lft forever
2: enp10s0:  mtu 1500
qdisc mq
master bond0 state UP group default qlen 1000
 link/ether 3c:7c:3f:ef:15:47 brd ff:ff:ff:ff:ff:ff
4: wlxc4411e319ad5:  mtu 1500 qdisc noop
state DOWN
group default qlen 1000
 link/ether c4:41:1e:31:9a:d5 brd ff:ff:ff:ff:ff:ff
7: bond0:  mtu 1500
qdisc
noqueue state UP group default qlen 1000
 link/ether 3c:7c:3f:ef:15:47 brd ff:ff:ff:ff:ff:ff
 inet 192.168.1.20/24 <http://192.168.1.20/24> brd
192.168.1.255 scope global bond0
    valid_lft forever preferred_lft forever
 inet6 fe80::3e7c:3fff:feef:1547/64 scope link proto
kernel_ll
    valid_lft forever preferred_lft forever

It does this even if I pull the cable from the wired
connection. The
wifi never comes up.

Here's the /etc/network/interfaces file:

auto lo
iface lo inet loopback

auto enp10s0
iface enp10s0 inet manual
 bond-master bond0
 bond-mode 1

auto wlxc4411e319ad5
iface wlxc4411e319ad5 inet manual
 bond-master bond0
 bond-mode 1

auto bond0
iface bond0 inet static
 address 192.168.1.20
 netmask 255.255.255.0
 network 192.168.1.0
 gateway 192.168.1.1
 bond-slaves enp10s0 wlxc4411e319ad5
 bond-mode 1
 bond-miimon 100
 bond-downdelay 200
 bond-updelay 200


I'd like to get it to work in a faster mode but for now the
backup at
least allows the networking to start without the wifi. Other
modes seem
to disable networking until both interfaces come up, which is
not a good
design decision IMHO. At least with mode 1, the network starts.

Any ideas on how to get the wifi to work in bonding?


Probably your wifi card does not support MII, check with:

~]# ethtool  wlxc4411e319ad5 | grep "Link detected:"

and:

~]# cat /proc/net/bonding/bind0



I'm assuming that no output is bad here. Still, I don't see why a
device that works shouldn't be able to participate in a bond. As a
network interface, the wifi device produces and responds to
network traffic. Are you saying the bonding takes place below the
driver level?


I'm saying the bonding driver is doing its own link detection on the 
presented interfaces for failover purposes. It can use ARP or MII. You 
can not enable MII on an interface that does not support that 
functionality. Use mii-tool to check both interfaces and see the 
difference.


Apparently neither interface supports it. According to what I have read, 
calling mii-tool with no parameters should return a terse list of all 
interfaces that support it. However, when I try that, I get "No 
interface specified". Moreover,


# mii-tool  enp10s0
SIOCGMIIPHY on 'enp10s0' failed: Operation not supported

# mii-tool wlxc4411e319ad5
SIOCGMIIPHY on 'wlxc4411e319ad5' failed: Operation not supported

which seems weird given that I have a recent, mainstream ASUS mainboard 
with a generic realtek onboard NIC that seems to be participating in the 
bonding.


I've also not seen any warnings that bonding requires a specific (and 
apparently rare) type of NIC. Indeed, my laptop seems to fail over 
nicely between ethernet and wifi.


Perhaps mii-tool is broken on Trixie?

Re: network bonding on Debian/Trixie

2023-10-16 Thread Gary Dale


On 2023-10-16 18:52, Igor Cicimov wrote:

Hi,

On Tue, Oct 17, 2023, 8:00 AM Gary Dale  wrote:

I'm trying to configure network bonding on an AMD64 system running
Debian/Trixie. I've got a wired connection and a wifi connection,
both
of which work individually. I'd like them to work together to improve
the throughput but for now I'm just trying to get the bond to work.
However when I configure them, the wifi interface always shows down.

# ip addr
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1000
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 inet 127.0.0.1/8 <http://127.0.0.1/8> scope host lo
    valid_lft forever preferred_lft forever
 inet6 ::1/128 scope host noprefixroute
    valid_lft forever preferred_lft forever
2: enp10s0:  mtu 1500 qdisc mq
master bond0 state UP group default qlen 1000
 link/ether 3c:7c:3f:ef:15:47 brd ff:ff:ff:ff:ff:ff
4: wlxc4411e319ad5:  mtu 1500 qdisc noop
state DOWN
group default qlen 1000
 link/ether c4:41:1e:31:9a:d5 brd ff:ff:ff:ff:ff:ff
7: bond0:  mtu 1500 qdisc
noqueue state UP group default qlen 1000
 link/ether 3c:7c:3f:ef:15:47 brd ff:ff:ff:ff:ff:ff
 inet 192.168.1.20/24 <http://192.168.1.20/24> brd
192.168.1.255 scope global bond0
    valid_lft forever preferred_lft forever
 inet6 fe80::3e7c:3fff:feef:1547/64 scope link proto kernel_ll
    valid_lft forever preferred_lft forever

It does this even if I pull the cable from the wired connection. The
wifi never comes up.

Here's the /etc/network/interfaces file:

auto lo
iface lo inet loopback

auto enp10s0
iface enp10s0 inet manual
 bond-master bond0
 bond-mode 1

auto wlxc4411e319ad5
iface wlxc4411e319ad5 inet manual
 bond-master bond0
 bond-mode 1

auto bond0
iface bond0 inet static
 address 192.168.1.20
 netmask 255.255.255.0
 network 192.168.1.0
 gateway 192.168.1.1
 bond-slaves enp10s0 wlxc4411e319ad5
 bond-mode 1
 bond-miimon 100
 bond-downdelay 200
 bond-updelay 200


I'd like to get it to work in a faster mode but for now the backup at
least allows the networking to start without the wifi. Other modes
seem
to disable networking until both interfaces come up, which is not
a good
design decision IMHO. At least with mode 1, the network starts.

Any ideas on how to get the wifi to work in bonding?


Probably your wifi card does not support MII, check with:

~]# ethtool  wlxc4411e319ad5 | grep "Link detected:"

and:

~]# cat /proc/net/bonding/bind0



I'm assuming that no output is bad here. Still, I don't see why a device 
that works shouldn't be able to participate in a bond. As a network 
interface, the wifi device produces and responds to network traffic. Are 
you saying the bonding takes place below the driver level?

network bonding on Debian/Trixie

2023-10-16 Thread Gary Dale

I'm trying to configure network bonding on an AMD64 system running 
Debian/Trixie. I've got a wired connection and a wifi connection, both 
of which work individually. I'd like them to work together to improve 
the throughput but for now I'm just trying to get the bond to work. 
However when I configure them, the wifi interface always shows down.


# ip addr
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN 
group default qlen 1000

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
   valid_lft forever preferred_lft forever
2: enp10s0:  mtu 1500 qdisc mq 
master bond0 state UP group default qlen 1000

    link/ether 3c:7c:3f:ef:15:47 brd ff:ff:ff:ff:ff:ff
4: wlxc4411e319ad5:  mtu 1500 qdisc noop state DOWN 
group default qlen 1000

    link/ether c4:41:1e:31:9a:d5 brd ff:ff:ff:ff:ff:ff
7: bond0:  mtu 1500 qdisc 
noqueue state UP group default qlen 1000

    link/ether 3c:7c:3f:ef:15:47 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.20/24 brd 192.168.1.255 scope global bond0
   valid_lft forever preferred_lft forever
    inet6 fe80::3e7c:3fff:feef:1547/64 scope link proto kernel_ll
   valid_lft forever preferred_lft forever

It does this even if I pull the cable from the wired connection. The 
wifi never comes up.


Here's the /etc/network/interfaces file:

auto lo
iface lo inet loopback

auto enp10s0
iface enp10s0 inet manual
    bond-master bond0
    bond-mode 1

auto wlxc4411e319ad5
iface wlxc4411e319ad5 inet manual
    bond-master bond0
    bond-mode 1

auto bond0
iface bond0 inet static
    address 192.168.1.20
    netmask 255.255.255.0
    network 192.168.1.0
    gateway 192.168.1.1
    bond-slaves enp10s0 wlxc4411e319ad5
    bond-mode 1
    bond-miimon 100
    bond-downdelay 200
    bond-updelay 200


I'd like to get it to work in a faster mode but for now the backup at 
least allows the networking to start without the wifi. Other modes seem 
to disable networking until both interfaces come up, which is not a good 
design decision IMHO. At least with mode 1, the network starts.


Any ideas on how to get the wifi to work in bonding?

Re: SMART error messages being sent to the wrong address


On 2023-10-04 02:43, Jeffrey Walton wrote:

On Tue, Oct 3, 2023 at 9:32 PM Gary Dale  wrote:

I'm running Debian/Bookworm on a headless server. The box has had a
variety of roles and names. At one time it was called fanny after the
groundbreaking rock band and because it had a lot of fans in it. This
latter attribute led to it being made into a file server and renamed
BigData.

The problem I'm having is that SMART error messages are being sent to
root@fanny. instead of to me. /etc/aliases has all mail to
root going to me, but because this addressed to root on a machine with a
different name, it goes out and I only get the message when it bounces
(because the machine name no longer exists).

I can't find where the e-mail address is being set. Tracing down the
smartmontools config files didn't turn up any obvious problems.

Can anyone point in the right direction?

If Greg and Charles' suggestions do not work, I would grep for it.

 $ sudo su -
 $ grep -iIR fanny /etc

That should uncover places the old name shows up.

Jeff

Thanks Jeff. It looks like it came from /etc/mailname.

Re: SMART error messages being sent to the wrong address


On 2023-10-04 03:22, to...@tuxteam.de wrote:

On Wed, Oct 04, 2023 at 02:43:36AM -0400, Jeffrey Walton wrote:

[...]


 $ sudo su -

...better spelt these days as "sudo -i" (or "sudo -s"), see sudo(1)'s
man page.


Or sudo bash - or whatever your preferred shell is.

Re: SMART error messages being sent to the wrong address


On 2023-10-03 22:31, Greg Wooledge wrote:

On Tue, Oct 03, 2023 at 09:02:39PM -0500, John Hasler wrote:

Add a CNAME record to your DNS.

Mail delivery is supposed to ignore CNAME records.  Perhaps you meant
to say an MX record.  But either way, the OP's question is still not
answered -- where is the recipient address configured?

My guess would be "in the system's MTA".  I'm guessing the SMART tools
are simply sending to "root" with no domain, and relying on the system's
MTA to fill in the recipient domain.  I'm guessing this MTA is not
configured properly.

The OP should verify this by running something like:

 echo test | mailx -s test root

And see how the message headers get written, and where the message goes.
If it turns out my guesses are right and the MTA is misconfigured, then
we'll know the next steps.

If it turns out my guesses are wrong, and the MTA is fine, then we'll
have to figure out how these SMART tools are configured.
Other mail from that server is being sent properly. It's just the SMART 
messages that are going to the wrong place.

Re: SMART error messages being sent to the wrong address


On 2023-10-03 23:39, Charles Curley wrote:

On Tue, 3 Oct 2023 20:57:57 -0400
Gary Dale  wrote:


I can't find where the e-mail address is being set. Tracing down the
smartmontools config files didn't turn up any obvious problems.

The email address is set with the -m option in the file
/etc/smartd.conf. I'd check that to see if you changed it from the
default ('root'). And you should be able to set it to what you want.

No. The -m option is "root".

SMART error messages being sent to the wrong address

2023-10-03 Thread Gary Dale

I'm running Debian/Bookworm on a headless server. The box has had a 
variety of roles and names. At one time it was called fanny after the 
groundbreaking rock band and because it had a lot of fans in it. This 
latter attribute led to it being made into a file server and renamed 
BigData.


The problem I'm having is that SMART error messages are being sent to 
root@fanny. instead of to me. /etc/aliases has all mail to 
root going to me, but because this addressed to root on a machine with a 
different name, it goes out and I only get the message when it bounces 
(because the machine name no longer exists).


I can't find where the e-mail address is being set. Tracing down the 
smartmontools config files didn't turn up any obvious problems.


Can anyone point in the right direction?

Thanks

wierd document under /run/user/1000 directory

2023-08-23 Thread Gary L. Roach


drwxr-xr-x 2 gary gary 120 Aug 20 10:19 akonadi
drwx-- 2 gary gary  60 Aug 20 10:19 at-spi
srw-rw-rw- 1 gary gary   0 Aug 20 10:18 bus
drwx-- 3 gary gary  60 Aug 20 10:18 dbus-1
drwx-- 2 gary gary  60 Aug 20 10:18 dconf
*d? ? ?    ?  ?    ? doc*

What is with the last entry on the above list.This is the contents of my 
/run/user/1000 directory. I can't change its characteristics and can't 
delete it. It is messing up several processes like rsync. Any help will 
be sincerely appreciated.


Gary R.

keybase upgrade / install fails

2023-08-10 Thread Gary Dale

I'm running Debian/Bookworm on an AMD64 system. For the last two or 
three weeks I've been getting messages like below when I use apt: The 
keybase package doesn't seem to configure properly so apt keeps trying, 
and failing, to finish the package installation. Removing it (not 
purging) then reinstalling doesn't help.


Setting up keybase (6.2.2-20230726175256.4464bfb32d) ...
Autorestarting Keybase via systemd for 
mkdir: cannot stat ‘/keybase’: Transport endpoint is not connected
chown: cannot access '/keybase': Transport endpoint is not connected
chmod: cannot access '/keybase': Transport endpoint is not connected
dpkg:error processing package keybase (--configure):
installed keybase package post-installation script subprocess returned 
error exit status 1

Errors were encountered while processing:
keybase
E: Sub-process /usr/bin/dpkg returned an error code (1)

Any suggestions?

Re: laptop stopped getting to desktop after latest updates [RESOLVED]

2023-05-27 Thread Gary Dale


On 2023-05-19 23:32, Gary Dale wrote:
I'm running Debian/Bookworm on an ASUS FA506IC laptop. It's got an AMD 
Ryzen processor but an NVidia graphics card that provides me with 
great evidence for why I had previously avoided NVidia cards. I'm 
running Bookworm because I couldn't get it work on Bullseye.


It'd been running OK with the proprietary drivers (but not the 
Nouveau) until earlier today. I don't use it very often so it was 
probably a few weeks since I last updated it. I had trouble the 
previous time I'd updated it too, but that was the move to the 
non-free-firmware section that messed it up. Once I added the new 
section to the sources, things worked again.


The symptoms I'm getting are the same as what it used to display when 
I tried to use sddm to start the desktop. Gdm3 and lightdm both worked 
in the past but now I'm getting the same symptom with all of them - a 
blank screen with a cursor flashing in the top-left corner. At that 
point I can't even bring up a text console, but I can reboot 
(ctrl-alt-del still works).


I can boot to a recovery mode and start the network, but not sure how 
to track this down. Removing and reinstalling the NVidia driver didn't 
help. Trying to start the desktop without the NVidia driver (and 
firmware) installed also didn't work. I still get the system booting 
to a blank screen with a flashing cursor in the top let corner.


Any ideas?

Thanks.

I got some time this afternoon to play around with the system. My first 
effort was to go back to Debian/Bullseye (11.7) and do a fresh install. 
Surprisingly, it worked this time. I could boot into Gnome without 
problems. However I had no wifi. Changing to sddm however led to failure 
to reach a login screen. Installing lightdm let me select Plasma 5 
however. This is all with the Nouveau drivers.


However the wifi issue needed to be resolved. It turns out there are 
working (non-free) drivers available but they require a more recent 
kernel. I added bullseye-backports and installed the newer kernel and 
firmware-misc-non-free. This led to a failure to reach a login screen 
(in fact, the boot appears to hang after producing about 4 lines of 
output but booting to recovery mode let me see that it failed loading 
the Nouveau drivers).


Installing the nvidia-driver allowed the system to reach a graphical 
login but the system was not very stable. The difference in kernel 
versions was giving me a lot of errors so I tried to upgrade completely 
to Bookworm. That got me back to the point I was at when I first posted 
my original problem. I couldn't get to a working graphical login.


This led me back to the Debian site to download the latest Bookworm 
installer. The RC3 netinst is problematic - it didn't recognize my /home 
partition as formatted and ended up wiping it out. And when I rebooted 
into the installed system, it left me at a grub prompt. But when I 
rebooted and selected the boot partition manually through the BIOS, I 
was able to boot into the system. I ran update-grub and it's now booting 
properly.


Surprisingly, I was even able to switch to sddm and get into Plasma 5 
(Wayland!), all while using the Nouveau drivers. And wifi just worked!

Re: laptop stopped getting to desktop after latest updates

2023-05-22 Thread Gary Dale





Share with the Debian community
the X server logs  of "Debian" and "systemrescuecd".


Groeten
Geert Stappers


First is the log from a session that failed. Below is a log from a 
previous session that worked. Sorry, didn't get one from a 
systemrescuecd session - I thought I'd copied it to a network share but 
now I can't find it...



[    15.585]
X.Org X Server 1.21.1.7
X Protocol Version 11, Revision 0
[    15.585] Current Operating System: Linux Aspect23 6.1.0-9-amd64 #1 
SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08) x86_64
[    15.585] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-9-amd64 
root=UUID=9562e6ee-0942-46a6-abdd-2e3a1a3a80bb ro quiet

[    15.585] xorg-server 2:21.1.7-3 (https://www.debian.org/support)
[    15.585] Current version of pixman: 0.42.2
[    15.585]     Before reporting problems, check http://wiki.x.org
    to make sure that you have the latest version.
[    15.585] Markers: (--) probed, (**) from config file, (==) default 
setting,

    (++) from command line, (!!) notice, (II) informational,
    (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[    15.585] (==) Log file: "/var/log/Xorg.0.log", Time: Mon May 22 
12:43:47 2023

[    15.585] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[    15.585] (==) No Layout section.  Using the first Screen section.
[    15.585] (==) No screen section available. Using defaults.
[    15.585] (**) |-->Screen "Default Screen Section" (0)
[    15.585] (**) |   |-->Monitor ""
[    15.585] (==) No monitor specified for screen "Default Screen Section".
    Using a default monitor configuration.
[    15.585] (==) Automatically adding devices
[    15.585] (==) Automatically enabling devices
[    15.585] (==) Automatically adding GPU devices
[    15.585] (==) Automatically binding GPU devices
[    15.585] (==) Max clients allowed: 256, resource mask: 0x1f
[    15.585] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not 
exist.

[    15.585]     Entry deleted from font path.
[    15.585] (==) FontPath set to:
    /usr/share/fonts/X11/misc,
    /usr/share/fonts/X11/100dpi/:unscaled,
    /usr/share/fonts/X11/75dpi/:unscaled,
    /usr/share/fonts/X11/Type1,
    /usr/share/fonts/X11/100dpi,
    /usr/share/fonts/X11/75dpi,
    built-ins
[    15.585] (==) ModulePath set to "/usr/lib/xorg/modules"
[    15.585] (II) The server relies on udev to provide the list of input 
devices.
    If no devices become available, reconfigure udev or disable 
AutoAddDevices.

[    15.585] (II) Loader magic: 0x55b923332f00
[    15.585] (II) Module ABI versions:
[    15.585]     X.Org ANSI C Emulation: 0.4
[    15.585]     X.Org Video Driver: 25.2
[    15.585]     X.Org XInput driver : 24.4
[    15.585]     X.Org Server Extension : 10.0
[    15.586] (++) using VT number 7

[    15.586] (II) systemd-logind: logind integration requires -keeptty 
and -keeptty was not provided, disabling logind integration

[    15.586] (II) xfree86: Adding drm device (/dev/dri/card0)
[    15.586] (II) Platform probe for 
/sys/devices/pci:00/:00:01.1/:01:00.0/drm/card0
[    15.589] (--) PCI: (1@0:0:0) 10de:25a2:1043:16ad rev 161, Mem @ 
0xfb00/16777216, 0xfe/4294967296, 0xff/33554432, I/O 
@ 0xf000/128, BIOS @ 0x/524288
[    15.589] (--) PCI:*(6@0:0:0) 1002:1636:1043:16ad rev 198, Mem @ 
0xff1000/268435456, 0xff2000/2097152, 0xfc50/524288, I/O @ 
0xd000/256

[    15.589] (II) LoadModule: "glx"
[    15.589] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[    15.590] (II) Module glx: vendor="X.Org Foundation"
[    15.590]     compiled for 1.21.1.7, module version = 1.0.0
[    15.590]     ABI class: X.Org Server Extension, version 10.0
[    15.590] (II) Applying OutputClass "nvidia" to /dev/dri/card0
[    15.590]     loading driver: nvidia
[    15.712] (==) Matched nvidia as autoconfigured driver 0
[    15.712] (==) Matched nouveau as autoconfigured driver 1
[    15.712] (==) Matched nv as autoconfigured driver 2
[    15.712] (==) Matched ati as autoconfigured driver 3
[    15.712] (==) Matched modesetting as autoconfigured driver 4
[    15.712] (==) Matched fbdev as autoconfigured driver 5
[    15.712] (==) Matched vesa as autoconfigured driver 6
[    15.712] (==) Assigned the driver to the xf86ConfigLayout
[    15.712] (II) LoadModule: "nvidia"
[    15.712] (II) Loading /usr/lib/xorg/modules/drivers/nvidia_drv.so
[    15.713] (II) Module nvidia: vendor="NVIDIA Corporation"
[    15.713]     compiled for 1.6.99.901, module version = 1.0.0
[    15.713]     Module class: X.Org Video Driver
[    15.713] (II) LoadModule: "nouveau"
[    15.713] (II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so
[    15.713] (II) Module nouveau: vendor="X.Org Foundation"
[    15.713]     compiled for 1.21.1.3, module version = 1.0.17
[    15.713]     Module class: X.Org Video Driver
[    15.713]     ABI class: X.Org Video Driver, version 25.2
[    15.713] (II) LoadModule: "nv"
[    15.713]

Re: laptop stopped getting to desktop after latest updates

2023-05-21 Thread Gary Dale


On 2023-05-19 23:32, Gary Dale wrote:
I'm running Debian/Bookworm on an ASUS FA506IC laptop. It's got an AMD 
Ryzen processor but an NVidia graphics card that provides me with 
great evidence for why I had previously avoided NVidia cards. I'm 
running Bookworm because I couldn't get it work on Bullseye.


It'd been running OK with the proprietary drivers (but not the 
Nouveau) until earlier today. I don't use it very often so it was 
probably a few weeks since I last updated it. I had trouble the 
previous time I'd updated it too, but that was the move to the 
non-free-firmware section that messed it up. Once I added the new 
section to the sources, things worked again.


The symptoms I'm getting are the same as what it used to display when 
I tried to use sddm to start the desktop. Gdm3 and lightdm both worked 
in the past but now I'm getting the same symptom with all of them - a 
blank screen with a cursor flashing in the top-left corner. At that 
point I can't even bring up a text console, but I can reboot 
(ctrl-alt-del still works).


I can boot to a recovery mode and start the network, but not sure how 
to track this down. Removing and reinstalling the NVidia driver didn't 
help. Trying to start the desktop without the NVidia driver (and 
firmware) installed also didn't work. I still get the system booting 
to a blank screen with a flashing cursor in the top let corner.


Any ideas?

Thanks.

Further to above, I purged the nVidia drivers then noticed that there 
was still some nVidia stuff left (e.g. nvidia-persistence) so I did a 
further purge. When I rebooted, the system stalled initially after a 
couple of ACPI errors (there were only those lines on the screen - it 
was barely starting) but a ctrl-alt-del later and it got all the way to 
starting the nouveau drivers before stalling.


I reinstalled the nVidia drivers and was back to the same problem. 
Rebooting to recovery mode and checking the journal for the previous 
boot, there were a string of errors relating to lightdm failing to 
start, followed by retry and the same error.


I purged lightdm, rebooted and re-installed it but got the same errors.

I don't believe this is a problem with lightdm because it is also 
happening with gdm3 and sddm. The only difference is that its been 
happening with sddm since I got the laptop last November whereas the 
problem with lightdm and gdm3 is much more recent.


I can run the system with the Nouveau drivers when booting from 
systemrescuecd (a couple of recent versions, including 10.0), so this is 
a Debian issue.

laptop stopped getting to desktop after latest updates

2023-05-19 Thread Gary Dale

I'm running Debian/Bookworm on an ASUS FA506IC laptop. It's got an AMD 
Ryzen processor but an NVidia graphics card that provides me with great 
evidence for why I had previously avoided NVidia cards. I'm running 
Bookworm because I couldn't get it work on Bullseye.


It'd been running OK with the proprietary drivers (but not the Nouveau) 
until earlier today. I don't use it very often so it was probably a few 
weeks since I last updated it. I had trouble the previous time I'd 
updated it too, but that was the move to the non-free-firmware section 
that messed it up. Once I added the new section to the sources, things 
worked again.


The symptoms I'm getting are the same as what it used to display when I 
tried to use sddm to start the desktop. Gdm3 and lightdm both worked in 
the past but now I'm getting the same symptom with all of them - a blank 
screen with a cursor flashing in the top-left corner. At that point I 
can't even bring up a text console, but I can reboot (ctrl-alt-del still 
works).


I can boot to a recovery mode and start the network, but not sure how to 
track this down. Removing and reinstalling the NVidia driver didn't 
help. Trying to start the desktop without the NVidia driver (and 
firmware) installed also didn't work. I still get the system booting to 
a blank screen with a flashing cursor in the top let corner.


Any ideas?

Thanks.

Re: WiFi firmware issue in Bookworm


On 2023-02-09 22:09, The Wanderer wrote:

On 2023-02-09 at 21:39, Gary Dale wrote:


I'm trying to use a Linksys AE1200 wifi usb dongle as a second network
connection for my Bookworm workstation. The device shows up in lsusb but
not in ip link.

According to what I've found, it needs the brcmfmac driver module, which
seems to be in the 6.1 kernel and loaded:

$ lsmod | grep brcmfmac
brcmfmac  360448  0
brcmutil   20480  1 brcmfmac
cfg80211 1122304  1 brcmfmac
mmc_core  208896  1 brcmfmac
usbcore   344064  10
xhci_hcd,snd_usb_audio,usbhid,snd_usbmidi_lib,usblp,usb_storage,uvcvideo,brcmfmac,xhci_pci,uas

I'm using KDE/Plasma as my desktop and plasma-nm is loaded. However it
too doesn't seem to think that there is a wifi network.

Interestingly the device works in Bullseye as I installed Bullseye on
the computer that used to use it. That really only required downloading
the correct firmware package that contained the brcmfmac module. That
package no longer exists in Bookworm.

Would that be firmware-brcm80211?

That still exists in bookworm; it's just been moved to the new
non-free-firmware component, so it won't be showing up if your
sources.list doesn't reference that component (in addition to e.g. main,
contrib, and/or non-free).

There was another thread on this mailing list just within the past day
that asked a similar question regarding another firmware package, and
the replies to that question include links to the announcements about
the new component.


Thanks. That points then to a problem with the package.debian.org page - 
it doesn't seem to search the new section. I found the announcement when 
I searched for debian non-free firmware. Right now if you don't know it 
exists, you can't find it.  :(

Re: WiFi firmware issue in Bookworm


On 2023-02-09 22:07, piorunz wrote:

On 10/02/2023 02:39, Gary Dale wrote:
Interestingly the device works in Bullseye as I installed Bullseye on 
the computer that used to use it. That really only required 
downloading the correct firmware package that contained the brcmfmac 
module. That package no longer exists in Bookworm.


All you need to do, is to search for package, it may have different 
name under Bookworm. dmesg give you file name you want:


[  176.573530] usb 1-3.1: firmware: failed to load 
brcm/brcmfmac43236b.bin (-2)


apt-file search brcmfmac43236b.bin
firmware-brcm80211: /lib/firmware/brcm/brcmfmac43236b.bin

Install package firmware-brcm80211.


As I identified, that package doesn't exist in Bookworm:

# apt install firmware-brcm80211
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package firmware-brcm80211

WiFi firmware issue in Bookworm

I'm trying to use a Linksys AE1200 wifi usb dongle as a second network 
connection for my Bookworm workstation. The device shows up in lsusb but 
not in ip link.


According to what I've found, it needs the brcmfmac driver module, which 
seems to be in the 6.1 kernel and loaded:


$ lsmod | grep brcmfmac
brcmfmac  360448  0
brcmutil   20480  1 brcmfmac
cfg80211 1122304  1 brcmfmac
mmc_core  208896  1 brcmfmac
usbcore   344064  10 
xhci_hcd,snd_usb_audio,usbhid,snd_usbmidi_lib,usblp,usb_storage,uvcvideo,brcmfmac,xhci_pci,uas


I'm using KDE/Plasma as my desktop and plasma-nm is loaded. However it 
too doesn't seem to think that there is a wifi network.


Interestingly the device works in Bullseye as I installed Bullseye on 
the computer that used to use it. That really only required downloading 
the correct firmware package that contained the brcmfmac module. That 
package no longer exists in Bookworm.


Dmesg reveals the problem:

[  176.393749] usb 1-3.1: new high-speed USB device number 6 using xhci_hcd
[  176.546464] usb 1-3.1: New USB device found, idVendor=13b1, 
idProduct=0039, bcdDevice= 0.01
[  176.546467] usb 1-3.1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3

[  176.546469] usb 1-3.1: Product: Linksys AE1200
[  176.546470] usb 1-3.1: Manufacturer: Cisco
[  176.546470] usb 1-3.1: SerialNumber: 0001
[  176.573466] brcmfmac: brcmf_fw_alloc_request: using 
brcm/brcmfmac43236b for chip BCM43235/3
[  176.573530] usb 1-3.1: firmware: failed to load 
brcm/brcmfmac43236b.bin (-2)
[  176.573535] usb 1-3.1: firmware: failed to load 
brcm/brcmfmac43236b.bin (-2)
[  176.573537] usb 1-3.1: Direct firmware load for 
brcm/brcmfmac43236b.bin failed with error -2

[  458.854083] usb 1-3.1: USB disconnect, device number 6
[  464.232185] usb 1-3.1: new high-speed USB device number 7 using xhci_hcd
[  464.392635] usb 1-3.1: New USB device found, idVendor=13b1, 
idProduct=0039, bcdDevice= 0.01
[  464.392642] usb 1-3.1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3

[  464.392644] usb 1-3.1: Product: Linksys AE1200
[  464.392645] usb 1-3.1: Manufacturer: Cisco
[  464.392646] usb 1-3.1: SerialNumber: 0001
[  464.422271] brcmfmac: brcmf_fw_alloc_request: using 
brcm/brcmfmac43236b for chip BCM43235/3
[  464.422449] usb 1-3.1: firmware: failed to load 
brcm/brcmfmac43236b.bin (-2)
[  464.422462] usb 1-3.1: firmware: failed to load 
brcm/brcmfmac43236b.bin (-2)
[  464.422465] usb 1-3.1: Direct firmware load for 
brcm/brcmfmac43236b.bin failed with error -2


Apparently the firmware isn't loading.

Any ideas on how to fix this?

Re: support for ASUS AC1200 USB-AC53 Nano wifi dongle

On 2023-02-08 10:55, Gary Dale wrote:

On 2023-02-08 09:07, Gary Dale wrote:

On 2023-02-08 00:55, Alexander V. Makartsev wrote:

On 08.02.2023 09:07, Gary Dale wrote:

I thought this would be easier than it's turned out to be. There
are Internet posts going back years about support for this device
but nothing recent - including a 5 year old Ubuntu post saying it
works. Other wifi devices seem to be recognized out of the box or
with a simple install of non-free firmware but not this one - at
least not in Bullseye or Bookworm.

The adapter itself seems to be quite popular so I'm hoping someone
can provide some clues on how to make it work

Thanks.

Your device should be based on "RTL8822B" chip from Realtek, so you
need to install "firmware-realtek" package.
If after doing that you still didn't get a functioning network wifi
adapter you might need to build driver kernel module. [1]
This is what I had to do to get USB Bluetooth adapter from Asus to
work without issues, even though it is supported by kernel in
"bullseye".

It is always the best to include extra information about your setup
when you asking for help.

At least output from these commands would be a start:
$ uname -a
$ lsusb -v -t
# journalctl -b 0 --no-pager | grep -iE "rtl|rtk_|firmware"

If the output is long you can use "paste" service [2] and send us a
link.

[1]
https://www.asus.com/ca-en/networking-iot-servers/adapters/all-series/usb-ac53-nano/helpdesk_download/?model2Name=USB-AC53-Nano

[2] https://paste.debian.net/
--
Thanks Alexander, but installing firmware-realtek doesn't work. It
was the first thing I tried. Secondly, the ASUS driver fails to
compile under Bullseye & later. It throws an error:

1.5_33902.20190604_COEX20180928-6a6a/include/rtw_security.h:255:8:
error: redefinition of ‘struct sha256_state’

255 | struct sha256_state {
| ^~~~

This is the same error I find in various drivers from GitHub. They
all seem to be for older kernels and no longer compile. The fact that
drivers have existed for so long was one reason I thought the device
should be reasonably supported by now.

I had considered posting the output of lsusb but it simply shows that
the device is recognized. Making it verbose returns a lot of
capabilities information but not much else. Here it is:

/: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
ID 1d6b:0003 Linux Foundation 3.0 root hub
/: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
ID 1d6b:0002 Linux Foundation 2.0 root hub
|__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=, 480M
ID 0b05:184c ASUSTek Computer, Inc.
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 1M
ID 1d6b:0003 Linux Foundation 3.0 root hub
|__ Port 2: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
ID 0080:a001 Unknown JMS578 based SATA bridge
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
ID 1d6b:0002 Linux Foundation 2.0 root hub
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/8p, 1M
ID 1d6b:0003 Linux Foundation 3.0 root hub
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M
ID 1d6b:0002 Linux Foundation 2.0 root hub
|__ Port 13: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage,
480M

ID 058f:6366 Alcor Micro Corp. Multi Flash Reader

The journalctl command returns nothing.

Found a github repository that compiles on Bullseye at
https://github.com/morrownr/88x2bu. Then it's a matter of doing the
following as root

git clone https://github.com/morrownr/88x2bu-20210702## date string
may different

cd 88x2bu-20210702
make clean
make
make install

then rebooting. The wifi dongle now shows in "ip addr".

Had the wrong git command - now corrected above.

Ended up having another issue after I got it installed (on a friend's
machine that had been running Windows 7 badly but is now running
Bullseye nicely). Their residence doesn't use a WiFi password, so I
thought the device should just connect. Turns out there was a device
fingerprinting system in place that worked with an annual voucher number
you had to enter to connect to the Internet. Once I got the number,
things worked perfectly.

Re: support for ASUS AC1200 USB-AC53 Nano wifi dongle


On 2023-02-09 03:30, Anssi Saari wrote:

Gary Dale  writes:


I thought this would be easier than it's turned out to be. There are Internet 
posts going back years about support for this device but nothing recent -
including a 5 year old Ubuntu post saying it works. Other wifi devices seem to 
be recognized out of the box or with a simple install of non-free firmware but
not this one - at least not in Bullseye or Bookworm.

Hm. What I found was the driver has been integrated in kernel 6.2 and if
you need to build it for an older kernel, then they're supported too.
Versions 5.12-6.2 have community support and 4.19-5.11 are supported by
Realtek. I don't know what that means exactly though.

Source: https://github.com/morrownr/88x2bu-20210702

I can try to build this with Debian's stable 5.10 kernel at some point
but I don't have the hardware.

Thanks. Found that github repo myself. I hope you are right about 6.2 
integration, but I'm not sure we'll get there with Bookworm...

Re: support for ASUS AC1200 USB-AC53 Nano wifi dongle

2023-02-08 Thread Gary Dale

On 2023-02-08 09:07, Gary Dale wrote:

On 2023-02-08 00:55, Alexander V. Makartsev wrote:

On 08.02.2023 09:07, Gary Dale wrote:

I thought this would be easier than it's turned out to be. There are
Internet posts going back years about support for this device but
nothing recent - including a 5 year old Ubuntu post saying it works.
Other wifi devices seem to be recognized out of the box or with a
simple install of non-free firmware but not this one - at least not
in Bullseye or Bookworm.

The adapter itself seems to be quite popular so I'm hoping someone
can provide some clues on how to make it work

Thanks.

It is always the best to include extra information about your setup
when you asking for help.

At least output from these commands would be a start:
$ uname -a
$ lsusb -v -t
# journalctl -b 0 --no-pager | grep -iE "rtl|rtk_|firmware"

If the output is long you can use "paste" service [2] and send us a link.

[1]
https://www.asus.com/ca-en/networking-iot-servers/adapters/all-series/usb-ac53-nano/helpdesk_download/?model2Name=USB-AC53-Nano

[2] https://paste.debian.net/
--
Thanks Alexander, but installing firmware-realtek doesn't work. It was
the first thing I tried. Secondly, the ASUS driver fails to compile
under Bullseye & later. It throws an error:

1.5_33902.20190604_COEX20180928-6a6a/include/rtw_security.h:255:8:
error: redefinition of ‘struct sha256_state’

255 | struct sha256_state {
| ^~~~

This is the same error I find in various drivers from GitHub. They all
seem to be for older kernels and no longer compile. The fact that
drivers have existed for so long was one reason I thought the device
should be reasonably supported by now.

I had considered posting the output of lsusb but it simply shows that
the device is recognized. Making it verbose returns a lot of
capabilities information but not much else. Here it is:

The journalctl command returns nothing.

Found a github repository that compiles on Bullseye at
https://github.com/morrownr/88x2bu. Then it's a matter of doing the
following as root

git clone https://github.com/morrownr/88x2bu
cd 88x2bu-20210702 ## date string may different
make clean
make
make install

then rebooting. The wifi dongle now shows in "ip addr".

Re: support for ASUS AC1200 USB-AC53 Nano wifi dongle

2023-02-08 Thread Gary Dale

On 2023-02-08 00:55, Alexander V. Makartsev wrote:

On 08.02.2023 09:07, Gary Dale wrote:

I thought this would be easier than it's turned out to be. There are
Internet posts going back years about support for this device but
nothing recent - including a 5 year old Ubuntu post saying it works.
Other wifi devices seem to be recognized out of the box or with a
simple install of non-free firmware but not this one - at least not
in Bullseye or Bookworm.

The adapter itself seems to be quite popular so I'm hoping someone
can provide some clues on how to make it work

Thanks.

It is always the best to include extra information about your setup
when you asking for help.

At least output from these commands would be a start:
$ uname -a
$ lsusb -v -t
# journalctl -b 0 --no-pager | grep -iE "rtl|rtk_|firmware"

If the output is long you can use "paste" service [2] and send us a link.

[1]
https://www.asus.com/ca-en/networking-iot-servers/adapters/all-series/usb-ac53-nano/helpdesk_download/?model2Name=USB-AC53-Nano

[2] https://paste.debian.net/
--
Thanks Alexander, but installing firmware-realtek doesn't work. It was
the first thing I tried. Secondly, the ASUS driver fails to compile
under Bullseye & later. It throws an error:

1.5_33902.20190604_COEX20180928-6a6a/include/rtw_security.h:255:8:
error: redefinition of ‘struct sha256_state’

255 | struct sha256_state {
| ^~~~

This is the same error I find in various drivers from GitHub. They all
seem to be for older kernels and no longer compile. The fact that
drivers have existed for so long was one reason I thought the device
should be reasonably supported by now.

I had considered posting the output of lsusb but it simply shows that
the device is recognized. Making it verbose returns a lot of
capabilities information but not much else. Here it is:

The journalctl command returns nothing.

support for ASUS AC1200 USB-AC53 Nano wifi dongle

2023-02-07 Thread Gary Dale

I thought this would be easier than it's turned out to be. There are 
Internet posts going back years about support for this device but 
nothing recent - including a 5 year old Ubuntu post saying it works. 
Other wifi devices seem to be recognized out of the box or with a simple 
install of non-free firmware but not this one - at least not in Bullseye 
or Bookworm.


The adapter itself seems to be quite popular so I'm hoping someone can 
provide some clues on how to make it work


Thanks.

Re: Installation of Salome 9.9.0

Sorry that I didn't catch that one. I just ripped the whole thing out 
and am going to go to Code_Aster and try to install Salome-Meca. This is 
probably what I should have done in the first place. Sorry if wasted 
your time. Thanks for the help.


Gary R.

On 1/14/23 16:46, Greg Wooledge wrote:

On Sat, Jan 14, 2023 at 03:54:22PM -0800, Gary L. Roach wrote:

PS I had tried ./salome and got the following error:

ERROR:salomeContext:Unexpected error:
Traceback (most recent call last):
  File
"/home/gary/Salome/SALOME-9.9.0-native-DB10-SRC/BINARIES-DB10/SALOME/bin/
salome/salomeContext.py", line 281, in _startSalome
    res = getattr(self, command)(options) # run appropriate method

That looks wrong.  In your prior message you said you're on Debian 11.

On the download page <https://www.salome-platform.org/?page_id=15> there
are links for Debian 11, Debian 10 and Debian 9.  The Debian 11 link
has "DB11" in it; the Debian 10 link has "DB10" and the Debian 9 link
has "DB09".

Are you sure you downloaded the correct one for your version of Debian?

Again, this is the part where telling us the URL you downloaded, and
showing us the downloaded file with ls -l, would be useful.

Re: Installation of Salome 9.9.0


PS I had tried ./salome and got the following error:

ERROR:salomeContext:Unexpected error:
Traceback (most recent call last):
 File 
"/home/gary/Salome/SALOME-9.9.0-native-DB10-SRC/BINARIES-DB10/SALOME/bin/

salome/salomeContext.py", line 281, in _startSalome
   res = getattr(self, command)(options) # run appropriate method
 File 
"/home/gary/Salome/SALOME-9.9.0-native-DB10-SRC/BINARIES-DB10/SALOME/bin/

salome/salomeContext.py", line 368, in _sessionless
   import setenv
 File 
"/home/gary/Salome/SALOME-9.9.0-native-DB10-SRC/BINARIES-DB10/KERNEL/bin/

salome/setenv.py", line 26, in 
   import orbmodule
 File 
"/home/gary/Salome/SALOME-9.9.0-native-DB10-SRC/BINARIES-DB10/KERNEL/bin/

salome/orbmodule.py", line 31, in 
   from omniORB import CORBA
 File 
"/home/gary/Salome/SALOME-9.9.0-native-DB10-SRC/BINARIES-DB10/omniORB/lib

/python3.7/site-packages/omniORB/__init__.py", line 44, in 
   import _omnipy
ModuleNotFoundError: No module named '_omnipy'

I guess I need to chase down the origin of the _omnipy module.

Gary R

On 1/14/23 14:04, Greg Wooledge wrote:

On Sat, Jan 14, 2023 at 09:12:06PM +,debian-u...@howorth.org.uk  wrote:

There is:

https://docs.salome-platform.org/latest/dev/cmake/html/index.html

Which I suppose is what Gary was referring to?

Hmm... maybe.  Of course that's on a separate hostname.

With a bit more digging, I also found, from the main page of the
Salome project:

Resources -> FAQ ->https://www.salome-platform.org/?page_id=428

This has the following instructions:


4. How to install SALOME on linux ?
First, download SALOME for your specific operating system version. If
your OS is not supported, you can use the “universal version”.

Extract the archive.

Then, check that the dependancies are installed on your OS:

./sat config SALOME-9.8.0 --check_system
Check that your graphic card is well configured for 3D rendering.

Then launch SALOME with:

./salome
More information is  available in the README file.


You may need Javascript enabled to read these instructions.  The whole
web page is stupidly fancy, with moving crap everywhere, instead of just
presenting information sanely.

Do note that the current release is apparently 9.9.0 rather than 9.8.0,
so I imagine that ./sat command might need a small adjustment.

Re: Installation of Salome 9.9.0

The lack of information is because I never got off the ground with this. 
I did finally figured out how to get ./sat to work and completely 
cleaned up all of the missing pieces. But then I am a loss of what to do 
next. My top Salome directory looks like this:


drwxr-xr-x  2 gary gary    4096 Jan 11 12:41 ARCHIVES
drwxr-xr-x 73 gary gary    4096 Jan 11 12:41 BINARIES-DB10
-rwxr-xr-x  1 gary gary   55590 May 31  2022 binsalome
-rwxr-xr-x  1 gary gary   44642 May 31  2022 env_launch.sh
drwxr-xr-x 73 gary gary    4096 Jan 11 16:31 INSTALL
-rwxr-xr-x  1 gary gary 866 May 31  2022 install_bin.sh
drwxrwxrwx  3 root root    4096 Jan 14 15:07 LOGS
-rw-r--r--  1 gary gary 2765865 May 31  2022 logs.tgz
-rwxr-xr-x  1 gary gary   56232 May 31  2022 mesa_salome
drwxr-xr-x  4 gary gary    4096 May 31  2022 PROJECT
-rw-r--r--  1 gary gary    5242 May 31  2022 README
-rwxr-xr-x  1 gary gary   55587 May 31  2022 salome
-rw-r--r--  1 gary gary  711820 May 30  2022 SALOME_9_9_0_Release_Notes.pdf
drwxr-xr-x  9 gary gary    4096 May 31  2022 sat
drwxr-xr-x  3 gary gary    4096 Jan 11 12:40 SOURCES

I have no idea what to do with this. I'm using a standard debian 11 
installation with KDE desk top if that helps.


Gary R.


On 1/14/23 13:12, debian-u...@howorth.org.uk wrote:

On Sat, Jan 14, 2023 at 12:20:21PM -0800, Gary L. Roach wrote:

Hi all,

I have been trying to install Salome 9.90 from the tar.gz file.
When I unzip the file the contents look nothing like the
installation instructions that I have found on line. Does anyone
have experience with the Debian installation of this package. If
so, please help

Gary, it would be helpful if you gave references for all your
statements, rather than have Greg and me and whoever else guessing what
you may have or have not done. Especially more detail about what
problems you've found.


I assume you mean the thing found at
<https://www.salome-platform.org/?p=2176>.

Good luck with this.  I can't find installation instructions anywhere
on this web site.  There's a 30-page PDF of "release notes", but guess
what's not in it.  That's right -- no installation instructions in it.

There are, however, 4 pages of prerequisites that this thing
apparently needs.

Sounds like a real party.

There is:

https://docs.salome-platform.org/latest/dev/cmake/html/index.html

Which I suppose is what Gary was referring to?

Seems like a potentially useful project. I'll be interested to see how
it goes.

Installation of Salome 9.9.0