60-serial.rules, broken

[gene heskett]

Greetings all;

/dev/serial/by-id has not been created for quite some time. The arm
folks have had a patch script for quite a while but it has not been
fixed in debian that we know of. I have 4 identical banana pi's, 3 of
which seem to work, but the patch has not fixed the 4th on for some unk
reason.

When a serial device is plugged into a usb point, /dev/ttyACM# is
created on all 4 machines, but /dev/serial/by-id entries are not. Some
of the 3d printer stuff uses that by-id thing to separate printers
plugged into the same host, and the lack of a /dev/serial entry kills
the 3d printer drivers.

Can anyone give us a hint as to when this will be addressed?

Thanks.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

[Darac Marjal]

On 07/06/2023 15:37, gene heskett wrote:
> Greetings all;
>
> /dev/serial/by-id has not been created for quite some time. The arm
> folks have had a patch script for quite a while but it has not been
> fixed in debian that we know of. I have 4 identical banana pi's, 3 of
> which seem to work, but the patch has not fixed the 4th on for some
> unk reason.
>
> When a serial device is plugged into a usb point, /dev/ttyACM# is
> created on all 4 machines, but /dev/serial/by-id entries are not. Some
> of the 3d printer stuff uses that by-id thing to separate printers
> plugged into the same host, and the lack of a /dev/serial entry kills
> the 3d printer drivers.
>
> Can anyone give us a hint as to when this will be addressed?

Hi Gene,

The subject suggest that it's "60-serial.rules" which is broken. This
would be a udev rules file.

If you know the contents of the patch, couldn't you just create your own
rules file which implements this patch? Is there any particular reason
why you need to wait for Debian to make the change?

>
> Thanks.
>
> Cheers, Gene Heskett.

[Sascha Silbe]

Hello Gene,

gene heskett <ghes...@shentel.net> writes:

> Greetings all;
>

> /dev/serial/by-id has not been created for quite some time. [...]

That's Debian#1035094 [1]. A fix was uploaded three weeks ago and is
available in bullseye-proposed-updates [2] but not the regular Bullseye
repository. If I understand the status page [3] correctly it's only
scheduled for the next point release. Given that there already was a
point release recently (11.7 on 2023-05-01) it will probably another
couple of months until this bug gets fixed in bullseye. :-/

Might be worth it to add proposed-updates to the APT sources and use APT
pinning to update only systemd.

Not sure if it's fixed in Bookworm already. The upstream fix went in at
v253. Bookworm is at 252.6 which doesn't exist as a tag in the upstream
repo so I cannot check if the fix was backported.

Sascha

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035094
[2] http://ftp.us.debian.org/debian/dists/bullseye-proposed-updates/
[3] https://release.debian.org/proposed-updates/stable.html

[gene heskett]

biggest reason is to prevent its (60-serial.rules) being overwritten by
an update if apt discovers we've overwritten its broken defaults, or if
replaced, is replaced by an even better version. This bug has caused
all users of 3d printers that have replaced the marlin gcode interpreter
in their printers with the faster, more capable klipper, which I'd
estimate is about 50% of the serious 3d printer users. I have 4,
supposedly identical banana pi's, 3 of which this patch fixes, but the
4th one must have something blown, it does create /dev/ttyACM0 but does
not create the matching /dev/serial/by-id device when a printer is
plugged in.

All 4 are uptodate as of yesterday as armbian bullseye uses your arm64
repo's. That and I have little understanding of how udev works, so I'll
let the real udev coders handle that. I am 1 user with several machines,
an update to that file that fixes this bug, would fix everyone.

Take care & stay well Darac.

[gene heskett]

On 6/7/23 14:04, Darac Marjal wrote:
>

As an addemdum to my previous reply, I just check this machine running
bullseye, and I have /dev/serial/by-path with several devices, but no
/dev/serial/by-id directory exists, so fixing this bug will fix most of
the debian world.
>>
>> Thanks.
>>
>> Cheers, Gene Heskett.

[gene heskett]

On 6/7/23 14:37, Sascha Silbe wrote:
> Hello Gene,
>
> gene heskett <ghes...@shentel.net> writes:
>
>> Greetings all;
>>
>> /dev/serial/by-id has not been created for quite some time. [...]
>
> That's Debian#1035094 [1]. A fix was uploaded three weeks ago and is
> available in bullseye-proposed-updates [2] but not the regular Bullseye
> repository. If I understand the status page [3] correctly it's only
> scheduled for the next point release. Given that there already was a
> point release recently (11.7 on 2023-05-01) it will probably another
> couple of months until this bug gets fixed in bullseye. :-/
>
> Might be worth it to add proposed-updates to the APT sources and use APT
> pinning to update only systemd.
>
> Not sure if it's fixed in Bookworm already. The upstream fix went in at
> v253. Bookworm is at 252.6 which doesn't exist as a tag in the upstream
> repo so I cannot check if the fix was backported.
>
> Sascha
>

That is most unfortunate for 3d printer users, our support group on
discord is blowing up with the problems this is cause for klipper users,
can its priority be raised? We use it because that gives us a
bulletproof method using the devices ChipID, which is totally unique,
like MAC addresses.

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035094
> [2] http://ftp.us.debian.org/debian/dists/bullseye-proposed-updates/
> [3] https://release.debian.org/proposed-updates/stable.html

