Re: How to rebuild the keys for APT.

[Philip]

SOLUTION:
I went though and added all the keys again and now it's working again.

sudo apt-key adv --keyserver keyserver.debian.org --recv-keys [KEY_MISSING]

Works good now.  Thanks everyone for the help.

Phil

On 16/05/2018 17:06, deloptes wrote:

Philip wrote:


I recently had to move a disk image from machine to another machine
however when I fired it up on the new machine the APT keys were
broken/corrupted. The errors I'm getting are below... Is there a simple
way of fixing this?

perhaps it is not only the gpg keys that got broken. How did you make/move
the disk image to another machine?

there is a page on the Debian Wiki how you import the keys, but it might be
something else missing as well

regards

Re: Running GParted and Synaptic without entering password

[Richard Owlett]

On 05/16/2018 12:36 AM, John Crawley wrote:

On 2018-05-15 22:24, Richard Owlett wrote:

On 05/15/2018 12:48 AM, John Crawley (johnraff) wrote:


Policykit brings its own complications, but I think it should be 
possible to create a .pkla file in /var/lib/polkit-1/localauthority 
to allow a certain user, or group member, to perform an action 
defined in /usr/share/polkit-1/actions/* without a password. You 
could even add a new action if necessary.


Through a chain of references I discovered
   /usr/share/polkit-1/actions/com.ubuntu.pkexec.gparted.policy

The initial lines read:


http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd";>



However
   [http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd]
gives a 404 File not found message.


Indeed. Even so, that seems to be what is required in the xml.


Where would I find its syntax?


I had a similar problem a while ago and found internet searches to be 
somewhat helpful.


My searches were not as good. Thank you.


This is not Debian, but on-topic:
https://wiki.archlinux.org/index.php/Polkit
And:
https://www.freedesktop.org/software/polkit/docs/0.105/pklocalauthority.8.html 


http://davidz25.blogspot.jp/2012/06/authorization-rules-in-polkit.html
https://github.com/systemd/systemd/issues/5523


I don't know if they answer ALL my questions.
BUT they each specifically address one or more of my questions.
They also suggest some likely fruitful search terms.



It seems polkit want to shift from .pkla files to (javascript-like) 
.rules files, but at the moment both might work on Debian, so use 
whichever you feel less uncomfortable with.


I used a .pkla file in /var/lib/polkit-1/localauthority/10-vendor.d/. If 
you search for *.pkla files on your system, there might be some there, 
or in /etc/polkit-1/localauthority/* to use as a template.



By a convoluted path I found:
[https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html]

Its last example strongly suggests I can do just what I want without 
messing up other users &/or apps.


That's what I think too. Just as an untested guess, since the action is 
already defined, something like this in 
/etc/polkit-1/localauthority/50-local.d/gparted.pkla?


[Allow specific user to use gparted]
Identity=unix-user:yourusername
Action=com.ubuntu.pkexec.gparted
ResultAny=no
ResultInactive=no
ResultActive=yes

BTW To see the currently defined actions on your system, try this:
cat /usr/share/polkit-1/actions/* | grep -E 
'(||)'|sed 
's/<\/action>/\n/g;s/<\/[^>]*>//g'

But you can add one of your own too.

lightdm (testing): Long waiting time after login

[work]

I just did a fresh install of testing with XFCE. After entering the login credentials the screen was black for 30-60 seconds before the desktop environment showed up. Assuming a bug in XFCE, I performed another fresh install with MATE, but a similar effect occured: after login the background image is shown for 30-60 seconds before the desktop is fully loaded.

A look into /var/log/lightdm/lightdm.log showed that the delay happens before VT is activated. The log file is attached.

Might this be a bug in lightdm or could a misconfiguragtion from my side cause this issue?

Best,
Dino

Re: lightdm (testing): Long waiting time after login

[Dino]

This time with attachment...

Am 16.05.2018 um 09:28 schrieb w...@hllmnn.de:


I just did a fresh install of testing with XFCE. After entering the 
login credentials the screen was black for 30-60 seconds before the 
desktop environment showed up. Assuming a bug in XFCE, I performed 
another fresh install with MATE, but a similar effect occured: after 
login the background image is shown for 30-60 seconds before the 
desktop is fully loaded.


A look into /var/log/lightdm/lightdm.log showed that the delay happens 
before VT is activated. The log file is attached.


Might this be a bug in lightdm or could a misconfiguragtion from my 
side cause this issue?


Best,
Dino



[+0.00s] DEBUG: Logging to /var/log/lightdm/lightdm.log
[+0.00s] DEBUG: Starting Light Display Manager 1.18.3, UID=0 PID=595
[+0.00s] DEBUG: Loading configuration dirs from /usr/share/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration from /usr/share/lightdm/lightdm.conf.d/01_debian.conf
[+0.00s] DEBUG: Loading configuration dirs from /usr/local/share/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration dirs from /etc/xdg/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration from /etc/lightdm/lightdm.conf
[+0.00s] DEBUG: Using D-Bus name org.freedesktop.DisplayManager
[+0.00s] DEBUG: Registered seat module xlocal
[+0.00s] DEBUG: Registered seat module xremote
[+0.00s] DEBUG: Registered seat module unity
[+0.06s] DEBUG: Monitoring logind for seats
[+0.06s] DEBUG: New seat added from logind: seat0
[+0.06s] DEBUG: Seat seat0: Loading properties from config section Seat:*
[+0.06s] DEBUG: Seat seat0: Starting
[+0.06s] DEBUG: Seat seat0: Creating greeter session
[+0.07s] DEBUG: Seat seat0: Creating display server of type x
[+0.07s] DEBUG: Could not run plymouth --ping: Failed to execute child process “plymouth” (No such file or directory)
[+0.07s] DEBUG: Using VT 7
[+0.07s] DEBUG: Seat seat0: Starting local X display on VT 7
[+0.07s] DEBUG: DisplayServer x-0: Logging to /var/log/lightdm/x-0.log
[+0.07s] DEBUG: DisplayServer x-0: Writing X server authority to /var/run/lightdm/root/:0
[+0.07s] DEBUG: DisplayServer x-0: Launching X Server
[+0.07s] DEBUG: Launching process 610: /usr/bin/X :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
[+0.07s] DEBUG: DisplayServer x-0: Waiting for ready signal from X server :0
[+0.07s] DEBUG: Acquired bus name org.freedesktop.DisplayManager
[+0.07s] DEBUG: Registering seat with bus path /org/freedesktop/DisplayManager/Seat0
[+0.08s] DEBUG: Loading users from org.freedesktop.Accounts
[+0.08s] DEBUG: User /org/freedesktop/Accounts/User1000 added
[+1.42s] DEBUG: Got signal 10 from process 610
[+1.42s] DEBUG: DisplayServer x-0: Got signal from X server :0
[+1.42s] DEBUG: DisplayServer x-0: Connecting to XServer :0
[+1.48s] DEBUG: Seat seat0: Display server ready, starting session authentication
[+1.48s] DEBUG: Session pid=637: Started with service 'lightdm-greeter', username 'lightdm'
[+1.52s] DEBUG: Session pid=637: Authentication complete with return value 0: Success
[+1.52s] DEBUG: Seat seat0: Session authenticated, running command
[+1.52s] DEBUG: Session pid=637: Running command /usr/sbin/lightdm-gtk-greeter
[+1.52s] DEBUG: Creating shared data directory /var/lib/lightdm/data/lightdm
[+1.52s] DEBUG: Session pid=637: Logging to /var/log/lightdm/seat0-greeter.log
[+1.69s] DEBUG: Activating VT 7
[+1.69s] DEBUG: Activating login1 session c1
[+1.70s] DEBUG: Seat seat0 changes active session to c1
[+1.70s] DEBUG: Session c1 is already active
[+2.10s] DEBUG: Greeter connected version=1.18.3 resettable=false
[+3.22s] DEBUG: Greeter start authentication
[+3.22s] DEBUG: Session pid=689: Started with service 'lightdm', username '(null)'
[+3.24s] DEBUG: Session pid=689: Got 1 message(s) from PAM
[+3.24s] DEBUG: Prompt greeter with 1 message(s)
[+5.72s] DEBUG: Greeter start authentication for USERNAME
[+5.72s] DEBUG: Session pid=689: Sending SIGTERM
[+5.72s] DEBUG: Session pid=691: Started with service 'lightdm', username 'USERNAME'
[+5.72s] DEBUG: Session pid=689: Terminated with signal 15
[+5.72s] DEBUG: Session: Failed during authentication
[+5.72s] DEBUG: Seat seat0: Session stopped
[+5.73s] DEBUG: Session pid=691: Got 1 message(s) from PAM
[+5.73s] DEBUG: Prompt greeter with 1 message(s)
[+7.52s] DEBUG: Continue authentication
[+7.55s] DEBUG: Session pid=691: Authentication complete with return value 0: Success
[+7.55s] DEBUG: Authenticate result for user USERNAME: Success
[+7.55s] DEBUG: User USERNAME authorized
[+7.63s] DEBUG: Greeter requests session lightdm-xsession
[+7.63s] DEBUG: Seat seat0: Stopping greeter; display server will be re-used for user session
[+7.63s] DEBUG: Session pid=637: Sending SIGTERM
[+7.71s] DEBUG: Greeter closed communication channel
[+7.71s] DEBUG: Session pid=637: Exited with return value 0
[+7.71s] DEBUG: Seat seat0: Session stopped
[+7.71s] DEBUG: Seat seat0: Greeter stopped, running session
[+7.71s] DEBUG: Registering session with b

Re: Running GParted and Synaptic without entering password

[Joe]

On Tue, 15 May 2018 18:27:20 +
Glenn English  wrote:

> When I've logged in as a mortal to my XFCE GUI, I can just type, in
> the terminal emulator, 'sudo gparted' and the GUI comes up and works
> like I expect it to. After I quit gparted, there's some stuff it's
> written on the screen (I've never tried to figure out what it's
> about).
> 
> I haven't tried that with Synaptic, but I'd be surprised if it whined.
> I know 'sudo aptitude' works, but CLI tools are what sudo's for.

You can run any program that way, once you know what file launches it.
It is how you begin debugging a faulty GUI app, the stuff left behind
when it closes may be useful. Or it may just be GTK garbage...

-- 
Joe 

Re: lightdm (testing): Long waiting time after login

[songbird]

Dino wrote:
> This is a multi-part message in MIME format.
> --D295C2A19D414A0F9C32AEE8
> Content-Type: multipart/alternative;
>  boundary="51A034E61483D85CC097E79C"
>
>
> --51A034E61483D85CC097E79C
> Content-Type: text/plain; charset=utf-8; format=flowed
> Content-Transfer-Encoding: 7bit
>
> This time with attachment...
>
> Am 16.05.2018 um 09:28 schrieb w...@hllmnn.de:
>>
>> I just did a fresh install of testing with XFCE. After entering the 
>> login credentials the screen was black for 30-60 seconds before the 
>> desktop environment showed up. Assuming a bug in XFCE, I performed 
>> another fresh install with MATE, but a similar effect occured: after 
>> login the background image is shown for 30-60 seconds before the 
>> desktop is fully loaded.
>>
>> A look into /var/log/lightdm/lightdm.log showed that the delay happens 
>> before VT is activated. The log file is attached.
>>
>> Might this be a bug in lightdm or could a misconfiguragtion from my 
>> side cause this issue?
...
> [+7.71s] DEBUG: Session pid=691: Running command /etc/X11/Xsession default
> [+7.71s] DEBUG: Creating shared data directory /var/lib/lightdm/data/USERNAME
> [+7.71s] DEBUG: Session pid=691: Logging to .xsession-errors
> [+40.89s] DEBUG: Activating VT 7
> [+40.89s] DEBUG: Activating login1 session 2
> [+40.89s] DEBUG: Seat seat0 changes active session to 
> [+40.89s] DEBUG: Seat seat0 changes active session to 2
> [+40.89s] DEBUG: Session 2 is already active

  what does .xsession-errors say?

  what type of device are you installing to?

  my recent installs with netinst for testing and having MATE
comes up ok (within a few seconds), but things may have changed
in packages.

  does a stable netinst give same results?


  songbird

Changing systemd startup timeout

[Dave Sherohman]

Short version:

How can I extend (or remove) the startup timeout for a single systemd
service?


Longer version:

I'm running a galera cluster of three mariadb servers.  It's been
brought down twice because one node has detected an inconsistency,
killed itself, and then systemd automatically restarted it.  This is all
good so far.

The problem comes in when it tries to restart and, because it shut down
in an inconsistent state, it wants to do a full state transfer to get
back in sync with the rest of the cluster, which involves copying
(potentially) 24G of data.  Performing this transfer takes long enough
that systemd times out, assumes the restart failed, and kills it, so
it's not possible to bring the node back online without bypassing
systemd and running mysqld_safe manually.

Based on some web searches, I've tried using `systemctl edit mysql` to
set "TimeoutStartUSec=infinity", but this does not appear to actually
have any effect, even after reloading the systemd daemon:

# systemctl edit mysql

# systemctl show mysql -p TimeoutStartUSec
TimeoutStartUSec=1min 30s
# systemctl daemon-reload
# systemctl show mysql -p TimeoutStartUSec
TimeoutStartUSec=1min 30s
# systemctl daemon-reexec
# systemctl show mysql -p TimeoutStartUSec
TimeoutStartUSec=1min 30s

What do I need to do to make this actually work?  Or is it possible to
tell systemd to use a different method of determining whether mysqld has
started successfully, so that it will recognize "SST in progress" as a
valid "started" state?

-- 
Dave Sherohman

Re: Changing systemd startup timeout

[Sven Joachim]

On 2018-05-16 06:04 -0500, Dave Sherohman wrote:

> I'm running a galera cluster of three mariadb servers.  It's been
> brought down twice because one node has detected an inconsistency,
> killed itself, and then systemd automatically restarted it.  This is all
> good so far.
>
> The problem comes in when it tries to restart and, because it shut down
> in an inconsistent state, it wants to do a full state transfer to get
> back in sync with the rest of the cluster, which involves copying
> (potentially) 24G of data.  Performing this transfer takes long enough
> that systemd times out, assumes the restart failed, and kills it, so
> it's not possible to bring the node back online without bypassing
> systemd and running mysqld_safe manually.
>
> Based on some web searches, I've tried using `systemctl edit mysql` to
> set "TimeoutStartUSec=infinity", but this does not appear to actually
> have any effect, even after reloading the systemd daemon:
>
> # systemctl edit mysql
> 
> # systemctl show mysql -p TimeoutStartUSec
> TimeoutStartUSec=1min 30s
> # systemctl daemon-reload
> # systemctl show mysql -p TimeoutStartUSec
> TimeoutStartUSec=1min 30s
> # systemctl daemon-reexec
> # systemctl show mysql -p TimeoutStartUSec
> TimeoutStartUSec=1min 30s
>
> What do I need to do to make this actually work?

Have you tried setting TimeoutStartSec rather than TimeoutStartUSec?
Though I have to admit that I did not perform a web search but cheated
by looking at the systemd.service(5) manpage, which mentions the former
but not the latter.

Cheers,
   Sven

Re: lightdm (testing): Long waiting time after login

[Dino]

Dino wrote:

This is a multi-part message in MIME format.
--D295C2A19D414A0F9C32AEE8
Content-Type: multipart/alternative;
  boundary="51A034E61483D85CC097E79C"


--51A034E61483D85CC097E79C
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

This time with attachment...

Am 16.05.2018 um 09:28 schrieb w...@hllmnn.de:

I just did a fresh install of testing with XFCE. After entering the
login credentials the screen was black for 30-60 seconds before the
desktop environment showed up. Assuming a bug in XFCE, I performed
another fresh install with MATE, but a similar effect occured: after
login the background image is shown for 30-60 seconds before the
desktop is fully loaded.

A look into /var/log/lightdm/lightdm.log showed that the delay happens
before VT is activated. The log file is attached.

Might this be a bug in lightdm or could a misconfiguragtion from my
side cause this issue?

...

[+7.71s] DEBUG: Session pid=691: Running command /etc/X11/Xsession default
[+7.71s] DEBUG: Creating shared data directory /var/lib/lightdm/data/USERNAME
[+7.71s] DEBUG: Session pid=691: Logging to .xsession-errors
[+40.89s] DEBUG: Activating VT 7
[+40.89s] DEBUG: Activating login1 session 2
[+40.89s] DEBUG: Seat seat0 changes active session to
[+40.89s] DEBUG: Seat seat0 changes active session to 2
[+40.89s] DEBUG: Session 2 is already active

   what does .xsession-errors say?

   what type of device are you installing to?

   my recent installs with netinst for testing and having MATE
comes up ok (within a few seconds), but things may have changed
in packages.

   does a stable netinst give same results?


   songbird
.xsession-errors contains one warning (file is attached), but I don't 
think that it causes the delay.


The device I'm installing to is an UDOO X86 
(https://www.udoo.org/udoo-x86/). Basically, it's standard hardware with 
an Intel CPU. I already had an installation of testing a few months ago 
that didn't show this behaviour.


A stable netinst works just fine, the desktop is loaded almost 
immediately. Hence, I assume a package changed recently is the reason 
for this.
Xsession: X session started for USERNAME at Wed May 16 13:57:36 CEST 2018
dbus-update-activation-environment: setting 
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
dbus-update-activation-environment: setting DISPLAY=:0
dbus-update-activation-environment: setting 
XAUTHORITY=/home/USERNAME/.Xauthority
localuser:USERNAME being added to access control list
dbus-update-activation-environment: setting GTK_MODULES=gail:atk-bridge
dbus-update-activation-environment: setting QT_ACCESSIBILITY=1
dbus-update-activation-environment: setting USER=USERNAME
dbus-update-activation-environment: setting LANGUAGE=en_US:en
dbus-update-activation-environment: setting XDG_SESSION_TYPE=x11
dbus-update-activation-environment: setting HOME=/home/USERNAME
dbus-update-activation-environment: setting DESKTOP_SESSION=lightdm-xsession
dbus-update-activation-environment: setting 
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
dbus-update-activation-environment: setting GTK_MODULES=gail:atk-bridge
dbus-update-activation-environment: setting 
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
dbus-update-activation-environment: setting LOGNAME=USERNAME
dbus-update-activation-environment: setting 
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
dbus-update-activation-environment: setting 
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0
dbus-update-activation-environment: setting XDG_RUNTIME_DIR=/run/user/1000
dbus-update-activation-environment: setting DISPLAY=:0
dbus-update-activation-environment: setting LANG=en_US.UTF-8
dbus-update-activation-environment: setting XDG_SESSION_DESKTOP=lightdm-xsession
dbus-update-activation-environment: setting 
XAUTHORITY=/home/USERNAME/.Xauthority
dbus-update-activation-environment: setting 
XDG_GREETER_DATA_DIR=/var/lib/lightdm/data/USERNAME
dbus-update-activation-environment: setting SHELL=/bin/bash
dbus-update-activation-environment: setting GDMSESSION=lightdm-xsession
dbus-update-activation-environment: setting QT_ACCESSIBILITY=1
dbus-update-activation-environment: setting 
GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent:0:1
dbus-update-activation-environment: setting PWD=/home/USERNAME
dbus-update-activation-environment: setting 
XDG_DATA_DIRS=/usr/share/mate:/usr/local/share/:/usr/share/
x-session-manager[773]: WARNING: Unable to find provider '' of required 
component 'dock'
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh

Re: UEFI/"BIOS" booting

[mess-mate]

On 16-May-18 00:23, Pascal Hambourg wrote:

Le 15/05/2018 à 03:37, David Wright a écrit :



But GRUB is not the only available bootloader.


No.

It's difficult to divine which bootloaders the author is familiar with.
My own experience of the last twenty years is limited to Lilo and Grub.


Same here. I would not trust LILO any more now because it uses 
hardcoded blocklists to read files, just like GRUB does when embedding 
is not possible, which is considered unreliable.



I remember reading about coreboot some years ago, but I doubt I'm ever
going to meet it. Are you suggesting others?


AFAIK, Coreboot is a replacement for platform firmware (BIOS), not an 
installable boot loader.


I have never used it, but it seems that syslinux supports GPT and EFI.
Also I have read positive reports about rEFInd for EFI boot.


Your're right.
I've installed windows 10first a mont ago, after that last debian and 
rEFIND.

All run smootless without any problem and at the first install.
Of course, partitions on GPT and UEFI.

Re: Changing systemd startup timeout

[Curt]

On 2018-05-16, Sven Joachim  wrote:
>>
>> # systemctl edit mysql
>> 
>> # systemctl show mysql -p TimeoutStartUSec
>> TimeoutStartUSec=1min 30s
>> # systemctl daemon-reload
>> # systemctl show mysql -p TimeoutStartUSec
>> TimeoutStartUSec=1min 30s
>> # systemctl daemon-reexec
>> # systemctl show mysql -p TimeoutStartUSec
>> TimeoutStartUSec=1min 30s
>>
>> What do I need to do to make this actually work?
>
> Have you tried setting TimeoutStartSec rather than TimeoutStartUSec?
> Though I have to admit that I did not perform a web search but cheated
> by looking at the systemd.service(5) manpage, which mentions the former
> but not the latter.

Moderately confusing to the hoi polloi because 'systemctl show' lists

 DefaultTimeoutStartUSec=1min 30s

here (and probably elsewhere).

It appears that the property and the configurable option are
unidentical. This could lead to head-scratching as well as unwelcome
headaches.

USECs are apparently µs (microseconds--dbus api unit). 

Anyway, it's all far beyond me, and your advice is sound. I was going to
say but didn't earlier that previously '0' (prior to systemd version
239) rather than 'infinity' turned off timeouts (not exactly what
you'd call intuitive, either, 0=infinity), in case the OP might be
using some older release.

> Cheers,
>Sven
>
>


-- 

Re: Changing systemd startup timeout

[Dave Sherohman]

On Wed, May 16, 2018 at 02:09:43PM +0200, Sven Joachim wrote:
> Have you tried setting TimeoutStartSec rather than TimeoutStartUSec?
> Though I have to admit that I did not perform a web search but cheated
> by looking at the systemd.service(5) manpage, which mentions the former
> but not the latter.

Whaddayaknow, that did the trick.  Thanks!

Strange, though, that you have to set it as TimeoutStartSec, but
`systemctl show` displays it as TimeoutStartUSec.

-- 
Dave Sherohman

Re: Changing systemd startup timeout

[David Wright]

On Wed 16 May 2018 at 14:09:43 (+0200), Sven Joachim wrote:
> On 2018-05-16 06:04 -0500, Dave Sherohman wrote:
> 
> > I'm running a galera cluster of three mariadb servers.  It's been
> > brought down twice because one node has detected an inconsistency,
> > killed itself, and then systemd automatically restarted it.  This is all
> > good so far.
> >
> > The problem comes in when it tries to restart and, because it shut down
> > in an inconsistent state, it wants to do a full state transfer to get
> > back in sync with the rest of the cluster, which involves copying
> > (potentially) 24G of data.  Performing this transfer takes long enough
> > that systemd times out, assumes the restart failed, and kills it, so
> > it's not possible to bring the node back online without bypassing
> > systemd and running mysqld_safe manually.
> >
> > Based on some web searches, I've tried using `systemctl edit mysql` to
> > set "TimeoutStartUSec=infinity", but this does not appear to actually
> > have any effect, even after reloading the systemd daemon:
> >
> > # systemctl edit mysql
> > 
> > # systemctl show mysql -p TimeoutStartUSec
> > TimeoutStartUSec=1min 30s
> > # systemctl daemon-reload
> > # systemctl show mysql -p TimeoutStartUSec
> > TimeoutStartUSec=1min 30s
> > # systemctl daemon-reexec
> > # systemctl show mysql -p TimeoutStartUSec
> > TimeoutStartUSec=1min 30s
> >
> > What do I need to do to make this actually work?
> 
> Have you tried setting TimeoutStartSec rather than TimeoutStartUSec?
> Though I have to admit that I did not perform a web search but cheated
> by looking at the systemd.service(5) manpage, which mentions the former
> but not the latter.

https://bugzilla.redhat.com/show_bug.cgi?id=1018335
seems to lend support. What OP might be doing:
TimeoutStartUSec = desiredByOP

and then systemd comes along and does:
TimeoutStartSec set? No, so:
TimeoutStartSec = DefaultTimeoutStartSec
and then, for internal use, TimeoutStartUSec = TimeoutStartSec
trampling on the OP's setting.

Presumably the OP is running a new enough systemd for infinity
to be acceptable.

Cheers,
David.

Re: Encrypted containers & the Debian installer.

[David Wright]

On Tue 15 May 2018 at 23:05:10 (-0700), Diagonal Arg wrote:
> On my first tries with the Debian installer, I am struggling with the limited 
> resources for installing to encrypted disks.  I am using the same technique I 
> have used with Ubuntu, but failing at the last step:
> 
> I create my luks disk(s) before-hand, then run the installer.  I find I have 
> to anna-install cryptsetup-udeb, as there is no such choice in "Load 
> Installer Modules".  Dropping to a shell, opening the disk, and  re-detecting 
> hard drives allows me to carry out the installation (as long as there's a 
> filesystem in the mapped device), but on reboot I'm at an initramfs without 
> cryptsetup.  So I use a debian-live to pivot into the system to create a 
> crypttab.  I find I also have to install cryptsetup.  Then I run 
> update-initramfs.  Here is where I'm stuck.  The new initramfs still does not 
> include cryptsetup.  Why is it not recognizing the crypttab?

Are you not seeing the last line in this screen excerpt?





  ┌┤ [?] Load installer components from CD 
├┐   
  │ 
│   
  │ All components of the installer needed to complete the install will be 
loaded   │   
  │ automatically and are not listed here. Some other (optional) installer  
│   
  │ components are shown below. They are probably not necessary, but may be 
│   
  │ interesting to some users.  
│   
  │ 
│   
  │ Note that if you select a component that requires others, those components  
│   
  │ will also be loaded.
│   
  │ 
│   
  │ Installer components to load:   
│   
  │ 
│   
  │[ ] choose-mirror: Choose mirror to install from (menu item) 
 ↑  │   
  │[ ] crypto-dm-modules-4.9.0-2-686-di: devicemapper crypto module 
 ▮  │   


Cheers,
David.

Re: GPG error when trying to update Lenny

[Greg Wooledge]

On Wed, May 16, 2018 at 03:20:09PM +, Marie-Madeleine Gullibert wrote:
> Fetched 235kB in 0s (301kB/s)
> Reading package lists... Done
> W: GPG error: http://archive.debian.org lenny Release: The following 
> signatures were invalid: KEYEXPIRED 1520281423 KEYEXPIRED 1337087218
> W: GPG error: http://archive.debian.org lenny/updates Release: The following 
> signatures were invalid: KEYEXPIRED 1356982504
> W: GPG error: http://archive.debian.org lenny/volatile Release: The following 
> signatures were invalid: KEYEXPIRED 1358963195
> W: You may want to run apt-get update to correct these problems

The "W:" means it's just a warning, right?  Ignore it and move on?

Re: GPG error when trying to update Lenny

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, May 16, 2018 at 03:20:09PM +, Marie-Madeleine Gullibert wrote:
> Hello to all, 
> 
> I'm relatively new to Debian. I'm helping out a small organization that has a 
> library server installed on Debian to update their system. They run currently 
> on Debian lenny so I'm first trying to upgrade the Debian system, but I keep 
> running into a GPG error when I try to first update. I've tried many things 
> but none have worked so far, and would gladly welcome any suggestions. I do 
> have debian-archive-keyring installed (and up to date) and I've tried 
> retrieving my expired keys from a two different keyservers to no avail. 
> 
> Here's what happens (I'm running as root): 
> 
> localhost:~# apt-get update
> Get:1 http://archive.debian.org lenny Release.gpg [1034B]

Lenny is "archived": packages don't get updated anymore, so at
some point in time expired keys shouldn't be a surprise. I guess
you'll have to live with that warning (if you, for some reason,
have to stay with lenny: otherwise, an upgrade lenny->squeeze->
wheezy->jessie should be the way to go).

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlr8VsMACgkQBcgs9XrR2kYqzQCdEWnCmh+qvdOI/SLZfqqTv96x
2DcAn0il9ZcC4hXIhqYX5r5O+87vgQ3+
=ZaCs
-END PGP SIGNATURE-

setting up a drive automount in systemd?

[dep]

greetings.

i've tried my best to search the list archives for the answer to this and have 
not gotten the search function to deliver . . . anything.

here's the issue. i have one of the new "gemini" devices, a psion-like 
smartphone-pda-computer that runs android and linux. i'm of course running 
linux. the linux available for it is a derivative of stretch arm64. it uses 
systemd, my first encounter with that not-universally-loved arrangement.

the device has 64gb of onboard storage and a microSD slot, in which i've placed 
a 128gb microSD card formatted ext4. to reduce write wear on the device's 
internal memory, it's my hope to put /home or at least /[users] on the microSD 
card. this of course requires mounting it at boot.

i've been much of a week searching and i cannot find any way to configure this 
to automount in systemd. i do not even know if under systemd it must be mounted 
to a mountpoint or if it's handled at the /dev level. so what was once a 
trivial configuration has become a more complicated one, with the possibility 
of bricking the device -- which i'd just as soon not do.

can anyone here either give or point to clear and i hope simple instructions 
for configuring the card to mount at boot? alternately, is there 
systemd-friendly disk management software? the disk managers i'm familiar with 
do not seem to work with systemd.

thanks in advance.

dep

Sent with [ProtonMail](https://protonmail.com/) Secure Email. Because privacy 
matters.

running arecord via ssh

[Pierre Frenkiel]

hi,
I try to record some old vinyls with arecord, the output being
sent to my desktop via a radio transmitter/receiver couple.

On the desktop xterm window, its works perfectly, but if I run arecord via
a ssh connection:

1/ from an other computer:
  ssh mydesktop arecord_command
2/ in a ssh xterm window:
  ssh mydesktop
  arecord_command

I get an empty file

Is really arecord incompatible with ssh?

best regards,
--
Pierre Frenkiel

Problems installing AMD64 Debian

[Richard Owlett]

My first question, is a ThinkPad T510 having a Intel i5 processor 
capable of running it.


The netinst appeared to run.
I comes up.
But neither the standard 32 bit version of SeaMonkey nor a late beta of 
a 64bit version will launch.


The only know atypical choice was to not allow the installer to create a 
swap partition.

Re: lightdm (testing): Long waiting time after login

[Dominic Knight]

On Wed, 2018-05-16 at 14:53 +0200, Dino wrote:
> > Dino wrote:
> > > This is a multi-part message in MIME format.
> > > --D295C2A19D414A0F9C32AEE8
> > > Content-Type: multipart/alternative;
> > >   boundary="51A034E61483D85CC097E79C"
> > > 
> > > 
> > > --51A034E61483D85CC097E79C
> > > Content-Type: text/plain; charset=utf-8; format=flowed
> > > Content-Transfer-Encoding: 7bit
> > > 
> > > This time with attachment...
> > > 
> > > Am 16.05.2018 um 09:28 schrieb w...@hllmnn.de:
> > > > I just did a fresh install of testing with XFCE. After entering
> > > > the
> > > > login credentials the screen was black for 30-60 seconds before
> > > > the
> > > > desktop environment showed up. Assuming a bug in XFCE, I
> > > > performed
> > > > another fresh install with MATE, but a similar effect occured:
> > > > after
> > > > login the background image is shown for 30-60 seconds before
> > > > the
> > > > desktop is fully loaded.
> > > > 
> > > > A look into /var/log/lightdm/lightdm.log showed that the delay
> > > > happens
> > > > before VT is activated. The log file is attached.
> > > > 
> > > > Might this be a bug in lightdm or could a misconfiguragtion
> > > > from my
> > > > side cause this issue?
> > 
> > ...
> > > [+7.71s] DEBUG: Session pid=691: Running command
> > > /etc/X11/Xsession default
> > > [+7.71s] DEBUG: Creating shared data directory
> > > /var/lib/lightdm/data/USERNAME
> > > [+7.71s] DEBUG: Session pid=691: Logging to .xsession-errors
> > > [+40.89s] DEBUG: Activating VT 7
> > > [+40.89s] DEBUG: Activating login1 session 2
> > > [+40.89s] DEBUG: Seat seat0 changes active session to
> > > [+40.89s] DEBUG: Seat seat0 changes active session to 2
> > > [+40.89s] DEBUG: Session 2 is already active
> > 
> >what does .xsession-errors say?
> > 
> >what type of device are you installing to?
> > 
> >my recent installs with netinst for testing and having MATE
> > comes up ok (within a few seconds), but things may have changed
> > in packages.
> > 
> >does a stable netinst give same results?
> > 
> > 
> >songbird
> 
> .xsession-errors contains one warning (file is attached), but I
> don't 
> think that it causes the delay.
> 
> The device I'm installing to is an UDOO X86 
> (https://www.udoo.org/udoo-x86/). Basically, it's standard hardware
> with 
> an Intel CPU. I already had an installation of testing a few months
> ago 
> that didn't show this behaviour.
> 
> A stable netinst works just fine, the desktop is loaded almost 
> immediately. Hence, I assume a package changed recently is the
> reason 
> for this.

Maybe;
systemd-analyze critical-chain
&
systemd-analyze blame
will give a clue as to what is taking its time?

Dom.

Re: Problems installing AMD64 Debian

[Felix Miata]

Richard Owlett composed on 2018-05-16 12:15 (UTC-0500):

> My first question, is a ThinkPad T510 having a Intel i5 processor 
> capable of running it.

> The netinst appeared to run.
> I comes up.
> But neither the standard 32 bit version of SeaMonkey nor a late beta of 
> a 64bit version will launch.

> The only know atypical choice was to not allow the installer to create a 
> swap partition.

"Launch" how? If you "launch" it from a terminal window you can see error
messages giving clues to the failure(s).
-- 
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: Problems installing AMD64 Debian

[Brian]

On Wed 16 May 2018 at 12:15:05 -0500, Richard Owlett wrote:

> My first question, is a ThinkPad T510 having a Intel i5 processor capable of
> running it.

A number of positive search engine hits with "debian ThinkPad T510"
would inspire confidence,
> 
> The netinst appeared to run.
> I comes up.

A netinst either runs flawlessly or it doesn't. You indicate it does
its job and installs the OS.

> But neither the standard 32 bit version of SeaMonkey nor a late beta of a
> 64bit version will launch.

This is after the installation, of course. "Will not launch" is a bit
vague. There is bound to be someone who wants detail.

> The only know atypical choice was to not allow the installer to create a
> swap partition.

Of no consequence.

-- 
Brian.

Re: Problems installing AMD64 Debian

[Richard Owlett]

On 05/16/2018 01:01 PM, Felix Miata wrote:

Richard Owlett composed on 2018-05-16 12:15 (UTC-0500):


My first question, is a ThinkPad T510 having a Intel i5 processor
capable of running it.



The netinst appeared to run.
I comes up.
But neither the standard 32 bit version of SeaMonkey nor a late beta of
a 64bit version will launch.



The only know atypical choice was to not allow the installer to create a
swap partition.


"Launch" how? If you "launch" it from a terminal window you can see error
messages giving clues to the failure(s).



DUH ;/
Too used to just double clicking from Caja.
Evidently a missing dependency.

Error Message:


richard@debian64:~$ /home/richard/Downloads/seamonkey/seamonkey
XPCOMGlueLoad error for file /home/richard/Downloads/seamonkey/libxul.so:
/usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.23' not found 
(required by /home/richard/Downloads/seamonkey/libxul.so)
Couldn't load XPCOM.
richard@debian64:~$ 

Re: setting up a drive automount in systemd?

[Joe]

On Wed, 16 May 2018 12:25:22 -0400
dep  wrote:

> greetings.
> 
> i've tried my best to search the list archives for the answer to this
> and have not gotten the search function to deliver . . . anything.
> 
> here's the issue. i have one of the new "gemini" devices, a
> psion-like smartphone-pda-computer that runs android and linux. i'm
> of course running linux. the linux available for it is a derivative
> of stretch arm64. it uses systemd, my first encounter with that
> not-universally-loved arrangement.
> 
> the device has 64gb of onboard storage and a microSD slot, in which
> i've placed a 128gb microSD card formatted ext4. to reduce write wear
> on the device's internal memory, it's my hope to put /home or at
> least /[users] on the microSD card. this of course requires mounting
> it at boot.
> 
> i've been much of a week searching and i cannot find any way to
> configure this to automount in systemd. i do not even know if under
> systemd it must be mounted to a mountpoint or if it's handled at
> the /dev level. so what was once a trivial configuration has become a
> more complicated one, with the possibility of bricking the device --
> which i'd just as soon not do.
> 
> can anyone here either give or point to clear and i hope simple
> instructions for configuring the card to mount at boot? alternately,
> is there systemd-friendly disk management software? the disk managers
> i'm familiar with do not seem to work with systemd.
> 

Not what you want, but related, possibly it will help to make sense
of other documentation. I have network drives set to automount on first
use. Here is a typical /etc/fstab line:

///Media/mnt//Media cifs
noauto,x-systemd.automount,user,guest,noperm,dir_mode=0x777,file_mode=0x777,vers=1.0,rw

Note that without the 'noauto' it *will* automount on boot, which is
not what you normally want for network or removable drives, given that
the boot will hang if the drive is not found. I believe 'nofail'
instead would also prevent a boot hang, but I also don't want a dozen
possibly delayed mount processes holding up boot, I'm prepared to wait
until I need them. Note that most of the parameters are relevant to
cifs/samba mounts.

With no /etc/fstab entry, a removable drive when plugged in will by
default automount on first use. I don't recall that any manual
configuration was necessary for that to happen.

-- 
Joe

Re: setting up a drive automount in systemd?

[dep]

On May 16, 2018 2:35 PM, Joe  wrote:

> Not what you want, but related, possibly it will help to make sense
> 
> of other documentation. I have network drives set to automount on first
> 
> use. Here is a typical /etc/fstab line:
> 
> ///Media /mnt//Media cifs
> 
> noauto,x-systemd.automount,user,guest,noperm,dir_mode=0x777,file_mode=0x777,vers=1.0,rw
> 
> Note that without the 'noauto' it will automount on boot, which is
> 
> not what you normally want for network or removable drives, given that
> 
> the boot will hang if the drive is not found. I believe 'nofail'
> 
> instead would also prevent a boot hang, but I also don't want a dozen
> 
> possibly delayed mount processes holding up boot, I'm prepared to wait
> 
> until I need them. Note that most of the parameters are relevant to
> 
> cifs/samba mounts.
> 
> With no /etc/fstab entry, a removable drive when plugged in will by
> 
> default automount on first use. I don't recall that any manual
> 
> configuration was necessary for that to happen.

That's what initially puzzled me -- there is *no* /etc/fstab file at all, 
leading me to consider that it's possible that everything has changed. If I 
were to make an /etc/fstab with just the line I need for the drive, this would 
work with systemd?

Re: setting up a drive automount in systemd?

[john doe]

On 5/16/2018 6:25 PM, dep wrote:

greetings.

i've tried my best to search the list archives for the answer to this and have 
not gotten the search function to deliver . . . anything.

here's the issue. i have one of the new "gemini" devices, a psion-like 
smartphone-pda-computer that runs android and linux. i'm of course running linux. the 
linux available for it is a derivative of stretch arm64. it uses systemd, my first 
encounter with that not-universally-loved arrangement.

the device has 64gb of onboard storage and a microSD slot, in which i've placed 
a 128gb microSD card formatted ext4. to reduce write wear on the device's 
internal memory, it's my hope to put /home or at least /[users] on the microSD 
card. this of course requires mounting it at boot.

i've been much of a week searching and i cannot find any way to configure this 
to automount in systemd. i do not even know if under systemd it must be mounted 
to a mountpoint or if it's handled at the /dev level. so what was once a 
trivial configuration has become a more complicated one, with the possibility 
of bricking the device -- which i'd just as soon not do.

can anyone here either give or point to clear and i hope simple instructions 
for configuring the card to mount at boot? alternately, is there 
systemd-friendly disk management software? the disk managers i'm familiar with 
do not seem to work with systemd.

thanks in advance.



I might be missing something here but why not using the fstab file?

--
John Doe

Re: Problems installing AMD64 Debian

[Brian]

On Wed 16 May 2018 at 13:43:17 -0500, Richard Owlett wrote:

> On 05/16/2018 01:01 PM, Felix Miata wrote:
> > Richard Owlett composed on 2018-05-16 12:15 (UTC-0500):
> > 
> > > My first question, is a ThinkPad T510 having a Intel i5 processor
> > > capable of running it.
> > 
> > > The netinst appeared to run.
> > > I comes up.
> > > But neither the standard 32 bit version of SeaMonkey nor a late beta of
> > > a 64bit version will launch.
> > 
> > > The only know atypical choice was to not allow the installer to create a
> > > swap partition.
> > 
> > "Launch" how? If you "launch" it from a terminal window you can see error
> > messages giving clues to the failure(s).
> > 
> 
> DUH ;/
> Too used to just double clicking from Caja.
> Evidently a missing dependency.
> 
> Error Message:
> 
> > richard@debian64:~$ /home/richard/Downloads/seamonkey/seamonkey
> > XPCOMGlueLoad error for file /home/richard/Downloads/seamonkey/libxul.so:
> > /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.23' not 
> > found (required by /home/richard/Downloads/seamonkey/libxul.so)
> > Couldn't load XPCOM.
> > richard@debian64:~$

Ah, I see. seamonkey is not included on an amd64 Debian ISO. The user
has to install it from elsewhere and responders to your post have to
guess this is the situation. They suffer information underload.:)

-- 
Brian.

Re: setting up a drive automount in systemd?

[dep]

On Wed, May 16, 2018 at 2:44 PM, john doe  wrote:

> On 5/16/2018 6:25 PM, dep wrote: > greetings. > > i've tried my best to 
> search the list archives for the answer to this and have not gotten the 
> search function to deliver . . . anything. > > here's the issue. i have one 
> of the new "gemini" devices, a psion-like smartphone-pda-computer that runs 
> android and linux. i'm of course running linux. the linux available for it is 
> a derivative of stretch arm64. it uses systemd, my first encounter with that 
> not-universally-loved arrangement. > > the device has 64gb of onboard storage 
> and a microSD slot, in which i've placed a 128gb microSD card formatted ext4. 
> to reduce write wear on the device's internal memory, it's my hope to put 
> /home or at least /[users] on the microSD card. this of course requires 
> mounting it at boot. > > i've been much of a week searching and i cannot find 
> any way to configure this to automount in systemd. i do not even know if 
> under systemd it must be mounted to a mountpoint or if it's handled at the 
> /dev level. so what was once a trivial configuration has become a more 
> complicated one, with the possibility of bricking the device -- which i'd 
> just as soon not do. > > can anyone here either give or point to clear and i 
> hope simple instructions for configuring the card to mount at boot? 
> alternately, is there systemd-friendly disk management software? the disk 
> managers i'm familiar with do not seem to work with systemd. > > thanks in 
> advance. > I might be missing something here but why not using the fstab 
> file? -- John Doe

because there is no /etc/fstab.

dep

Sent with [ProtonMail](https://protonmail.com/) Secure Email. Because privacy 
matters.

Re: GPG error when trying to update Lenny

[john doe]

On 5/16/2018 5:20 PM, Marie-Madeleine Gullibert wrote:

Hello to all,

I'm relatively new to Debian. I'm helping out a small organization that has a 
library server installed on Debian to update their system. They run currently 
on Debian lenny so I'm first trying to upgrade the Debian system, but I keep 
running into a GPG error when I try to first update. I've tried many things but 
none have worked so far, and would gladly welcome any suggestions. I do have 
debian-archive-keyring installed (and up to date) and I've tried retrieving my 
expired keys from a two different keyservers to no avail.

Here's what happens (I'm running as root):

localhost:~# apt-get update
Get:1 http://archive.debian.org lenny Release.gpg [1034B]
Ign http://archive.debian.org lenny/main Translation-en_US
Get:2 http://archive.debian.org lenny/updates Release.gpg [836B]
Ign http://archive.debian.org lenny/updates/main Translation-en_US
Ign http://archive.debian.org lenny/updates/contrib Translation-en_US
Get:3 http://archive.debian.org lenny/volatile Release.gpg [481B]
Ign http://archive.debian.org lenny/volatile/main Translation-en_US
Hit http://archive.debian.org lenny Release
Hit http://archive.debian.org lenny/updates Release
Hit http://archive.debian.org lenny/volatile Release
Get:4 http://archive.debian.org lenny Release [99.6kB]
Get:5 http://archive.debian.org lenny/updates Release [92.4kB]
Ign http://archive.debian.org lenny Release
Get:6 http://archive.debian.org lenny/volatile Release [40.7kB]
Ign http://archive.debian.org lenny/updates Release
Ign http://archive.debian.org lenny/volatile Release
Ign http://archive.debian.org lenny/main Packages/DiffIndex
Ign http://archive.debian.org lenny/main Sources/DiffIndex
Ign http://archive.debian.org lenny/updates/main Packages/DiffIndex
Ign http://archive.debian.org lenny/updates/contrib Packages/DiffIndex
Ign http://archive.debian.org lenny/updates/main Sources/DiffIndex
Ign http://archive.debian.org lenny/updates/contrib Sources/DiffIndex
Ign http://archive.debian.org lenny/volatile/main Packages/DiffIndex
Ign http://archive.debian.org lenny/volatile/main Sources/DiffIndex
Hit http://archive.debian.org lenny/main Packages
Hit http://archive.debian.org lenny/main Sources
Hit http://archive.debian.org lenny/updates/main Packages
Hit http://archive.debian.org lenny/updates/contrib Packages
Hit http://archive.debian.org lenny/updates/main Sources
Hit http://archive.debian.org lenny/updates/contrib Sources
Hit http://archive.debian.org lenny/volatile/main Packages
Hit http://archive.debian.org lenny/volatile/main Sources
Fetched 235kB in 0s (301kB/s)
Reading package lists... Done
W: GPG error: http://archive.debian.org lenny Release: The following signatures 
were invalid: KEYEXPIRED 1520281423 KEYEXPIRED 1337087218
W: GPG error: http://archive.debian.org lenny/updates Release: The following 
signatures were invalid: KEYEXPIRED 1356982504
W: GPG error: http://archive.debian.org lenny/volatile Release: The following 
signatures were invalid: KEYEXPIRED 1358963195
W: You may want to run apt-get update to correct these problems



This is a rather old release of Debian! :)
By any chance don't you have an other box laying around that you could 
configure with Debian 9 and install all required packages?


The idea here would be to not do anything on the "working" box before 
you have an other box that could take over that role.


Alternatively you could try to refresh the keys but I'm not sure if that 
would work with the Debian's keys.


--
John Doe

Re: setting up a drive automount in systemd?

[john doe]

On 5/16/2018 9:04 PM, dep wrote:

On Wed, May 16, 2018 at 2:44 PM, john doe  wrote:


On 5/16/2018 6:25 PM, dep wrote: > greetings. > > i've tried my best to search the list archives for the answer to this 
and have not gotten the search function to deliver . . . anything. > > here's the issue. i have one of the new 
"gemini" devices, a psion-like smartphone-pda-computer that runs android and linux. i'm of course running linux. the 
linux available for it is a derivative of stretch arm64. it uses systemd, my first encounter with that not-universally-loved 
arrangement. > > the device has 64gb of onboard storage and a microSD slot, in which i've placed a 128gb microSD card 
formatted ext4. to reduce write wear on the device's internal memory, it's my hope to put /home or at least /[users] on the microSD 
card. this of course requires mounting it at boot. > > i've been much of a week searching and i cannot find any way to 
configure this to automount in systemd. i do not even know if under systemd it must be mounted to a mountpoint or if it's handled 
at the /dev level. so what was once a trivial configuration has become a more complicated one, with the possibility of bricking the 
device -- which i'd just as soon not do. > > can anyone here either give or point to clear and i hope simple instructions for 
configuring the card to mount at boot? alternately, is there systemd-friendly disk management software? the disk managers i'm 
familiar with do not seem to work with systemd. > > thanks in advance. > I might be missing something here but why not 
using the fstab file? -- John Doe


because there is no /etc/fstab.



1)  Fstab could be located somewhere else (find / -iname fstab -type f)
2)  What happens if you try to use /etc/fstab file?
3)  Anything in the log for a missing fstab file?
4)  Use a systemd service file to mount it at boot (Automatic mounting 
of additional volumes).


I'm on Stretch with systemd and a fstab file.

--
John Doe

Debian testing not receivng packages at least in gnome.

[Matthew]

Afternoon all.


A very strange problem that is very strange.  I have two debian machines 
both with the testing repo as the sources from which I am using.  One is 
using mate desktop and the other is using gnome.  I have the sources 
list pointing to the testing branch on both.  One the mate machinee 
updates the desktop without any problem, but the gnome system however 
does not.  Here is how my debian sorces list looks on my gnome system.  
I switch to the main server thinking that this might work, but no luck.  
I know that there were updates as my mate system was just updated.  Any 
ideas.  Now here is the sources list info.



#

# deb cdrom:[Debian GNU/Linux 9.4.0 _Stretch_ - Official amd64 NETINST 
20180310-11:21]/ stretch main


# deb cdrom:[Debian GNU/Linux 9.4.0 _Stretch_ - Official amd64 NETINST 
20180310-11:21]/ stretch main


deb http://deb.debian.org/debian/ testing main
deb-src http://deb.debian.org/debian/ testing main

# deb-src http://ftp.us.debian.org/debian/ testing-updates main


BTW the last 2 lines are commented in the file.


Matthew

Nvidia, BOINC and Steam

[Nicolas FRANCOIS]

Hi.

I've been working with a stable Debian for a few years now (three major
releases), with backports depots for a few tools I use regularly. I
need a proprietary Nvidia driver for essentially two things : Steam,
because I'm a Civ V gamer, and BOINC, because my computer is up 24h/day.

There was a backport update of the nvidia drivers a few weeks ago, I
tried to migrate. But then Steam wouldn't work anymore (32bits libglx,
or something like this, complaint). I ended up breaking everything
trying to get back to stable.

I finally was able to recover in console, erasing one by one the
backports packages (they cooperate to not let them be deinstalled,
those little bastards !!!)

Now, I have the stable nvidia kernel driver (375.82), but I've noticed
some BOINC apps complaining about not finding a GPU (Seti@Home, for
sure, and I haven't seen Primegrid works for a while...). Djezus, I
HAVE a GPU, it cost me enough (950, not the best one, but the most
powerful I was able to "sell" to my wife :-)

I don't know exactly what to do, if anyone could provide me with a
checklist of what to install to be able to make Steam AND BOINC work
with ANY Nvidia driver version, I would be so grateful...

Thanks for any help.

\bye

-- 

Nicolas FRANCOIS  |  /\ 
http://nicolas.francois.free.fr   | |__|
  X--/\\
We are the Micro$oft.   _\_V
Resistance is futile.   
You will be assimilated. darthvader penguin


pgpEjTJ1cCfvv.pgp
Description: Signature digitale OpenPGP

Re: Debian testing not receivng packages at least in gnome.

[Cindy-Sue Causey]

On 5/16/18, Matthew  wrote:
> Afternoon all.
>
>
> A very strange problem that is very strange.  I have two debian machines
> both with the testing repo as the sources from which I am using.  One is
> using mate desktop and the other is using gnome.  I have the sources
> list pointing to the testing branch on both.  One the mate machinee
> updates the desktop without any problem, but the gnome system however
> does not.  Here is how my debian sorces list looks on my gnome system.
> I switch to the main server thinking that this might work, but no luck.
> I know that there were updates as my mate system was just updated.  Any
> ideas.  Now here is the sources list info.
>
>
> #
>
> # deb cdrom:[Debian GNU/Linux 9.4.0 _Stretch_ - Official amd64 NETINST
> 20180310-11:21]/ stretch main
>
> # deb cdrom:[Debian GNU/Linux 9.4.0 _Stretch_ - Official amd64 NETINST
> 20180310-11:21]/ stretch main
>
> deb http://deb.debian.org/debian/ testing main
> deb-src http://deb.debian.org/debian/ testing main
>
> # deb-src http://ftp.us.debian.org/debian/ testing-updates main
>
>
> BTW the last 2 lines are commented in the file.


Are you saying that you see something like this, like *mine*, when you
try to update:

0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Or are you saying something else, e.g. like maybe it won't complete
the earlier "apt-get update" step (or however else you update your
setup's package manager)?

I'm just asking because mine has remained at the above for MANY
months. Every so many weeks, one outside browser needs updated, but
that's it.

I consciously thought about it and just thought Stable was
phenomenally stable. At the same time I'm on security listservs that
keep sending out announcements for familiar packages. I've found it
hard to believe that mine hasn't needed *anything* updated to
date..

Your inquiry just retriggered an *oops* forgotten minor detail that
there's a security related line that can be added. That would be some
personalized main v. contrib v. non-free tweak of:

deb http://security.debian.org/debian-security/ stretch/updates main

Oh, have mercy. I just added that then "apt-get update"/"apt-get
upgrade". Went pretty quick, but, ummm...

"102 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 429 MB of archives.
After this operation, 10.5 MB disk space will be freed."

Via dialup.

At that rate, I might as well debootstrap again just for funnsies to
sweep out incidental cobwebs. Comme ci comme ça, six of one, half a
dozen of another, yada-yada.. :D

My meandering is partially k/t...

1) https://unix.stackexchange.com/questions/371865/debian-9-sources-list

2) https://www.howtoforge.com/using-old-debian-versions-in-your-sources.list

And ultimately...

3) https://wiki.debian.org/SourcesList

PS I can see where that missing "debian-security" line would be, nay,
apparently *is* why there have been no updates on *my* end with a
one-liner sources.list, BUT...

I'm not cognitively grasping why resource protecting security updates
to software would not have naturally been reflected all along even
with that one-liner sources.list file. I would have thought it was all
in the same single repository bucket that our packagers pluck from
regularly... :)

My faded memory is that this came up here on Debian-User, and there
*is* some rational thought process as to why that doesn't naturally
happen...

I think... ? Maybe.. ? Or not..? :)

Cindy =)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with duct tape *

Re: Debian testing not receivng packages at least in gnome.

[Joe]

On Wed, 16 May 2018 16:53:57 -0400
Cindy-Sue Causey  wrote:

> On 5/16/18, Matthew  wrote:
> > Afternoon all.
> >
> >
> > A very strange problem that is very strange.  I have two debian
> > machines both with the testing repo as the sources from which I am
> > using.  One is using mate desktop and the other is using gnome.  I
> > have the sources list pointing to the testing branch on both.  One
> > the mate machinee updates the desktop without any problem, but the
> > gnome system however does not.  Here is how my debian sorces list
> > looks on my gnome system. I switch to the main server thinking that
> > this might work, but no luck. I know that there were updates as my
> > mate system was just updated.  Any ideas.  Now here is the sources
> > list info.
> >
> >
> > #
> >
> > # deb cdrom:[Debian GNU/Linux 9.4.0 _Stretch_ - Official amd64
> > NETINST 20180310-11:21]/ stretch main
> >
> > # deb cdrom:[Debian GNU/Linux 9.4.0 _Stretch_ - Official amd64
> > NETINST 20180310-11:21]/ stretch main
> >
> > deb http://deb.debian.org/debian/ testing main
> > deb-src http://deb.debian.org/debian/ testing main
> >
> > # deb-src http://ftp.us.debian.org/debian/ testing-updates main
> >
> >
> > BTW the last 2 lines are commented in the file.  
> 
> 
> Are you saying that you see something like this, like *mine*, when you
> try to update:
> 
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> 

Thing is, he's not on Stable. Sid has been getting bucket-loads of
updates every day, as usual, and a fair proportion of that should make
it to Testing fairly quickly.

To the OP: how are you making updates? I use upgrade-system, which
works most of the time. When it wants to pull stupid amounts of stuff
out, I move to Synaptic and see how much I can make work.

In your case, you might want to try upgrading using apt-get or
aptitude, and report the messages from the two machines. If you are
using an upgrade method which is part of the desktop environment, there
might well be different behaviour.

-- 
Joe

Re: Nvidia, BOINC and Steam

[Dominic Knight]

On Wed, 2018-05-16 at 22:46 +0200, Nicolas FRANCOIS wrote:
> Hi.
> 
> I've been working with a stable Debian for a few years now (three
> major
> releases), with backports depots for a few tools I use regularly. I
> need a proprietary Nvidia driver for essentially two things : Steam,
> because I'm a Civ V gamer, and BOINC, because my computer is up
> 24h/day.
> 
> There was a backport update of the nvidia drivers a few weeks ago, I
> tried to migrate. But then Steam wouldn't work anymore (32bits
> libglx,
> or something like this, complaint). I ended up breaking everything
> trying to get back to stable.
> 
> I finally was able to recover in console, erasing one by one the
> backports packages (they cooperate to not let them be deinstalled,
> those little bastards !!!)
> 
> Now, I have the stable nvidia kernel driver (375.82), but I've
> noticed
> some BOINC apps complaining about not finding a GPU (Seti@Home, for
> sure, and I haven't seen Primegrid works for a while...). Djezus, I
> HAVE a GPU, it cost me enough (950, not the best one, but the most
> powerful I was able to "sell" to my wife :-)
> 
> I don't know exactly what to do, if anyone could provide me with a
> checklist of what to install to be able to make Steam AND BOINC work
> with ANY Nvidia driver version, I would be so grateful...
> 
> Thanks for any help.
> 
> \bye
> 
On Buster as no 32 bit available, presumably also for Stretch.
Only way I found to get Steam working well was via flatpak.
as root or sudo,

apt-get install flatpak

then as user 

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/fla
thub.flatpakrepo

flatpak install flathub com.valvesoftware.Steam

flatpak run com.valvesoftware.Steam


no idea about BOINC

Re: UEFI/"BIOS" booting

[Pascal Hambourg]

Le 16/05/2018 à 00:10, Pascal Hambourg a écrit :

Le 15/05/2018 à 08:51, Thomas Schmitt a écrit :


Summary:
- Boot flag on MBR partition of type 0xEE is bad on several EFI
   implementations.
- No MBR partition with boot flag is bad on some very few BIOS
   implementations.


Not so few in my experience.


- Compromise is to set the boot flag on a dummy partition of type 0x00.
   This is barely UEFI-compliant because the specs say that a 
partition of

   type 0x00 shall be regarded as non-existent.


I never thought about this. It may be a workaround with my old UEFI 
motherboard. Thanks for the tip, I will try it and report.


The trick indeed worked with my old motherboard ! Good to know, thanks.

However there are some caveats :
- I had to use the old fdisk version from Wheezy because newer versions 
and other partition editors would not allow to set the boot flag on an 
empty partition entry.
- parted silently erased the flag when I used it to edit the GPT table. 
I expected it, because parted had already reset a hybrid MBR I had set 
up with gdisk to a standard protective MBR.

Re: lightdm (testing): Long waiting time after login

[Ben Caradoc-Davies]

On 16/05/18 19:28, w...@hllmnn.de wrote:

I just did a fresh install of testing with XFCE. After entering the login
credentials the screen was black for 30-60 seconds before the desktop
environment showed up. Assuming a bug in XFCE, I performed another fresh install
with MATE, but a similar effect occured: after login the background image is
shown for 30-60 seconds before the desktop is fully loaded.


What happens if you wiggle your mouse or provide keyboard activity while 
waiting? For example, if you wiggle your mouse vigorously for two 
seconds or press the Alt key 20 times? Does the wait end sooner?


In Linux 4.16, the getrandom system call (without the GRND_NONBLOCK 
flag) blocks until sufficient entropy is available in the pool. This is 
the documented behaviour, and Linux 4.16 now enforces it to fix 
CVE-2018-1108. This has caught out several services that try to use 
getrandom (without the GRND_NONBLOCK flag) at early boot, including 
plymouth (via fontconfig) and gdm3. What you see might have the same 
cause. For details of my investigation, see:

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

Wiggling your mouse or providing keyboard activity adds entropy to the 
pool. If this reduces the waiting time, you might be affected by the 
same bug.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Re: running arecord via ssh

[David Margerison]

On 17 May 2018 at 03:10, Pierre Frenkiel  wrote:
> hi,
> I try to record some old vinyls with arecord, the output being
> sent to my desktop via a radio transmitter/receiver couple.
>
> On the desktop xterm window, its works perfectly, but if I run arecord via
> a ssh connection:
>
> 1/ from an other computer:
>   ssh mydesktop arecord_command
> 2/ in a ssh xterm window:
>   ssh mydesktop
>   arecord_command
>
> I get an empty file
>
> Is really arecord incompatible with ssh?

It might be related to this:
http://mywiki.wooledge.org/BashFAQ/096

But no-one can know, because you wrote "arecord_command"
instead of showing what you are actually doing.

"I'm running a command that fails, but I'm not going to
tell you what it is."  is not the best way to generate
helpful replies.

Details matter. Do not ever deliberately omit details.
unless you *know* they are not relevant.

Re: "pre-treating" documents from certain remote URLs before a web browser renders them

[davidson]

On Tue, 15 May 2018, davidson wrote:


I have a problem: The more frequently I browse a web site, the more I
notice all the things I hate about its web pages.

And I seem to have a partial solution to this problem: I can make XSLT
stylesheets[1] that will transform a web page A, as received from a
remote site, into a XHTML document B that better suits my purposes.[2]
I find it entertaining to make these, so I would like to figure out
how to incorporate them into a solution to the problem above.

But at the moment I do not know a good solution to the rest of the
problem, namely how to incorporate the application of stylesheets (and
preliminary preprocessing) into the web browsing activity.


[snip]


I would appreciate any suggestions, experiences (bad or good) along
these lines, etc.


I would like to thank everybody who took some time to reply with
suggestions and experience. So, thanks!

I will experiment with privoxy first, but I've taken note of the clues
and hints about alternatives too.

Grateful for the help.

Re: "pre-treating" documents from certain remote URLs before a web browser renders them

[Kushal Kumaran]

davidson  writes:

> On Tue, 15 May 2018, davidson wrote:
>
>> I have a problem: The more frequently I browse a web site, the more I
>> notice all the things I hate about its web pages.
>>
>> And I seem to have a partial solution to this problem: I can make XSLT
>> stylesheets[1] that will transform a web page A, as received from a
>> remote site, into a XHTML document B that better suits my purposes.[2]
>> I find it entertaining to make these, so I would like to figure out
>> how to incorporate them into a solution to the problem above.
>>
>> But at the moment I do not know a good solution to the rest of the
>> problem, namely how to incorporate the application of stylesheets (and
>> preliminary preprocessing) into the web browsing activity.
>
> [snip]
>
>> I would appreciate any suggestions, experiences (bad or good) along
>> these lines, etc.
>
> I would like to thank everybody who took some time to reply with
> suggestions and experience. So, thanks!
>
> I will experiment with privoxy first, but I've taken note of the clues
> and hints about alternatives too.
>
> Grateful for the help.

You should note that HTTP-proxy based systems will not be able to do any
inspection or modification of traffic for sites using HTTPS.
Browser-based systems like greasemonkey work better for that.  Since you
mentioned xslt, there is someone at [1] mangling web pages using xslt
with a greasemonkey script that you could use as inspiration.

[1] 
https://stackoverflow.com/questions/17998446/how-to-transform-an-xml-file-with-xslt-using-a-greasemonkey-script

-- 
regards,
kushal

Re: "pre-treating" documents from certain remote URLs before a web browser renders them

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, May 16, 2018 at 07:35:51PM -0700, Kushal Kumaran wrote:

[...]

> You should note that HTTP-proxy based systems will not be able to do any
> inspection or modification of traffic for sites using HTTPS.

This is true... and then it's not :-)

If your proxy terminates the HTTPS connection, effectively doing a
"man-in-the-middle" (but controlled by you), it can: most probably
you'd have to fool your browser by offering it a HTTPS connection
from the proxy, and by installing a trusted root certificate you
create yourself. Basically what the proxy in your $CORPORATION does
all of the time.

I don't know whether privoxy or squid can do that (I'd love to know,
mind you, but days are so short).

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlr9JeAACgkQBcgs9XrR2kZlfgCfUj93U5VfwlbzO6HPxLCjQIIP
a20AnjQmH9FHDdVbIujYUJTKE+OTqkYJ
=Lits
-END PGP SIGNATURE-