[gene heskett]

I couldn't figure how to dl the file, so I snapshoted the diff screen
from [1], and will compare it to what I have from the patch, which it
appears I have not done to this machine, as I have /dev/serial/by-path
only here, no by-id. This bug is a showstopper for users of 3d printers.

Take care & stay well Sascha.

[David Wright]

On Thu 08 Jun 2023 at 11:47:25 (-0400), gene heskett wrote:
> On 6/7/23 14:04, Darac Marjal wrote:
> > On 07/06/2023 15:37, gene heskett wrote:
> > >
> > > /dev/serial/by-id has not been created for quite some time.
> > > The arm folks have had a patch script for quite a while but it
> > > has not been fixed in debian that we know of. I have 4
> > > identical banana pi's, 3 of which seem to work, but the patch
> > > has not fixed the 4th on for some unk reason.
> > >
> > > When a serial device is plugged into a usb point, /dev/ttyACM#
> > > is created on all 4 machines, but /dev/serial/by-id entries
> > > are not. Some of the 3d printer stuff uses that by-id thing to
> > > separate printers plugged into the same host, and the lack of
> > > a /dev/serial entry kills the 3d printer drivers.
> > >
> > > Can anyone give us a hint as to when this will be addressed?
> >

> > The subject suggest that it's "60-serial.rules" which is broken.
> > This would be a udev rules file.
> >
> > If you know the contents of the patch, couldn't you just create
> > your own rules file which implements this patch? Is there any
> > particular reason why you need to wait for Debian to make the
> > change?
> >
> biggest reason is to prevent its (60-serial.rules) being overwritten
> by an update if apt discovers we've overwritten its broken defaults,
> or if replaced, is replaced by an even better version.

Of course it won't. The package provides /usr/lib/udev/rules.d/60-serial.rules
which you should leave strictly alone for APT to handle. You would
create /etc/udev/rules.d/60-serial.rules and APT will never touch that.
Files under /etc/ take priority over those under /usr/lib/ when their
filenames are the same. That's how both udev and systemd work.
See RULES FILES under man 7 udev.

Cheers,
David.

[gene heskett]

Perhaps I've ben mistaken, but the files in /etc/udev/rules.d are not
the same as /lib/udev/rules.d, so which one actually rules?
> Cheers,
> David.

[to...@tuxteam.de]

On Thu, Jun 08, 2023 at 09:08:59PM -0400, gene heskett wrote:

[...]

> Perhaps I've ben mistaken, but the files in /etc/udev/rules.d are not the
> same as /lib/udev/rules.d, so which one actually rules?

The one in /etc, as David said. Unless it doesn't exist.

This is actually the classical pattern of "layered configuration", which
is widespread in the UNIX world. You see that often with a system config
which can be overridden by a user config.

Sometimes you have even three layers: distro (e.g. lib), local (etc) and
user.

Cheers
--
t

[Michael Biebl]

> Not sure if it's fixed in Bookworm already. The upstream fix went in at
> v253. Bookworm is at 252.6 which doesn't exist as a tag in the upstream
> repo so I cannot check if the fix was backported.

stable/point releases can be found in the systemd-stable repository. See
https://github.com/systemd/systemd-stable/

[gene heskett]

Thanks for the clarification Tomas. That would intimate the search order
would be /home/$usr/someplace, /etc/someplace, /lib/someplace. Is that
correct?

Change of subject:

I have a mod I make to the $PATH which I've put in .profile, but I've
failed to find a place to make it autoexec when I login. And I'm tired
of typing ". .profile in every shell tab I open.

Suggestion?

Thanks Tomas. Take care & stay well.

[gene heskett]

4 questions:

1.This and 4 other machines here are on bullseye, 4 more are on buster
and they work ok.

2.these links seem to be in diff format.

3. can I dl these files in ready to run format? and

4. where on a 64 bit i5 debian 11 system do I put them as it appears I
might need 60-persisyent-storage too.

Thanks & Cheers, Gene Heskett.

[David Wright]

On Fri 09 Jun 2023 at 06:20:07 (-0400), gene heskett wrote:
> On 6/9/23 00:46, to...@tuxteam.de wrote:
> > On Thu, Jun 08, 2023 at 09:08:59PM -0400, gene heskett wrote:
> >
> > [...]
> >
> > > Perhaps I've ben mistaken, but the files in /etc/udev/rules.d are not the
> > > same as /lib/udev/rules.d, so which one actually rules?
> >
> > The one in /etc, as David said. Unless it doesn't exist.
> >
> > This is actually the classical pattern of "layered configuration", which
> > is widespread in the UNIX world. You see that often with a system config
> > which can be overridden by a user config.
> >
> > Sometimes you have even three layers: distro (e.g. lib), local (etc) and
> > user.
>

> Thanks for the clarification Tomas. That would intimate the search
> order would be /home/$usr/someplace, /etc/someplace, /lib/someplace.
> Is that correct?

Not only did I give the priority for the task you're tackling
(which BTW would not concern an individual user's directory tree),
I also gave you the reference: man udev.

What is your problem??

> Change of subject:
>
> I have a mod I make to the $PATH which I've put in .profile, but I've
> failed to find a place to make it autoexec when I login. And I'm tired
> of typing ". .profile in every shell tab I open.
>
> Suggestion?

Read INVOCATION in man 1 bash (and check the existence and priorities
of the several startup files). But I feel I'm wasting my breath.

PS New thread for a new subject? Come on …

Cheers,
David.

[to...@tuxteam.de]

On Fri, Jun 09, 2023 at 06:20:07AM -0400, gene heskett wrote:
> On 6/9/23 00:46, to...@tuxteam.de wrote:
> > On Thu, Jun 08, 2023 at 09:08:59PM -0400, gene heskett wrote:
> >
> > [...]
> >
> > > Perhaps I've ben mistaken, but the files in /etc/udev/rules.d are not the
> > > same as /lib/udev/rules.d, so which one actually rules?
> >
> > The one in /etc, as David said. Unless it doesn't exist.
> >
> > This is actually the classical pattern of "layered configuration", which
> > is widespread in the UNIX world. You see that often with a system config
> > which can be overridden by a user config.
> >
> > Sometimes you have even three layers: distro (e.g. lib), local (etc) and
> > user.
> >
> > Cheers
>
> Thanks for the clarification Tomas. That would intimate the search order
> would be /home/$usr/someplace, /etc/someplace, /lib/someplace. Is that
> correct?
>
> Change of subject:
>
> I have a mod I make to the $PATH which I've put in .profile, but I've failed
> to find a place to make it autoexec when I login. And I'm tired of typing ".
> .profile in every shell tab I open.

I quote in full from the bash man page, section "INVOCATION" (I assume your
shell is bash):

INVOCATION
A login shell is one whose first character of argument zero is a -, or
one started with the --login option.

An interactive shell is one started without non-option arguments (unless
-s is specified) and without the -c option whose standard input and error
are both connected to terminals (as determined by isatty(3)), or one
started with the -i option. PS1 is set and $- includes i if bash is in‐
teractive, allowing a shell script or a startup file to test this state.

The following paragraphs describe how bash executes its startup files.
If any of the files exist but cannot be read, bash reports an error.
Tildes are expanded in filenames as described below under Tilde Expansion
in the EXPANSION section.

When bash is invoked as an interactive login shell, or as a non-interac‐
tive shell with the --login option, it first reads and executes commands
from the file /etc/profile, if that file exists. After reading that
file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in
that order, and reads and executes commands from the first one that ex‐
ists and is readable. The --noprofile option may be used when the shell
is started to inhibit this behavior.


> Suggestion?

Perhaps you have a ~/.bash_profile, which then would take precedence over
your ~/.profile (people who want to have both usually source ~/.profile
from ~/.bash_profile. Writing shell-independent code is left as an exercise
to the reader, though). Perhaps your PATH is not exported. Perhaps your
.profile isn't in your HOME. Perhaps your shell ain't a login shell (it's
possibly started by the DE monstrosity du jour). I'd start debugging it
by putting some "echo hi >> /tmp/debug-shell-startup" or something, and
putting it also into ~/.bashrc.

> Thanks Tomas. Take care & stay well.

Likewise :)

Cheers
--
t

[Greg Wooledge]

I must have said this a hundred times, but... it depends on HOW you login.

The only times .profile is read are when you have a login shell (from a
pure text console login, or an ssh login, or something like "su - gene"),
or if some other file that IS read dots it in.

If your changes to .profile are not being seen at login time, that means
you aren't using one of the above -- OR, something is overwriting your
change later.

In your previous emails, you've mentioned a Trinity Desktop Environment.
If that's how you login (a graphical Display Manager brought in as part
of TDE), then it's no surprise that .profile is not being read.

See <https://wiki.debian.org/Xsession> assuming your TDE + Display Manager
setup still uses a Debian X session.

If your setup does NOT use a Debian X session, then I would revert to the
traditional configuration -- create a .xsession file, put your changes
in it (which may simply be dotting in .profile, or not, depending on
what's in .profile), and then make sure it executes the startup command
for TDE at the end. Which means you have to figure out what that startup
command IS.

The tricky parts of the traditional configuration are figuring out how
to invoke your WM or desktop environment, and figuring out whether you
can dot in .profile, or whether you have to duplicate parts of it. The
key is that .xsession is NOT executed in a terminal environment. So,
if it tries to write any messages to stdout, you won't see them. If
it tries to call stty or any other terminal-oriented program, it will
fail. In a lot of cases, you can simply ignore these failures, but
without knowing what's in your .profile (and all the files it dots in),
it's impossible to give specific advice.

Finally, remember that .xsession is run by /bin/sh, not by your login
shell. So, if you've got bash syntax in .profile (or anything it dots
in, such as .bashrc), then you cannot safely dot it in from .xsession.

[Greg Wooledge]

On Fri, Jun 09, 2023 at 06:20:07AM -0400, gene heskett wrote:

> On 6/9/23 00:46, to...@tuxteam.de wrote:
> > This is actually the classical pattern of "layered configuration", which
> > is widespread in the UNIX world. You see that often with a system config
> > which can be overridden by a user config.
> >
> > Sometimes you have even three layers: distro (e.g. lib), local (etc) and
> > user.
>

> Thanks for the clarification Tomas. That would intimate the search order
> would be /home/$usr/someplace, /etc/someplace, /lib/someplace. Is that
> correct?

Tomas is speaking in a general sense. There are many different programs
which use this TYPE of arrangement, or some subset of it.

The exact search order would depend on which specific program is being
analzed.

Also, sometimes it's not a case of "search through the following list
and use the first one you find". Sometimes the list is traversed in
the other direction, and ALL configuration files are read, starting
with the generic distribution file, and then the local sysadmin's file,
and then the user's file, with the intent that the later files can
override the configuration elements established by the earlier files.

Both ways are quite common.

[to...@tuxteam.de]

On Fri, Jun 09, 2023 at 07:36:42AM -0400, Greg Wooledge wrote:
> On Fri, Jun 09, 2023 at 06:20:07AM -0400, gene heskett wrote:
> > On 6/9/23 00:46, to...@tuxteam.de wrote:
> > > This is actually the classical pattern of "layered configuration", which
> > > is widespread in the UNIX world. You see that often with a system config
> > > which can be overridden by a user config.
> > >
> > > Sometimes you have even three layers: distro (e.g. lib), local (etc) and
> > > user.
> >
> > Thanks for the clarification Tomas. That would intimate the search order
> > would be /home/$usr/someplace, /etc/someplace, /lib/someplace. Is that
> > correct?
>
> Tomas is speaking in a general sense. There are many different programs
> which use this TYPE of arrangement, or some subset of it.
>
> The exact search order would depend on which specific program is being
> analzed.
>
> Also, sometimes it's not a case of "search through the following list
> and use the first one you find".

This would be the udev pattern: if there's something in /etc, use
that, otherwise use the one in /lib. I.e. the /etc one REPLACES
the /lib one.

> Sometimes the list is traversed in
> the other direction, and ALL configuration files are read, starting
> with the generic distribution file, and then the local sysadmin's file,
> and then the user's file, with the intent that the later files can
> override the configuration elements established by the earlier files.

This is typical for shell thingies: the $HOME ones AUGMENT/OVERRIDE
the /etc ones.

> Both ways are quite common.

Thanks for all the gory details :-)

Cheers
--
t

[gene heskett]

On 6/9/23 07:25, to...@tuxteam.de wrote:
[...]

> I quote in full from the bash man page, section "INVOCATION" (I assume your
> shell is bash):
>

bash it is, and I've even an older printout. I'll pursue this as I was
not aware of it. Thank you Tomas.

> INVOCATION
> A login shell is one whose first character of argument zero is a -, or
> one started with the --login option.

[...]

[songbird]

<to...@tuxteam.de> wrote:
...

> Perhaps you have a ~/.bash_profile, which then would take precedence over
> your ~/.profile (people who want to have both usually source ~/.profile
> from ~/.bash_profile. Writing shell-independent code is left as an exercise
> to the reader, though). Perhaps your PATH is not exported. Perhaps your
> .profile isn't in your HOME. Perhaps your shell ain't a login shell (it's
> possibly started by the DE monstrosity du jour). I'd start debugging it
> by putting some "echo hi >> /tmp/debug-shell-startup" or something, and
> putting it also into ~/.bashrc.

i use the MATE desktop but i think this would work for
Gnome too.

what i have set up for when i fire up the desktops is in
my .bashrc i check to see which directory i am in (which
is an indication of which project that terminal is working
on) and from there i test and set various environment
variables. it is all in my .bashrc file. when i save the
layout of the desktops and then restart the computer the
various terminals come up in the respective directories
i was in when i saved (or shutdown using the menu), if i
do not shutdown using the menu then the layouts are not
changed (which is perfect for my usage because not always
do i want to make changes to my desktop layouts). so the
difference is between using the menu shutdown and the
command line shutdown from root (which is how i shut down
99.99% of the time).

$ cwd=`pwd`
if [ "$HOME/rogo/project" == "${cwd}" -o \
"$HOME/src/github/project" == "${cwd}" -o \
"$HOME/src/github/similar_project" == "${cwd}" ] ; then

set stuff...
fi

etc.

i like that i don't have to remember which environment
variables to fiddle with and that i can just change the
context and content of a terminal starting up just by
changing to the right directory and then shutting down
using the menu - so if i need to change back to working
on an old project (as long as i've not removed the
things from my .bashrc) it is a simple adjustment.

this lets my brain cells get used for remembering
other things and scrolling through .bashrc can remind
me of other things i may want to change (some variables
i comment out different versions for debugging vs normal
production settings).


songbird

[songbird]

Greg Wooledge wrote:
...

> I must have said this a hundred times, but... it depends on HOW you login.

yes! login vs. non-login.

the rest left in because it is useful and notable.

songbird

[gene heskett]

> .
Apparently this last is true. I put it as next to last line in
/etc/X11/Xsession and killed everything I had running but did let me
exec a new xfce4 terminal, which did not get the fix so fixed it back to
original but still had to reboot. With my local network thats about 15
times typing my pw's :-\ add 2 more times for every one of the bpi's
actually running. Making an .xsession file also failed, didn't do anything.

Thanks Greg.

[Greg Wooledge]

On Fri, Jun 09, 2023 at 09:25:25AM -0400, gene heskett wrote:
> On 6/9/23 07:33, Greg Wooledge wrote:
> > Finally, remember that .xsession is run by /bin/sh, not by your login
> > shell. So, if you've got bash syntax in .profile (or anything it dots
> > in, such as .bashrc), then you cannot safely dot it in from .xsession.
> >
> > .
> Apparently this last is true. I put it as next to last line in
> /etc/X11/Xsession and killed everything I had running but did let me exec a
> new xfce4 terminal, which did not get the fix so fixed it back to original
> but still had to reboot.

I would NOT advise modifying the files in /etc/X11, especially if you
aren't 100% sure what you're doing. There are lot of subtle and delicate
moving parts in there.

Whatever you end up doing to get your PATH set properly at login should
happen only in your $HOME directory.

Start with .xsessionrc (the Debian hack) and see if that works. Put a
PATH modification in there, and also put something like

export GENETEST=hello

and see if that's present in a shell inside a newly spawned xterm.
If it is, then you know that .xsessionrc is being read during login,
even if the PATH modification is lost.

If GENETEST is present but the PATH modification is not, then you know
something's changing your PATH after .xsessionrc has been read. In that
case you need to track it down inside your desktop environment.

If neither one is present, then you're not using a Debian X session.

Whatever the results are, you'll have learned *something*.

[gene heskett]

On 6/9/23 09:33, Greg Wooledge wrote:
> On Fri, Jun 09, 2023 at 09:25:25AM -0400, gene heskett wrote:
>> On 6/9/23 07:33, Greg Wooledge wrote:
>>> Finally, remember that .xsession is run by /bin/sh, not by your login
>>> shell. So, if you've got bash syntax in .profile (or anything it dots
>>> in, such as .bashrc), then you cannot safely dot it in from .xsession.
>>>
>>> .
>> Apparently this last is true. I put it as next to last line in
>> /etc/X11/Xsession and killed everything I had running but did let me exec a
>> new xfce4 terminal, which did not get the fix so fixed it back to original
>> but still had to reboot.
>
> I would NOT advise modifying the files in /etc/X11, especially if you
> aren't 100% sure what you're doing. There are lot of subtle and delicate
> moving parts in there.
>
> Whatever you end up doing to get your PATH set properly at login should
> happen only in your $HOME directory.
>
> Start with .xsessionrc (the Debian hack) and see if that works. Put a
> PATH modification in there, and also put something like
>
> export GENETEST=hello
>

in a $HOME/.xsessionrc had no effect on a new xfce4 terminal.

> and see if that's present in a shell inside a newly spawned xterm.
> If it is, then you know that .xsessionrc is being read during login,
> even if the PATH modification is lost.
>
> If GENETEST is present but the PATH modification is not, then you know
> something's changing your PATH after .xsessionrc has been read. In that
> case you need to track it down inside your desktop environment.
>
> If neither one is present, then you're not using a Debian X session.
>
> Whatever the results are, you'll have learned *something*.
>

[gene heskett]

On 6/9/23 06:51, David Wright wrote:
> On Fri 09 Jun 2023 at 06:20:07 (-0400), gene heskett wrote:
>> On 6/9/23 00:46, to...@tuxteam.de wrote:
>>> On Thu, Jun 08, 2023 at 09:08:59PM -0400, gene heskett wrote:
>>>
>>> [...]
>>>
>>>> Perhaps I've ben mistaken, but the files in /etc/udev/rules.d are not the
>>>> same as /lib/udev/rules.d, so which one actually rules?
>>>
>>> The one in /etc, as David said. Unless it doesn't exist.
>>>
>>> This is actually the classical pattern of "layered configuration", which
>>> is widespread in the UNIX world. You see that often with a system config
>>> which can be overridden by a user config.
>>>
>>> Sometimes you have even three layers: distro (e.g. lib), local (etc) and
>>> user.
>>
>> Thanks for the clarification Tomas. That would intimate the search
>> order would be /home/$usr/someplace, /etc/someplace, /lib/someplace.
>> Is that correct?
>
> Not only did I give the priority for the task you're tackling
> (which BTW would not concern an individual user's directory tree),
> I also gave you the reference: man udev.
>
> What is your problem??
>

man udev is as opaque as you can make what looks like plain English.

>> Change of subject:
>>
>> I have a mod I make to the $PATH which I've put in .profile, but I've
>> failed to find a place to make it autoexec when I login. And I'm tired
>> of typing ". .profile in every shell tab I open.
>>
>> Suggestion?
>
> Read INVOCATION in man 1 bash (and check the existence and priorities
> of the several startup files). But I feel I'm wasting my breath.
>
> PS New thread for a new subject? Come on …
>
> Cheers,
> David.

[to...@tuxteam.de]

On Fri, Jun 09, 2023 at 09:47:56AM -0400, gene heskett wrote:
> On 6/9/23 09:33, Greg Wooledge wrote:
> > On Fri, Jun 09, 2023 at 09:25:25AM -0400, gene heskett wrote:
> > > On 6/9/23 07:33, Greg Wooledge wrote:
> > > > Finally, remember that .xsession is run by /bin/sh, not by your login
> > > > shell. So, if you've got bash syntax in .profile (or anything it dots
> > > > in, such as .bashrc), then you cannot safely dot it in from .xsession.
> > > >
> > > > .
> > > Apparently this last is true. I put it as next to last line in
> > > /etc/X11/Xsession and killed everything I had running but did let me exec a
> > > new xfce4 terminal, which did not get the fix so fixed it back to original
> > > but still had to reboot.
> >
> > I would NOT advise modifying the files in /etc/X11, especially if you
> > aren't 100% sure what you're doing. There are lot of subtle and delicate
> > moving parts in there.
> >
> > Whatever you end up doing to get your PATH set properly at login should
> > happen only in your $HOME directory.
> >
> > Start with .xsessionrc (the Debian hack) and see if that works. Put a
> > PATH modification in there, and also put something like
> >
> > export GENETEST=hello
> >
> in a $HOME/.xsessionrc had no effect on a new xfce4 terminal.

Make sure /etc/X11/Xsession.options has a non-commented out

allow-user-xsession

I think on my box it wasn't the default.

Cheers
--
t

[gene heskett]

And I'm subbed, no need for reply-all. ;o)>
>
> Cheers

[gene heskett]

it was un-commented and still is.

>
> I think on my box it wasn't the default.
>
> Cheers

[Greg Wooledge]

On Fri, Jun 09, 2023 at 09:47:56AM -0400, gene heskett wrote:
> On 6/9/23 09:33, Greg Wooledge wrote:
> > Start with .xsessionrc (the Debian hack) and see if that works. Put a
> > PATH modification in there, and also put something like
> >
> > export GENETEST=hello
> >
> in a $HOME/.xsessionrc had no effect on a new xfce4 terminal.

Did you log out and back in, or did you simply start a new XFCE4
terminal within an existing session? The .xsessionrc file is only
read during X session startup, not when running various applications
like terminal emulators.

(Yes, I know, it's a PAIN to log out and back in, at least for me, and
it sounded like for you too... but it's required for this test to be
meaningful. It's not urgent, so you can do it when it's convenient.)

[gene heskett]

> .
logging out and back in may as well be a reboot. I normally run with
quite a few apps I have to restart, and rebuild my network to up to 9
other machines, up to 9 ssh -Y shells, (allthough the -Y doesn't work
any more which severely limits the editors I can use, a bigger pita than
this in fact.) and 6 or more links for mc to copy things around. Yes,
its a pita. Done if needed of course. Thanks Greg.

Take care & stay well.

[David Wright]

On Fri 09 Jun 2023 at 09:41:23 (-0400), gene heskett wrote:
> On 6/9/23 06:51, David Wright wrote:
> > On Fri 09 Jun 2023 at 06:20:07 (-0400), gene heskett wrote:
> > > On 6/9/23 00:46, to...@tuxteam.de wrote:
> > > > On Thu, Jun 08, 2023 at 09:08:59PM -0400, gene heskett wrote:
> > > >
> > > > [...]
> > > >
> > > > > Perhaps I've ben mistaken, but the files in /etc/udev/rules.d are not the
> > > > > same as /lib/udev/rules.d, so which one actually rules?
> > > >
> > > > The one in /etc, as David said. Unless it doesn't exist.
> > > >
> > > > This is actually the classical pattern of "layered configuration", which
> > > > is widespread in the UNIX world. You see that often with a system config
> > > > which can be overridden by a user config.
> > > >
> > > > Sometimes you have even three layers: distro (e.g. lib), local (etc) and
> > > > user.
> > >
> > > Thanks for the clarification Tomas. That would intimate the search
> > > order would be /home/$usr/someplace, /etc/someplace, /lib/someplace.
> > > Is that correct?
> >
> > Not only did I give the priority for the task you're tackling
> > (which BTW would not concern an individual user's directory tree),
> > I also gave you the reference: man udev.
> >
> > What is your problem??
> >
> man udev is as opaque as you can make what looks like plain English.

I find it hard to believe that the exams you're always talking about
having passed are any easier than understanding:

"All rules files are collectively sorted and processed in lexical
order, regardless of the directories in which they live. However,
files with identical filenames replace each other.
Files in /etc/ have the highest priority, files in /run/
take precedence over files with the same name under /usr/.
This can be used to override a system-supplied rules file
with a local file if needed"

But paraphrasing myself, not only did I give you the reference,
I also gave you the priority for the task you're tackling:

"Files under /etc/ take priority over those under /usr/lib/
when their filenames are the same."

Cheers,
David.

[Cousin Stanley]

On 2023-06-09 13:00, gene heskett wrote:

>> Did you log out and back in, or did you simply start
>> a new XFCE4 terminal within an existing session?
>>
>> The .xsessionrc file is only read
>> during X session startup, not when running
>> various applications like terminal emulators.
>>
>>
>>> (Yes, I know, it's a PAIN to log out and back in,
>>> at least for me, and> it sounded like for you too...
>>> but it's required for this test to be meaningful.
>>>

>>> logging out and back in may as well be a reboot.

I sometimes update the .xsessionrc file
for various reasons and then source it
to activate the changes without logging out
or restarting ....

sk@jhp1 03:52 PM ~
$ echo "export SKUNK='pee euuu' " >> .xsessionrc

sk@jhp1 03:53 PM ~
$ echo $SKUNK

sk@jhp1 03:53 PM ~
$ source .xsessionrc

sk@jhp1 03:53 PM ~
$ echo $SKUNK
pee euuu



--
Stanley C. Kitching
Human Being
Phoenix, Arizona

[David Wright]

Two problems here:

Other sessions are unaware of the change made in one; and
the point of this thread is to find a location where Gene's
".profile" file is run regardless of how he logs in. This
doesn't test that.

Cheers,
David.

[Cousin Stanley]

>> Cousin Stanley wrote ....

>>
>> I sometimes update the .xsessionrc file
>> for various reasons and then source it
>> to activate the changes without logging out
>> or restarting ....

On 2023-06-10 00:20, David Wright wrote:

> Two problems here:
>
> Other sessions are unaware of the change made in one ;

After updating the .xsessionrc file in one session
what I usually do is also source it from another ....

$ source ~/.xsessionrc

However, my naive view of another session here
entails a different tab opened in qterminal
running under lxqt ,,,,

> and the point of this thread is to find a location

> where Gene's.profile" file is run regardless

> of how he logs in.
>
> This doesn't test that.

I understand but only wanted to suggest
that a logout was not necessarily required
to reflect any changes in the .xsessionrc file

[gene heskett]

A neat trick, thanks. if I can remember it. I've reached that age where
I can't remember what, if anything I had for breakfast most mornings.

[Cousin Stanley]

Cousin Stanley wrote ....

>> ....
>> $ source .xsessionrc
>> ....


On 2023-06-10 10:10, gene heskett wrote:

> A neat trick, thanks.

You're welcome.

> I've reached that age where I can't remember what,
> if anything I had for breakfast most mornings.

I'm on the way ....

Birthday next month will turn 77.

My mother designated age-related memory lapses
as CRS ....

Can't Remember Squat

I have occasional memory lapses as well.

[gene heskett]

On 6/10/23 15:27, Cousin Stanley wrote:
>
>
> Cousin Stanley wrote ....
>
> >> ....
> >> $ source .xsessionrc
> >> ....
>
>
> On 2023-06-10 10:10, gene heskett wrote:
>
> > A neat trick, thanks.
>
>   You're welcome.
>
>
> > I've reached that age where I can't remember what,
> > if anything I had for breakfast most mornings.
>
>   I'm on the way ....
>
>     Birthday next month will turn 77.

I'll be 89 in October.

>   My mother designated age-related memory lapses
>   as CRS ....
>
>      Can't Remember Squat
>

She was being nice. My version is CRE.

>  I have occasional memory lapses as well.

I think it will happen to all of us, eventually.

Take care & stay well.

[gene heskett]

The last of those tests, was in 1972, 51 years ago. I finally did get a
GED about 25 years ago. My now departed 3rd wife had a degree in music,
and said it was embarrassing to tell her friends her hubby only had an
8th grade education. Now I'm 88 and fading which I'll also admit to.

But I'll readily admit its been one hell of a ride to get this far. ;o)>

Pure serendipity has put me in places and times that made history, so I
also have all these "war stories" I occasionally bore folks with.

>
> "All rules files are collectively sorted and processed in lexical
> order, regardless of the directories in which they live. However,
> files with identical filenames replace each other.
> Files in /etc/ have the highest priority, files in /run/
> take precedence over files with the same name under /usr/.
> This can be used to override a system-supplied rules file
> with a local file if needed"
>
> But paraphrasing myself, not only did I give you the reference,
> I also gave you the priority for the task you're tackling:
> "Files under /etc/ take priority over those under /usr/lib/
> when their filenames are the same."
>

Yup, you did all of that, thank you David.

Take care & stay well.
> Cheers,

> David.

[Sascha Silbe]

Hello Michael,

Michael Biebl <bi...@debian.org> writes:

>> Not sure if it's fixed in Bookworm already. The upstream fix went in at
>> v253. Bookworm is at 252.6 which doesn't exist as a tag in the upstream
>> repo so I cannot check if the fix was backported.
>
> stable/point releases can be found in the systemd-stable repository. See
> https://github.com/systemd/systemd-stable/

Thanks for the pointer! I can now see that the fix went in upstream in
v252.1 so it should be contained in both the bullseye-backports
(252.5-2~bpo11+1) and bookworm (252.6-1) versions. In fact I can confirm
that a recently installed Bookworm host (armhf) is NOT affected.

Sascha

[Sascha Silbe]

Hello,

gene heskett <ghes...@shentel.net> writes:

>> That's Debian#1035094 [1]. A fix was uploaded three weeks ago and is
>> available in bullseye-proposed-updates [2] but not the regular Bullseye
>> repository. If I understand the status page [3] correctly it's only
>> scheduled for the next point release. Given that there already was a
>> point release recently (11.7 on 2023-05-01) it will probably another
>> couple of months until this bug gets fixed in bullseye. :-/
[...]
> That is most unfortunate for 3d printer users, our support group on
> discord is blowing up with the problems this is cause for klipper users,
> can its priority be raised? We use it because that gives us a
> bulletproof method using the devices ChipID, which is totally unique,
> like MAC addresses.

Tell me about it. As an embedded developer this bug is a huge PITA. I'm
surprised the fix for this regression hasn't already landed in
stable. But then I don't know what else changed and what the risks are
for other bugs to show up and potentially affect even more users. After
all systemd is a rather central component of most Debian systems.

You may want to try asking on the bug report (#1035094 [1]) about
it. I'm not a Debian Developer myself and don't have much experience
trying to get a fix landed in stable but I expect there is a way for the
maintainers of the package to request an exception and get the fix in
the repository before the next point release.

As a first step however we should try out the version from
bullseye-proposed-updates to make sure it's safe to use. I've already
installed it on one of my hosts (where it fixed the bug) and will
monitor it for regressions; would be great if others did the same.

Sascha

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035094

[Sascha Silbe]

Hello Gene,

gene heskett <ghes...@shentel.net> writes:

[udev update from proposed-updates]
> I couldn't figure how to dl the file, so I snapshoted the diff screen
> from [1], and will compare it to what I have from the patch, which it
> appears I have not done to this machine, as I have /dev/serial/by-path
> only here, no by-id. This bug is a showstopper for users of 3d printers.


Warning: Only do any of the following on a host you can afford to
break. If systemd malfunctions you may not even be able to boot the
system any more.


*-proposed-updates is an APT repository. The easiest way to access it is
to add it to sources.list:

=== Begin ===
deb http://deb.debian.org/debian/ bullseye-proposed-updates main
=== End ===

I added an APT preferences rule (create a file for it in
/etc/apt/preferences.d/) to update all systemd packages from
bullseye-proposed-updates:

=== Begin ===
Explanation: Pull in fix for Debian#1035094 before next point release
Package: libnss-myhostname libnss-mymachines libnss-resolve libnss-systemd libpam-systemd libsystemd0 libsystemd-dev libsystemd-shared libudev1 libudev1-udeb libudev-dev systemd systemd-boot systemd-boot-efi systemd-container systemd-coredump systemd-dev systemd-homed systemd-journal-remote systemd-oomd systemd-resolved systemd-standalone-sysusers systemd-standalone-tmpfiles systemd-sysv systemd-tests systemd-timesyncd systemd-userdbd udev udev-udeb
Pin: release n=bullseye-proposed-updates
Pin-Priority: 990
=== End ===

Then just upgrade like usual using APT.

If you want to download the packages manually (which gets tedious fast)
you can find them in the systemd directory [1] in the package
pool. bullseye-proposed-updates currently points at 247.3-7+deb11u3 (see
e.g. the amd64 Packages.xz [2]).


Sascha

[1] http://deb.debian.org/debian/pool/main/s/systemd/
[2] http://deb.debian.org/debian/dists/bullseye-proposed-updates/main/binary-amd64/Packages.xz

[Fred]

Hi,
If systemd is a problem you could try using Devuan Linux. Devuan is
Debian without systemd.
Best regards,
Fred

[to...@tuxteam.de]

On Wed, Jun 14, 2023 at 12:24:21PM -0700, Fred wrote:

[...]

> Hi,
> If systemd is a problem you could try using Devuan Linux. Devuan is Debian
> without systemd.
> Best regards,
> Fred

This wasn't helpful at all: it's not systemd, but one udev rule
(which are maintained under the systemd umbrella anyway). Changing
the whole operating system for this doesn't really make sense.

And oh, I yesterday just installed the all-new Bookworm with SysV
init (thank to all of you who make this still possible!).

Cheers
--
t

[gene heskett]

A fixit script was posted on discord/linux/klipper/configuration, and
pinned. It worked ok on several of my bananapi-m5's and my i5 version of
bullseye had a /dev/serial/by-path, but no by-id, so I ran that same
script here, but it pulled in 39 other updates at the same time and blew
away my passwd. no root pw had ever been set as I use sudo for that, so
I was locked out. 5 installs later I'm finally back in business. But my
setup is a bit unusual, /home is a raid10 of 1.7 TB on 4 1Tb samsung
ssd's, with 60Gb of swap on the rest of that raid10. And I still haven't
recreated my local /sshnet network of all my cnc'd machines and 3d
printers but that's just details I haven't addressed yet.

That script does an apt update && apt upgrade -y before it pulls in this
new 60-persistent-serial into /etc/udev/rules.d. Then recommended
strongly that I reboot.

It has not actually bothered this machine. so given the nearly 3 days of
hell it gave me to recover from it, I'll wait for it to make 64 bit
intel bullseye.

As for the networking, I've found sshfs to be many times more dependable
than nfs any version, it Just Works. That forces me to go to that
machines keyboard for root stuffs, its only disadvantage. But I'll go
check that bug since to see if its the same fix.

Take care & stay well.