Re: Suspicious output during apt update

[Anders Andersson]

On Wed, May 13, 2020 at 8:05 AM Ihor Antonov  wrote:
>
> Today during apt update I got a very strange error message (below)
> Running apt udpate did not seem to reproduce the issue.
>
> Does anyone know what is this? And why does it tell "get haircut" ?
>
> 
> $ sudo apt update
> [sudo] password for ngor:
>
> ...
>
> Fetched 14.9 MB in 4s (3,979 kB/s)
> Entity: line 4: parser error : xmlParseEntityRef: no name
> e original message barList of languages in a config file instead 
> iso-codesFind &
>   
>  ^
> Entity: line 8: parser error : EntityRef: expecting ';'
> - get haircut @s 24 @r d &i 14 @o r
>^
> Entity: line 11: parser error : EntityRef: expecting ';'
> @r y &i 4 &M 11 &m 2, 3, 4, 5, 6, 7, 8 &w TU
>^
> Entity: line 11: parser error : EntityRef: expecting ';'
> @r y &i 4 &M 11 &m 2, 3, 4, 5, 6, 7, 8 &w TU
> ^
> Entity: line 11: parser error : EntityRef: expecting ';'
> @r y &i 4 &M 11 &m 2, 3, 4, 5, 6, 7, 8 &w TU
>   ^
> Entity: line 11: parser error : EntityRef: expecting ';'
> @r y &i 4 &M 11 &m 2, 3, 4, 5, 6, 7, 8 &w TU
>  ^
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> 12 packages can be upgraded. Run 'apt list --upgradable' to see them.


Don't know what it is but I got exactly the same thing. I just ran
update again and since it didn't occur again, I forgot all about it. I
assumed it had to do with me running a testing distribution. Didn't
happen on the debian stable box that I just tried.

Suspicious output during apt update

[Ihor Antonov]

Today during apt update I got a very strange error message (below)
Running apt udpate did not seem to reproduce the issue.

Does anyone know what is this? And why does it tell "get haircut" ?


$ sudo apt update   

  
[sudo] password for ngor:

...

Fetched 14.9 MB in 4s (3,979 kB/s)
Entity: line 4: parser error : xmlParseEntityRef: no name
e original message barList of languages in a config file instead iso-codesFind &
   ^
Entity: line 8: parser error : EntityRef: expecting ';'
- get haircut @s 24 @r d &i 14 @o r
   ^
Entity: line 11: parser error : EntityRef: expecting ';'
@r y &i 4 &M 11 &m 2, 3, 4, 5, 6, 7, 8 &w TU
   ^
Entity: line 11: parser error : EntityRef: expecting ';'
@r y &i 4 &M 11 &m 2, 3, 4, 5, 6, 7, 8 &w TU
^
Entity: line 11: parser error : EntityRef: expecting ';'
@r y &i 4 &M 11 &m 2, 3, 4, 5, 6, 7, 8 &w TU
  ^
Entity: line 11: parser error : EntityRef: expecting ';'
@r y &i 4 &M 11 &m 2, 3, 4, 5, 6, 7, 8 &w TU
 ^
Reading package lists... Done
Building dependency tree
Reading state information... Done
12 packages can be upgraded. Run 'apt list --upgradable' to see them.

-- 
Ihor Antonov

signature.asc
Description: This is a digitally signed message part.

Re: Smallest Usable EFI Partition?

[Sven Hartge]

Rick Thomas  wrote:
> On Tue, May 12, 2020, at 3:37 PM, Andrea Borgia wrote:
>> Il 13/05/20 00:21, Patrick Bartek ha scritto:

>> > I can't find anything definitive on this question.  Some say, 100MB
>> > is fine; others 215 or 550 is a safe choice.  It all seems to be
>> > just opinions.

>> I had the same doubts about a year ago and went with the
>> recommendation of a larger partition, about 500MB... of which only 6%
>> is used.  My office laptop with Windows10 has something in the region
>> of 100MB but it is not dualboot.  Debian uses about 6MB, MS about
>> 26MB, plus a couple of megs for boot.  If space is really tight you
>> might want to stick with 100MB in total.

> One thing to keep in mind is that, when the contents are being
> updated, the EFI partition and the /boot partition if you have one,
> will need space for two (or even more) copies of stuff.  So don't be
> too stingy!

Also Firmware/BIOS update are often put onto there nowadays to be
installed on next reboot.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

Re: Question on Unattended Upgrades

[Gene Heskett]

On Tuesday 12 May 2020 22:49:48 Tom Dial wrote:

> On 5/12/20 09:05, Gene Heskett wrote:
> > On Tuesday 12 May 2020 10:30:04 Celejar wrote:
> >> On Tue, 12 May 2020 06:03:52 -0400
> >>
> >> Gene Heskett  wrote:
> >>> On Tuesday 12 May 2020 05:07:04 l0f...@tuta.io wrote:
>  Hi,
> 
>  12 mai 2020 à 08:22 de keifer@gmail.com:
> > Is there a way to configure it to automatically restart when a
> > package that needs to be restarted is upgraded?
> 
>  I think 'Unattended-Upgrade::Automatic-Reboot "true";' should do
>  it in /etc/apt/apt.conf.d/50unattended-upgrades. If I were you, I
>  would check /etc/apt/apt.conf.d/20auto-upgrades as well because
>  those are the 2 most important configuration files for
>  unattended-upgrades.
> 
>  Best regards,
>  l0f4r0
> >>>
> >>> I can see a major disaster in the making, what if that reboot was
> >>> commanded in the middle of your nightly backup run, leaving your
> >>> backup program with a totally bogus database it cannot recover
> >>> from?
> >>
> >> That would be unfortunate - but surely a serious backup program
> >> would be designed to be robust enough that ending up "with a
> >> totally bogus database it cannot recover from" should never happen?
> >> What if you have some sort of system crash during a backup? Do you
> >> have a specific backup system in mind?
> >
> > You are trying to justify an automatic reboot, very bad idea.
> > Granted, most such would be ok, and will leave a requester popup to
> > advise the admin, doing its normal routine in the meantime.
> >
> > I happen to use amanda to backup 5 machines here, but any backup
> > suite that maintains a recovery database is going to be in deep
> > doodoo if it gets rebooted in the middle of a backup.  I probably do
> > better than most but a worst case scenario here if everything in
> > place works, would only lose me that days data because I do keep
> > separate copies of that data. But 60 days of that is 33GB, the
> > biggest single entry in my nearly 70 items long list.
>
> I don't know about Amanda other than understanding it to be a
> commercial quality backup system. In my working days as an
> administrator, my organization used HP Data Protector (now Micro
> Focus). As I recall, it had a proprietary transactional database that
> should have been up to date as of the last successfully completed file
> backups before a crash. It also, at least in our usage, backed up its
> database as the first action in a cycle, so in the worst case,
> reloading the database and rerunning the faulted backup would restore
> synchronization of the database and data. And if all else failed, I
> think there were procedures for rebuilding the database from the
> tapes. I wonder if Amanda does not provide similar features.
>
> We also did not do automatic updates, there being organizational
> requirements to test configuration changes before installing them on
> production systems.
>
> I don't consider automatic updates a very good idea, although out of
> laziness in retirement I allow automatic security updates. Unplanned
> reboots seem an even worse idea inasmuch as they occasionally will
> either fail or affect system function. (Updating without rebooting
> also may do that, of course).
>
> >>> Frankly the update shouldn't be allowed if your backup is actually
> >>> running.  So it might be safer to schedule the update and reboot
> >>> if needed before the backup starts.  That means one cron driven
> >>> script does it all in the sequence desired.
>
> With respect, I would run the backup first and schedule upgrades and
> possible reboots to follow, and perhaps depend on success of, the
> backup.
>
> Regards,
> Tom Dial
>
We are in violent agreement on that. I've never done an "automatic" 
upgrade, although apt does do a update to keep its database as to whats 
available automaticly.  The only fault with the list --upgradeable 
output is that it does not filter out what is pinned, which on the other 
4 machines here, is the kernel and its libs because its a special 
realtime built kernel for running cnc machinery.  So they don't often 
get rebooted unless something has obviously screwed the moose. X related 
stuff for instance often qualifies.  Although x development's pace has 
slowed, the gui's it makes possible hasn't.

As far as amanda's database is concerned, until the backup has been done, 
that database is effectively yesterdays, so I wrote a wrapper that 
appends that now up to date database to the just completed backup so the 
database in THAT backup is up to date.  Gives me a little more peace of 
mind.

Thanks, stay well and safe now.

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Question on Unattended Upgrades

[Keifer Bly]

I am not backing this machine up to a physical drive, it is a VPS, so being
hosted in the cloud and all. We are not dealing with databases, but just
pushing traffic between nodes, etc. They strongly advise be running both
the most secure version of the OS and their software at all times, that's
why I am wanting to update them both automatically. Thanks very much.
--Keifer


On Tue, May 12, 2020 at 8:06 PM Tom Dial  wrote:

>
>
> On 5/12/20 09:05, Gene Heskett wrote:
> > On Tuesday 12 May 2020 10:30:04 Celejar wrote:
> >
> >> On Tue, 12 May 2020 06:03:52 -0400
> >>
> >> Gene Heskett  wrote:
> >>> On Tuesday 12 May 2020 05:07:04 l0f...@tuta.io wrote:
>  Hi,
> 
>  12 mai 2020 à 08:22 de keifer@gmail.com:
> > Is there a way to configure it to automatically restart when a
> > package that needs to be restarted is upgraded?
> 
>  I think 'Unattended-Upgrade::Automatic-Reboot "true";' should do
>  it in /etc/apt/apt.conf.d/50unattended-upgrades. If I were you, I
>  would check /etc/apt/apt.conf.d/20auto-upgrades as well because
>  those are the 2 most important configuration files for
>  unattended-upgrades.
> 
>  Best regards,
>  l0f4r0
> >>>
> >>> I can see a major disaster in the making, what if that reboot was
> >>> commanded in the middle of your nightly backup run, leaving your
> >>> backup program with a totally bogus database it cannot recover from?
> >>
> >> That would be unfortunate - but surely a serious backup program would
> >> be designed to be robust enough that ending up "with a totally bogus
> >> database it cannot recover from" should never happen? What if you
> >> have some sort of system crash during a backup? Do you have a specific
> >> backup system in mind?
> >
> > You are trying to justify an automatic reboot, very bad idea. Granted,
> > most such would be ok, and will leave a requester popup to advise the
> > admin, doing its normal routine in the meantime.
> >
> > I happen to use amanda to backup 5 machines here, but any backup suite
> > that maintains a recovery database is going to be in deep doodoo if it
> > gets rebooted in the middle of a backup.  I probably do better than most
> > but a worst case scenario here if everything in place works, would only
> > lose me that days data because I do keep separate copies of that data.
> > But 60 days of that is 33GB, the biggest single entry in my nearly 70
> > items long list.
> >
>
> I don't know about Amanda other than understanding it to be a commercial
> quality backup system. In my working days as an administrator, my
> organization used HP Data Protector (now Micro Focus). As I recall, it
> had a proprietary transactional database that should have been up to
> date as of the last successfully completed file backups before a crash.
> It also, at least in our usage, backed up its database as the first
> action in a cycle, so in the worst case, reloading the database and
> rerunning the faulted backup would restore synchronization of the
> database and data. And if all else failed, I think there were procedures
> for rebuilding the database from the tapes. I wonder if Amanda does not
> provide similar features.
>
> We also did not do automatic updates, there being organizational
> requirements to test configuration changes before installing them on
> production systems.
>
> I don't consider automatic updates a very good idea, although out of
> laziness in retirement I allow automatic security updates. Unplanned
> reboots seem an even worse idea inasmuch as they occasionally will
> either fail or affect system function. (Updating without rebooting also
> may do that, of course).
>
> >>> Frankly the update shouldn't be allowed if your backup is actually
> >>> running.  So it might be safer to schedule the update and reboot if
> >>> needed before the backup starts.  That means one cron driven script
> >>> does it all in the sequence desired.
>
> With respect, I would run the backup first and schedule upgrades and
> possible reboots to follow, and perhaps depend on success of, the backup.
>
> Regards,
> Tom Dial
>
> >
> > Cheers, Gene Heskett
> >
>
>

Re: How to debug a vnc issue in Debian 10?

[Yuwen Dai]

Le mer. 13 mai 2020 à 09:40, Yuwen Dai  a écrit :

> Dear all,
>
> I setup a vnc server in Debian 10 and connect to the server by using vnc
> client,   the desktop shows, but I cannot launch any application.  There's
> no error message.   It looks like a privilege issue.  This is what I did:
>
>
> I found the applications do run,  but show up on the desktop of the host
> that vncserver runs!  Do you have any advice on what happened?
>
> Best regards,
Yuwen

Re: Question on Unattended Upgrades

[Tom Dial]

On 5/12/20 09:05, Gene Heskett wrote:
> On Tuesday 12 May 2020 10:30:04 Celejar wrote:
> 
>> On Tue, 12 May 2020 06:03:52 -0400
>>
>> Gene Heskett  wrote:
>>> On Tuesday 12 May 2020 05:07:04 l0f...@tuta.io wrote:
 Hi,

 12 mai 2020 à 08:22 de keifer@gmail.com:
> Is there a way to configure it to automatically restart when a
> package that needs to be restarted is upgraded?

 I think 'Unattended-Upgrade::Automatic-Reboot "true";' should do
 it in /etc/apt/apt.conf.d/50unattended-upgrades. If I were you, I
 would check /etc/apt/apt.conf.d/20auto-upgrades as well because
 those are the 2 most important configuration files for
 unattended-upgrades.

 Best regards,
 l0f4r0
>>>
>>> I can see a major disaster in the making, what if that reboot was
>>> commanded in the middle of your nightly backup run, leaving your
>>> backup program with a totally bogus database it cannot recover from?
>>
>> That would be unfortunate - but surely a serious backup program would
>> be designed to be robust enough that ending up "with a totally bogus
>> database it cannot recover from" should never happen? What if you
>> have some sort of system crash during a backup? Do you have a specific
>> backup system in mind?
> 
> You are trying to justify an automatic reboot, very bad idea. Granted, 
> most such would be ok, and will leave a requester popup to advise the 
> admin, doing its normal routine in the meantime.
> 
> I happen to use amanda to backup 5 machines here, but any backup suite 
> that maintains a recovery database is going to be in deep doodoo if it 
> gets rebooted in the middle of a backup.  I probably do better than most 
> but a worst case scenario here if everything in place works, would only 
> lose me that days data because I do keep separate copies of that data. 
> But 60 days of that is 33GB, the biggest single entry in my nearly 70 
> items long list.
> 

I don't know about Amanda other than understanding it to be a commercial
quality backup system. In my working days as an administrator, my
organization used HP Data Protector (now Micro Focus). As I recall, it
had a proprietary transactional database that should have been up to
date as of the last successfully completed file backups before a crash.
It also, at least in our usage, backed up its database as the first
action in a cycle, so in the worst case, reloading the database and
rerunning the faulted backup would restore synchronization of the
database and data. And if all else failed, I think there were procedures
for rebuilding the database from the tapes. I wonder if Amanda does not
provide similar features.

We also did not do automatic updates, there being organizational
requirements to test configuration changes before installing them on
production systems.

I don't consider automatic updates a very good idea, although out of
laziness in retirement I allow automatic security updates. Unplanned
reboots seem an even worse idea inasmuch as they occasionally will
either fail or affect system function. (Updating without rebooting also
may do that, of course).

>>> Frankly the update shouldn't be allowed if your backup is actually
>>> running.  So it might be safer to schedule the update and reboot if
>>> needed before the backup starts.  That means one cron driven script
>>> does it all in the sequence desired.

With respect, I would run the backup first and schedule upgrades and
possible reboots to follow, and perhaps depend on success of, the backup.

Regards,
Tom Dial

> 
> Cheers, Gene Heskett
> 

How to debug a vnc issue in Debian 10?

[Yuwen Dai]

Dear all,

I setup a vnc server in Debian 10 and connect to the server by using vnc
client,   the desktop shows, but I cannot launch any application.  There's
no error message.   It looks like a privilege issue.  This is what I did:

sudo apt install xfce4 xfce4-goodies gnome-icon-theme tightvncserver -y
vncpasswd
create my ./vnc/xstartup like this:

#! /bin/sh
exec /usr/bin/xfce4-session &

then run
 vncserver :1   -localhost no -verbose

in the client host, run
vncviewer :1

Are there any log files I can view to the debug this issue?   Thanks in
advance.

Best regards,
Yuwen

Re: Question on Unattended Upgrades

[Keifer Bly]

Right, so according to i0f...@tutra.io's advice, I changed the line "
 'Unattended-Upgrade::Automatic-Reboot "false" to
'Unattended-Upgrade::Automatic-Reboot
"true" in   /etc/apt/apt.conf.d/50unattended-upgrades. Upon checking
 /etc/apt/apt.conf.d/20auto-upgrades I see the lines:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

What I am doing is running a small web server via a Debian Linux VPS, which
I am trying to use Unattended Upgrades to keep the software for this web
server and he OS Kernel up to date automatically. Based on what I see it
looks like it is working. Will this restart the OS and all processes I have
to restart via Chron automatically?  Thx.




--Keifer



Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Tue, May 12, 2020 at 2:07 AM  wrote:

> Hi,
>
> 12 mai 2020 à 08:22 de keifer@gmail.com:
>
> > Is there a way to configure it to automatically restart when a package
> that needs to be restarted is upgraded?
> >
> I think 'Unattended-Upgrade::Automatic-Reboot "true";' should do it
> in /etc/apt/apt.conf.d/50unattended-upgrades.
> If I were you, I would check /etc/apt/apt.conf.d/20auto-upgrades as well
> because those are the 2 most important configuration files for
> unattended-upgrades.
>
> Best regards,
> l0f4r0
>
>

Re: Smallest Usable EFI Partition?

[Rick Thomas]

On Tue, May 12, 2020, at 3:37 PM, Andrea Borgia wrote:
> Il 13/05/20 00:21, Patrick Bartek ha scritto:
> > I can't find anything definitive on this question.  Some say, 100MB is
> > fine; others 215 or 550 is a safe choice.  It all seems to be just
> > opinions.
> I had the same doubts about a year ago and went with the recommendation 
> of a larger partition, about 500MB... of which only 6% is used.
> My office laptop with Windows10 has something in the region of 100MB but 
> it is not dualboot.
> Debian uses about 6MB, MS about 26MB, plus a couple of megs for boot.
> If space is really tight you might want to stick with 100MB in total.

One thing to keep in mind is that, when the contents are being updated, the EFI 
partition and the /boot partition if you have one, will need space for two (or 
even more) copies of stuff.  So don't be too stingy!

Stay well, stay safe!
Rick

Re: Suggestion on hardware issue?

[David Christensen]

On 2020-05-12 08:04, Yvan Masson wrote:

Le 12/05/2020 à 03:37, David Christensen a écrit :

On 2020-05-11 10:28, Yvan Masson wrote:



Was the memory in your computer installed by Acer?

I believe so.


Okay.



Have you removed or inserted any memory modules?

Not before the issue arose.


Okay.



Do you use static safe tools and work practices?

In this case I only used my hands, and touched grounded metal before.
AIUI microelectronics are now so small that an electrostatic discharge 
too small for people to notice may still be large enough to damage the 
electronics.




What is the model/ part number of your computer?

I can not tell now as I won't have access to the computer before two days.


Okay.  Please post the information when available.



How many memory slots does the computer have?

1


Okay.


For each slot, what is the manufacturer name and and model/ part 
number of the installed memory module?

Can not tell right now.


Okay.  Please post the information when available.


Run Memtest86+ for 24+ hours with the computer in the same location 
and under the same environmental conditions as the failed 
installations.  I have seen  computers pass Memtest86+ for the first 
12 hours, then give a few failures in the next 12 hours.  Understand 
that temperature and airflow can affect the reliability of electronics.



Try installing from media only; do not use a mirror:

https://cdimage.debian.org/debian-cd/current/i386/iso-cd/debian-10.4.0-i386-xfce-CD-1.iso 



Checksum the ISO file after you download it.


Checksum the installation media after you have burned it and before 
you have booted it (installer images on USB flash drives can and do 
change when booted).



Document the choices you make while running the installer.


Thanks for your suggestions! I will first try to find another RAM stick 
that I know is good, and try install again: it seems faster than trying 
to diagnose a faulty RAM stick.


I would run Memtest86+ for 24 hours first.  If it fails, replace the 
memory module with a known good module and run Memtest86+ for another 24 
hours.  If that fails, I would blame the motherboard.



If/ when your memory is good (and CPU by proxy), download the 
manufacturer diagnostic tool for your system drive and run that. 
Consider wiping the system drive.  I prefer bootable USB images.  For 
example:


https://www.seagate.com/support/downloads/seatools/


Once your CPU, memory, and system drive are known good, then do the install.


David

Re: Smallest Usable EFI Partition?

[Andrea Borgia]

Il 13/05/20 00:21, Patrick Bartek ha scritto:



I can't find anything definitive on this question.  Some say, 100MB is
fine; others 215 or 550 is a safe choice.  It all seems to be just
opinions.


I had the same doubts about a year ago and went with the recommendation 
of a larger partition, about 500MB... of which only 6% is used.


My office laptop with Windows10 has something in the region of 100MB but 
it is not dualboot.


Debian uses about 6MB, MS about 26MB, plus a couple of megs for boot.
If space is really tight you might want to stick with 100MB in total.

HTH,
Andrea.

Smallest Usable EFI Partition?

[Patrick Bartek]

Hi! All,

I can't find anything definitive on this question.  Some say, 100MB is
fine; others 215 or 550 is a safe choice.  It all seems to be just
opinions.

Anyone know for sure? I hate having to waste hundreds of megs for a
partition that only needs to hold a few megs, if that much.

This applies to one of those small, $300+/- notebooks (haven't decided
which one, yet) that usually use 32 or 64GB eMMCs.  I'm trying to
maximize the available free space. Best option seems to be a MBR
install, one OS only (Buster, X, window manager only, etc.), / and
swap.  But if that's not possible . . . .  Hence, my query.

Thanks.

B

Re: Question on Unattended Upgrades

[l0f4r0]

Hi,

12 mai 2020 à 23:44 de cov...@ccs.covici.com:

> Hmmm, I looked in man apt.conf and for the periodic options it said to
> look in /usr/lib/apt/apt.systemd.daily and that script does not
> mention the option you mentioned.  Is there some other place I should
> look for its description?
>
APT::Periodic::Unattended-Upgrade "1"; enables "apt upgrade" itself.More 
details on:
* https://wiki.debian.org/UnattendedUpgrades.
* man unattended-upgrades
* /usr/share/doc/unattended-upgrades/README.md.gz

Best regards,
l0f4r0

Re: Question on Unattended Upgrades

[John Covici]

Hmmm, I looked in man apt.conf and for the periodic options it said to
look in /usr/lib/apt/apt.systemd.daily and that script does not
mention the option you mentioned.  Is there some other place I should
look for its description?


On Tue, 12 May 2020 16:47:33 -0400,
David Wright wrote:
> 
> On Tue 12 May 2020 at 15:14:51 (-0400), John Covici wrote:
> > To get back to the topic -- I have unattended updates set supposedly,
> > but they do nothing.
> > 
> > Here are the relevant files from my apt.conf.d directory
> > 
> > 20-auto-upgrades
> > apt::periodic::unattended-upgrade "1";
> > 
> > Here is my 50-unattended-upgrades
> > […]
> 
> You appear to have removed the line
> 
> APT::Periodic::Update-Package-Lists "1";
> 
> from 20-auto-upgrades. Is something else responsible for updating them?
> 
> Also, I assume that there's no 20auto-upgrades-disabled present.
> 
> Disclaimer: I don't use the package, so I'm only looking at the
> /usr/share/unattended-upgrades/ files which probably get modified
> during installation.
> 
> Cheers,
> David.
> 

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici wb2una
 cov...@ccs.covici.com

Re: Lost the firefox windows

[l0f4r0]

Hi,

12 mai 2020 à 21:29 de d...@randomstring.org:

> Are you running a window manager which has the concept of
> minimization/iconization?
>
In the same vein, I've already lost sight of some windows because of the 
roll-up functionality under Xfce ;p

Best regards,
l0f4r0

Re: Lost the firefox windows

[rhkramer]

On Tuesday, May 12, 2020 03:29:10 PM Dan Ritter wrote:
> rhkra...@gmail.com wrote:
> > On debian wheezy:
> > 
> > I might have fat fingered something (or not) but the firefox windows have
> > disappeared.  I was about to restart firefox (which would cause me to
> > lose the content on my private firefox window), but I ran a ps command
> > and see that firefox is still running, but I've checked all my desktops
> > and the windows (firefox gui displays) are gone.
> > 
> > Any thoughts on a way to recover them short of killing firefox and
> > restarting it?
> 
> Are you running a window manager which has the concept of
> minimization/iconization? 

I think I found the problem (at least I think so) apparently (I'm guessing 
that I hit  q by accident), but the system / firefox was so busy that it 
took something like 15 minutes to shut down.

But, just to answer the question you asked: Well, yes, I think so (I run kde 
4.8.4 -- the "current" version in Wheezy, but if I minimize a window the icon 
(or whatever the right word is) still remains on my tool bar so I can re-
establish the window by clicking on it.

Anyway, I guess it is all good now -- thanks for your help!  (I have restarted 
firefox, and recovered the windows / tabs except for those in the private 
window -- disappointing.

> It might have just suspended showing
> you the windows and be able to bring them back by undoing that.
> 
> -dsr-

Re: Lost the firefox windows

[David Wright]

On Tue 12 May 2020 at 15:29:10 (-0400), Dan Ritter wrote:
> rhkra...@gmail.com wrote: 
> > On debian wheezy:
> > 
> > I might have fat fingered something (or not) but the firefox windows have 
> > disappeared.  I was about to restart firefox (which would cause me to lose 
> > the 
> > content on my private firefox window), but I ran a ps command and see that 
> > firefox is still running, but I've checked all my desktops and the windows 
> > (firefox gui displays) are gone.
> > 
> > Any thoughts on a way to recover them short of killing firefox and 
> > restarting 
> > it?
> 
> Are you running a window manager which has the concept of
> minimization/iconization? It might have just suspended showing
> you the windows and be able to bring them back by undoing that.

On my system, if I type   firefox   into an xterm, firefox reappears.
If it was iconified, it deiconifies; if it wasn't running, it runs,
often failing to open all the windows/tabs until I press its Restore
button.

I could just Ctrl-RightClick in the root window and click firefox in
the Window List, but that's more effort than rerunning it (usually
via an alias like my-bank or my-forecast).

Cheers,
David.

Re: Question on Unattended Upgrades

[David Wright]

On Tue 12 May 2020 at 15:14:51 (-0400), John Covici wrote:
> To get back to the topic -- I have unattended updates set supposedly,
> but they do nothing.
> 
> Here are the relevant files from my apt.conf.d directory
> 
> 20-auto-upgrades
> apt::periodic::unattended-upgrade "1";
> 
> Here is my 50-unattended-upgrades
> […]

You appear to have removed the line

APT::Periodic::Update-Package-Lists "1";

from 20-auto-upgrades. Is something else responsible for updating them?

Also, I assume that there's no 20auto-upgrades-disabled present.

Disclaimer: I don't use the package, so I'm only looking at the
/usr/share/unattended-upgrades/ files which probably get modified
during installation.

Cheers,
David.

Re: Lost the firefox windows

[Dan Ritter]

rhkra...@gmail.com wrote: 
> On debian wheezy:
> 
> I might have fat fingered something (or not) but the firefox windows have 
> disappeared.  I was about to restart firefox (which would cause me to lose 
> the 
> content on my private firefox window), but I ran a ps command and see that 
> firefox is still running, but I've checked all my desktops and the windows 
> (firefox gui displays) are gone.
> 
> Any thoughts on a way to recover them short of killing firefox and restarting 
> it?

Are you running a window manager which has the concept of
minimization/iconization? It might have just suspended showing
you the windows and be able to bring them back by undoing that.

-dsr-

Re: Question on Unattended Upgrades

[John Covici]

To get back to the topic -- I have unattended updates set supposedly,
but they do nothing.

Here are the relevant files from my apt.conf.d directory

20-auto-upgrades
apt::periodic::unattended-upgrade "1";

Here is my 50-unattended-upgrades

// Unattended-Upgrade::Origins-Pattern controls which packages are
// upgraded.
//
// Lines below have the format format is "keyword=value,...".  A
// package will be upgraded only if the values in its metadata match
// all the supplied keywords in a line.  (In other words, omitted
// keywords are wild cards.) The keywords originate from the Release
// file, but several aliases are accepted.  The accepted keywords are:
//   a,archive,suite (eg, "stable")
//   c,component (eg, "main", "contrib", "non-free")
//   l,label (eg, "Debian", "Debian-Security")
//   o,origin(eg, "Debian", "Unofficial Multimedia Packages")
//   n,codename  (eg, "jessie", "jessie-updates")
// site  (eg, "http.debian.net")
// The available values on the system are printed by the command
// "apt-cache policy", and can be debugged by running
// "unattended-upgrades -d" and looking at the log file.
//
// Within lines unattended-upgrades allows 2 macros whose values are
// derived from /etc/debian_version:
//   ${distro_id}Installed origin.
//   ${distro_codename}  Installed codename (eg, "buster")
Unattended-Upgrade::Origins-Pattern {
// Codename based matching:
// This will follow the migration of a release through different
// archives (e.g. from testing to stable and later oldstable).
// Software will be the latest available for the named release,
// but the Debian release itself will not be automatically upgraded.
//  "origin=Debian,codename=${distro_codename}-updates";
//  "origin=Debian,codename=${distro_codename}-proposed-updates";
"origin=Debian,codename=${distro_codename},label=Debian";
"origin=Debian,codename=${distro_codename},label=Debian-Security";

// Archive or Suite based matching:
// Note that this will silently match a different release after
// migration to the specified archive (e.g. testing becomes the
// new stable).
//  "o=Debian,a=stable";
//  "o=Debian,a=stable-updates";
//  "o=Debian,a=proposed-updates";
//  "o=Debian Backports,a=${distro_codename}-backports,l=Debian Backports";
};

// Python regular expressions, matching packages to exclude from upgrading
Unattended-Upgrade::Package-Blacklist {
// The following matches all packages starting with linux-
//  "linux-";

// Use $ to explicitely define the end of a package name. Without
// the $, "libc6" would match all of them.
//  "libc6$";
//  "libc6-dev$";
//  "libc6-i686$";

// Special characters need escaping
//  "libstdc\+\+6$";

// The following matches packages like xen-system-amd64, xen-utils-4.1,
// xenstore-utils and libxenstore3.0
//  "(lib)?xen(store)?";

// For more information about Python regular expressions, see
// https://docs.python.org/3/howto/regex.html
};

// This option allows you to control if on a unclean dpkg exit
// unattended-upgrades will automatically run 
//   dpkg --force-confold --configure -a
// The default is true, to ensure updates keep getting installed
//Unattended-Upgrade::AutoFixInterruptedDpkg "true";

// Split the upgrade into the smallest possible chunks so that
// they can be interrupted with SIGTERM. This makes the upgrade
// a bit slower but it has the benefit that shutdown while a upgrade
// is running is possible (with a small delay)
//Unattended-Upgrade::MinimalSteps "true";

// Install all updates when the machine is shutting down
// instead of doing it in the background while the machine is running.
// This will (obviously) make shutdown slower.
// Unattended-upgrades increases logind's InhibitDelayMaxSec to 30s.
// This allows more time for unattended-upgrades to shut down gracefully
// or even install a few packages in InstallOnShutdown mode, but is still a
// big step back from the 30 minutes allowed for InstallOnShutdown previously.
// Users enabling InstallOnShutdown mode are advised to increase
// InhibitDelayMaxSec even further, possibly to 30 minutes.
Unattended-Upgrade::InstallOnShutdown "false";

// Send email to this address for problems or packages upgrades
// If empty or unset then no email is sent, make sure that you
// have a working mail setup on your system. A package that provides
// 'mailx' must be installed. E.g. "u...@example.com"
Unattended-Upgrade::Mail "cov...@ccs.covici.com";

// Set this value to "true" to get emails only on errors. Default
// is to always send a mail if Unattended-Upgrade::Mail is set
//Unattended-Upgrade::MailOnlyOnError "false";

// Remove unused automatically installed kernel-related packages
// (kernel images, kernel headers and kernel version locked tools).
//Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";

// Do automatic remo

Re: trying to mount a micro USB disk as a regular user on a Linux laptop on which I don't have admin rights ...

[deloptes]

Albretch Mueller wrote:

> $ mount --types vfat /dev/sdc1 /media/user/5C51-D400
> mount: only root can use "--types" option

this is not supposed to be mounted there from the command line. use the file
browser and don't forget to add the user to plugdev (if I am not mistaken)
after adding to the group you have to logout and login again

Lost the firefox windows

[rhkramer]

On debian wheezy:

I might have fat fingered something (or not) but the firefox windows have 
disappeared.  I was about to restart firefox (which would cause me to lose the 
content on my private firefox window), but I ran a ps command and see that 
firefox is still running, but I've checked all my desktops and the windows 
(firefox gui displays) are gone.

Any thoughts on a way to recover them short of killing firefox and restarting 
it?

Re: R performance

[Nicholas Geovanis]

On Tue, May 12, 2020, 10:55 AM Mark Fletcher  wrote:

> On Tue, May 12, 2020 at 08:16:52AM -0600, D. R. Evans wrote:
> > Mark Fletcher wrote on 5/12/20 7:34 AM:
> > > Hello
> > >
> >
> > I have noticed that recent versions of R supplied by debian are using
> all the
> > available cores instead of just one. I don't know whether that's a debian
> > change or an R change, but it certainly makes things much faster (one of
> my
> > major complaints about R was that it seemed to be single threaded, so
> I'm very
> > glad that, for whatever reason, that's no longer the case).
> >
> Thanks, but definitely not the case here. When running on my own
> machine, top shows the process at 100% CPU, the load on the machine
> heading for 1.0, and the Gnome system monitor shows one CPU vCore
> (hyperthread, whatever) at 100% and the other 7 idle.
>
> R is certainly _capable_ of using more of the CPU than that, but you
> have to load libraries eg snow and use their function calls to do it -- in
> short, like in many languages, you have to code for parallelism. I tried
> to keep parallelism out of this experiment on both machines being
> compared.
>

You don't mention which distro you are running on the EC2 instance, nor
whether R or the C libraries differ in release levels. Moreover, that EC2
instance type is AMD-based not Intel. So if not an apples-to-oranges
comparison, it might be fujis-to-mcintoshs.

Long ago I built R from source a couple times a year. It has an
unfathomable number of libraries and switches, any one of them could have a
decisive effect on performamce. Two different builds could be quite
different in behavior.

Mark
>
>

Re: R performance

[D. R. Evans]

Mark Fletcher wrote on 5/12/20 9:55 AM:
> On Tue, May 12, 2020 at 08:16:52AM -0600, D. R. Evans wrote:
>> Mark Fletcher wrote on 5/12/20 7:34 AM:
>>> Hello
>>>
>>
>> I have noticed that recent versions of R supplied by debian are using all the
>> available cores instead of just one. I don't know whether that's a debian
>> change or an R change, but it certainly makes things much faster (one of my
>> major complaints about R was that it seemed to be single threaded, so I'm 
>> very
>> glad that, for whatever reason, that's no longer the case).
>>
> Thanks, but definitely not the case here. When running on my own 
> machine, top shows the process at 100% CPU, the load on the machine 
> heading for 1.0, and the Gnome system monitor shows one CPU vCore 
> (hyperthread, whatever) at 100% and the other 7 idle.
> 
> R is certainly _capable_ of using more of the CPU than that, but you 
> have to load libraries eg snow and use their function calls to do it -- in 
> short, like in many languages, you have to code for parallelism. I tried 
> to keep parallelism out of this experiment on both machines being 
> compared.
> 

OK. Well I don't understand what's going on and don't really have anything
further to contribute :-( All I know is that the same code that used to run on
just one core pre-buster now uses all the cores available, with no changes or
fancy libraries. I was (of course) very pleasantly surprised the first time I
ran one of my R scripts under buster and saw this happen. I haven't
experimented further.

  Doc

-- 
Web:  http://enginehousebooks.com/drevans



signature.asc
Description: OpenPGP digital signature

Re: R performance

[Mark Fletcher]

On Tue, May 12, 2020 at 08:16:52AM -0600, D. R. Evans wrote:
> Mark Fletcher wrote on 5/12/20 7:34 AM:
> > Hello
> > 
> 
> I have noticed that recent versions of R supplied by debian are using all the
> available cores instead of just one. I don't know whether that's a debian
> change or an R change, but it certainly makes things much faster (one of my
> major complaints about R was that it seemed to be single threaded, so I'm very
> glad that, for whatever reason, that's no longer the case).
> 
Thanks, but definitely not the case here. When running on my own 
machine, top shows the process at 100% CPU, the load on the machine 
heading for 1.0, and the Gnome system monitor shows one CPU vCore 
(hyperthread, whatever) at 100% and the other 7 idle.

R is certainly _capable_ of using more of the CPU than that, but you 
have to load libraries eg snow and use their function calls to do it -- in 
short, like in many languages, you have to code for parallelism. I tried 
to keep parallelism out of this experiment on both machines being 
compared.

Mark

Re: Question on Unattended Upgrades

[David Wright]

On Tue 12 May 2020 at 07:48:49 (-0400), rhkra...@gmail.com wrote:
> On Tuesday, May 12, 2020 02:22:13 AM Keifer Bly wrote:
> > Is there a way to configure it to automatically restart when a package that
> > needs to be restarted is upgraded? Thx.
> 
> If there is a comand named "needrestart" (I don't see it on my Wheezy 
> system), 
> then presumably a (bash?) script could be written to automate a restart.

It's in backports.

Cheers,
David.

Re: Question on Unattended Upgrades

[Celejar]

On Tue, 12 May 2020 11:05:55 -0400
Gene Heskett  wrote:

> On Tuesday 12 May 2020 10:30:04 Celejar wrote:
> 
> > On Tue, 12 May 2020 06:03:52 -0400
> >
> > Gene Heskett  wrote:
> > > On Tuesday 12 May 2020 05:07:04 l0f...@tuta.io wrote:
> > > > Hi,
> > > >
> > > > 12 mai 2020 à 08:22 de keifer@gmail.com:
> > > > > Is there a way to configure it to automatically restart when a
> > > > > package that needs to be restarted is upgraded?
> > > >
> > > > I think 'Unattended-Upgrade::Automatic-Reboot "true";' should do
> > > > it in /etc/apt/apt.conf.d/50unattended-upgrades. If I were you, I
> > > > would check /etc/apt/apt.conf.d/20auto-upgrades as well because
> > > > those are the 2 most important configuration files for
> > > > unattended-upgrades.
> > > >
> > > > Best regards,
> > > > l0f4r0
> > >
> > > I can see a major disaster in the making, what if that reboot was
> > > commanded in the middle of your nightly backup run, leaving your
> > > backup program with a totally bogus database it cannot recover from?
> >
> > That would be unfortunate - but surely a serious backup program would
> > be designed to be robust enough that ending up "with a totally bogus
> > database it cannot recover from" should never happen? What if you
> > have some sort of system crash during a backup? Do you have a specific
> > backup system in mind?
> 
> You are trying to justify an automatic reboot, very bad idea. Granted, 
> most such would be ok, and will leave a requester popup to advise the 
> admin, doing its normal routine in the meantime.

I'm not trying to justify an automatic reboot; I'm just questioning the
specific dire scenario you mention.

> I happen to use amanda to backup 5 machines here, but any backup suite 
> that maintains a recovery database is going to be in deep doodoo if it 
> gets rebooted in the middle of a backup.  I probably do better than most 

Surely any "recovery database" used by a serious backup program is
atomic!

> but a worst case scenario here if everything in place works, would only 
> lose me that days data because I do keep separate copies of that data. 
> But 60 days of that is 33GB, the biggest single entry in my nearly 70 
> items long list.

Celejar

Re: Question on Unattended Upgrades

[Gene Heskett]

On Tuesday 12 May 2020 10:30:04 Celejar wrote:

> On Tue, 12 May 2020 06:03:52 -0400
>
> Gene Heskett  wrote:
> > On Tuesday 12 May 2020 05:07:04 l0f...@tuta.io wrote:
> > > Hi,
> > >
> > > 12 mai 2020 à 08:22 de keifer@gmail.com:
> > > > Is there a way to configure it to automatically restart when a
> > > > package that needs to be restarted is upgraded?
> > >
> > > I think 'Unattended-Upgrade::Automatic-Reboot "true";' should do
> > > it in /etc/apt/apt.conf.d/50unattended-upgrades. If I were you, I
> > > would check /etc/apt/apt.conf.d/20auto-upgrades as well because
> > > those are the 2 most important configuration files for
> > > unattended-upgrades.
> > >
> > > Best regards,
> > > l0f4r0
> >
> > I can see a major disaster in the making, what if that reboot was
> > commanded in the middle of your nightly backup run, leaving your
> > backup program with a totally bogus database it cannot recover from?
>
> That would be unfortunate - but surely a serious backup program would
> be designed to be robust enough that ending up "with a totally bogus
> database it cannot recover from" should never happen? What if you
> have some sort of system crash during a backup? Do you have a specific
> backup system in mind?

You are trying to justify an automatic reboot, very bad idea. Granted, 
most such would be ok, and will leave a requester popup to advise the 
admin, doing its normal routine in the meantime.

I happen to use amanda to backup 5 machines here, but any backup suite 
that maintains a recovery database is going to be in deep doodoo if it 
gets rebooted in the middle of a backup.  I probably do better than most 
but a worst case scenario here if everything in place works, would only 
lose me that days data because I do keep separate copies of that data. 
But 60 days of that is 33GB, the biggest single entry in my nearly 70 
items long list.

> > Frankly the update shouldn't be allowed if your backup is actually
> > running.  So it might be safer to schedule the update and reboot if
> > needed before the backup starts.  That means one cron driven script
> > does it all in the sequence desired.

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Suggestion on hardware issue?

[Yvan Masson]

Le 12/05/2020 à 03:37, David Christensen a écrit :

On 2020-05-11 10:28, Yvan Masson wrote:

Hi,

I installed Debian 10 on a Acer AspireOne (32 bits processor, 1GB RAM).
Installation failed two times with corrupted packages, each time on 
same package (tcllib). I finally manage to re-download and install it 
by hand in another TTY so that the installer could finish. However, 
after the reboot, it could not start sddm (segfaults).


I tested RAM by running memtest86+ on this computer (3 passes, 4 
hours), no issue. I ran debsums to check files integrity, and it 
returned many errors (written here by hand, so there might be typos):


/usr/lib/gcc/i686-linux-gnu/8/cc1
/usr/lib/firefox-esr/libxul.so
/usr/lib/firefox-esr/omni.ja
/usr/lib/i386-linux-gnu/dri/kms_swrast_dri.so
/usr/lib/i386-linux-gnu/dri/nouveau_dri.so
/usr/lib/i386-linux-gnu/dri/r300_dri.so
/usr/lib/i386-linux-gnu/dri/r600_dri.so
/usr/lib/i386-linux-gnu/dri/radeonsi_dri.so
/usr/lib/i386-linux-gnu/dri/swrast_dri.so
/usr/lib/i386-linux-gnu/dri/virtio_gpu_dri.so
/usr/lib/i386-linux-gnu/dri/vmwgfx_dri.so
/usr/share/doc/libgstreamer1.0-0/changelog.gz
/usr/lib/i386-linux-gnu/libgucharmap_2_90.so.7.0.0
/usr/lib/i386-linux-gnu/libicudata.so.63.1
/usr/lib/i386-linux-gnu/libLLVM-7.so.1
/usr/lib/i386-linux-gnu/libQt5WebKit.so.5.212.0
/usr/lib/i386-linux-gnu/libre2.so.5.0.0
/usr/share/libreoffice/share/config/images_helpimg.zip
/usr/lib/libreoffice/program/libmergedlo.so
/usr/lib/libreoffice/program/libpcrlo.so
/usr/lib/jvm/java-11-openjdk-i386/lib/modules
/usr/lib/jvm/java-11-openjdk-i386/lib/server/libjvm.so
/usr/share/thunderbird/omni.ja
[ ] EXT4-fs error (device sda-1): ext4_lookup:1591: inode #1222922: 
comm debsums: iget: checksum invalid

[ ] Aborting journal on device sda1-8.
[ ] EXT4-fs (sda1): Remounting filesystem read-only


I have then thought that it could be the hard drive, so I replaced it 
with a spare one: install failed again, but when configuring a 
different package.


Is the motherboard or processor faulty, or is there any hope for a 
simple solution to save this computer?


Regards,
Yvan


Was the memory in your computer installed by Acer?

I believe so.



Have you removed or inserted any memory modules?

Not before the issue arose.



Do you use static safe tools and work practices?

In this case I only used my hands, and touched grounded metal before.



What is the model/ part number of your computer?

I can not tell now as I won't have access to the computer before two days.



How many memory slots does the computer have?

1



For each slot, what is the manufacturer name and and model/ part number 
of the installed memory module?

Can not tell right now.



Run Memtest86+ for 24+ hours with the computer in the same location and 
under the same environmental conditions as the failed installations.  I 
have seen  computers pass Memtest86+ for the first 12 hours, then give a 
few failures in the next 12 hours.  Understand that temperature and 
airflow can affect the reliability of electronics.



Try installing from media only; do not use a mirror:

https://cdimage.debian.org/debian-cd/current/i386/iso-cd/debian-10.4.0-i386-xfce-CD-1.iso 




Checksum the ISO file after you download it.


Checksum the installation media after you have burned it and before you 
have booted it (installer images on USB flash drives can and do change 
when booted).



Document the choices you make while running the installer.


David



Thanks for your suggestions! I will first try to find another RAM stick 
that I know is good, and try install again: it seems faster than trying 
to diagnose a faulty RAM stick.

Re: Question on Unattended Upgrades

[Celejar]

On Tue, 12 May 2020 06:03:52 -0400
Gene Heskett  wrote:

> On Tuesday 12 May 2020 05:07:04 l0f...@tuta.io wrote:
> 
> > Hi,
> >
> > 12 mai 2020 à 08:22 de keifer@gmail.com:
> > > Is there a way to configure it to automatically restart when a
> > > package that needs to be restarted is upgraded?
> >
> > I think 'Unattended-Upgrade::Automatic-Reboot "true";' should do it
> > in /etc/apt/apt.conf.d/50unattended-upgrades. If I were you, I would
> > check /etc/apt/apt.conf.d/20auto-upgrades as well because those are
> > the 2 most important configuration files for unattended-upgrades.
> >
> > Best regards,
> > l0f4r0
> 
> I can see a major disaster in the making, what if that reboot was 
> commanded in the middle of your nightly backup run, leaving your backup 
> program with a totally bogus database it cannot recover from?

That would be unfortunate - but surely a serious backup program would
be designed to be robust enough that ending up "with a totally bogus
database it cannot recover from" should never happen? What if you
have some sort of system crash during a backup? Do you have a specific
backup system in mind?

> Frankly the update shouldn't be allowed if your backup is actually 
> running.  So it might be safer to schedule the update and reboot if 
> needed before the backup starts.  That means one cron driven script does 
> it all in the sequence desired.
> 
> Cheers, Gene Heskett

Celejar

Re: R performance

[D. R. Evans]

Mark Fletcher wrote on 5/12/20 7:34 AM:
> Hello
> 
> I have recently had cause to compare performance of running the R 
> language on my 10+-year-old PC running Buster (Intel Core i7-920 CPU) 
> and in the cloud on AWS. I got a surprising result, and I am wondering 
> if the R packages on Debian have been built with any flags that account 
> for the difference.
> 
> My PC was a mean machine when it was built, but that was in 2009. I'd 
> expect it would be outperformed by up to date hardware.
> 

I have noticed that recent versions of R supplied by debian are using all the
available cores instead of just one. I don't know whether that's a debian
change or an R change, but it certainly makes things much faster (one of my
major complaints about R was that it seemed to be single threaded, so I'm very
glad that, for whatever reason, that's no longer the case).

  Doc

-- 
Web:  http://enginehousebooks.com/drevans



signature.asc
Description: OpenPGP digital signature

R performance

[Mark Fletcher]

Hello

I have recently had cause to compare performance of running the R 
language on my 10+-year-old PC running Buster (Intel Core i7-920 CPU) 
and in the cloud on AWS. I got a surprising result, and I am wondering 
if the R packages on Debian have been built with any flags that account 
for the difference.

My PC was a mean machine when it was built, but that was in 2009. I'd 
expect it would be outperformed by up to date hardware.

I have a script in R which I wrote which performs a moderately involved 
calculation column-by-column on a 4000-row, 1-column matrix. On my 
Buster PC, performing the calculation on a single column takes 9.5 
seconds. The code does not use any multi-cpu capabilities so it uses 
just one of the 8 avaialable virtual CPUs in my PC while doing so. (4 
cores, with hyperthreading = 8 virtual CPUs)

Running the same code on the same data on a fairly high-spec AWS EC2 
server in the cloud, (the r5a-4xlarge variety for those who know about 
AWS) the same calculation takes 2 minutes and 6 seconds. 

Obviously there is virtualisation involved here, but at low load with 
just one instance running and the machine not being asked to do anything 
else I would have expected the AWS machine to be much closer to local 
performance if not better, given the age of my PC.

In the past I have run highly parallel Java programs in the two 
environments and have seen much better results from using AWS in 
Java-land. That led me to wonder if it is something about how R is 
configured. I am not getting anywhere in the AWS forums (unless you pay 
a lot of money you basically don't get a lot of attention) so I was 
wondering if anyone was familiar with how the R packages are configured 
in Debian who might know if anything has been done to optimise 
performance, that might explain why it is so much faster in Debian? Is 
it purely local hardware versus virtualised? I am struggling to believe 
that because I don't see the same phenomenon in Java programs.

Thanks for any ideas

Mark

Re: Question on Unattended Upgrades

[John Hasler]

 Keifer Bly writes:
> I am wondering, does the OS need to be restarted for the upgrade to
> take effect?

Only if the kernel was upgraded.

> What file would I check to make sure the unattended upgrades is
> working and the packages it updated?

>From the man page:

All operations are logged to
/var/log/unattended-upgrades/unattended-upgrades.log
and the package manager (dpkg) output is logged to
/var/log/unattended-upgrades/unattended-up‐grades-dpkg.log

You can arrange to get emails by editing
/etc/apt/apt.conf.d/50unattended-upgrades.  Lots other options as well.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: Question on Unattended Upgrades

[Reco]

Hi.

On Tue, May 12, 2020 at 07:48:49AM -0400, rhkra...@gmail.com wrote:
> On Tuesday, May 12, 2020 02:22:13 AM Keifer Bly wrote:
> > Is there a way to configure it to automatically restart when a package that
> > needs to be restarted is upgraded? Thx.
> 
> If there is a comand named "needrestart" (I don't see it on my Wheezy 
> system), 
> then presumably a (bash?) script could be written to automate a restart.

$ file /usr/sbin/needrestart
/usr/sbin/needrestart: Perl script text executable

Appeared in Jessie, still here.

Reco

Re: Question on Unattended Upgrades

[Greg Wooledge]

On Tue, May 12, 2020 at 07:48:49AM -0400, rhkra...@gmail.com wrote:
> On Tuesday, May 12, 2020 02:22:13 AM Keifer Bly wrote:
> > Is there a way to configure it to automatically restart when a package that
> > needs to be restarted is upgraded? Thx.
> 
> If there is a comand named "needrestart" (I don't see it on my Wheezy 
> system), 
The package appears to have been added in jessie.

Re: Question on Unattended Upgrades

[rhkramer]

On Tuesday, May 12, 2020 02:22:13 AM Keifer Bly wrote:
> Is there a way to configure it to automatically restart when a package that
> needs to be restarted is upgraded? Thx.

If there is a comand named "needrestart" (I don't see it on my Wheezy system), 
then presumably a (bash?) script could be written to automate a restart.

(If I did it (which I won't), I'd make it present its results to the user / 
administrator and ask for confirmation, and/or use that command that warns 
users that the system is about to be shut down.)

Re: trying to mount a micro USB disk as a regular user on a Linux laptop on which I don't have admin rights ...

[Eric S Fraga]

If pmount is installed/available, 'pmount sdc1' will mount the disk onto
/media/sdc1.

-- 
Eric S Fraga via Emacs 28.0.50 & org 9.3.6 on Debian bullseye/sid

Re: Question on Unattended Upgrades

[l0f4r0]

Hi,

12 mai 2020 à 12:03 de ghesk...@shentel.net:

> I can see a major disaster in the making, what if that reboot was 
> commanded in the middle of your nightly backup run, leaving your backup 
> program with a totally bogus database it cannot recover from?
>
> Frankly the update shouldn't be allowed if your backup is actually 
> running.  So it might be safer to schedule the update and reboot if 
> needed before the backup starts.  That means one cron driven script does 
> it all in the sequence desired.
>
Of course, nice reminder from Gene, as usual technology doesn't replace common 
sense ;)
Binaries simply execute what you ask them to, they don't see the whole picture 
and what you really intend to do eventually... 

Best regards,
l0f4r0

Re: cleanly getting rid of manually installed transitional packages due to rename

[Vincent Lefevre]

On 2020-05-07 18:24:59 -0500, David Wright wrote:
> On Wed 06 May 2020 at 12:31:35 (+0200), Vincent Lefevre wrote:
> > I use unstable. I doubt that packages get renamed in stable
> > (except between full upgrades, where the issue has already
> > been solved with the oldlibs section).
> 
> I don't understand the relevance of oldlibs: only one of the packages
> that I removed was in that section, imagemagick, which gets pulled in
> under that name by inkscape as a Recommends.

oldlibs was mentioned by Sven Joachim as solving the issue
automatically (at least with apt).

I also have a Debian/stable machine, but no manually installed
packages were renamed in the upgrade to buster, so I could not
check... IIRC, I've never noticed any issue when upgrading this
Debian/stable machine anyway.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

trying to mount a micro USB disk as a regular user on a Linux laptop on which I don't have admin rights ...

[Albretch Mueller]

$ mount /dev/sdc1
mount: can't find /dev/sdc1 in /etc/fstab

$ umount /dev/sdc1

$ mount --types vfat /dev/sdc1 /media/user/5C51-D400
mount: only root can use "--types" option

$ mount /dev/sdc1 /media/user/5C51-D400
mount: only root can do that

$ mount /dev/sdc1
mount: can't find /dev/sdc1 in /etc/fstab

$

 lbrtchx

Re: Question on Unattended Upgrades

[Gene Heskett]

On Tuesday 12 May 2020 05:07:04 l0f...@tuta.io wrote:

> Hi,
>
> 12 mai 2020 à 08:22 de keifer@gmail.com:
> > Is there a way to configure it to automatically restart when a
> > package that needs to be restarted is upgraded?
>
> I think 'Unattended-Upgrade::Automatic-Reboot "true";' should do it
> in /etc/apt/apt.conf.d/50unattended-upgrades. If I were you, I would
> check /etc/apt/apt.conf.d/20auto-upgrades as well because those are
> the 2 most important configuration files for unattended-upgrades.
>
> Best regards,
> l0f4r0

I can see a major disaster in the making, what if that reboot was 
commanded in the middle of your nightly backup run, leaving your backup 
program with a totally bogus database it cannot recover from?

Frankly the update shouldn't be allowed if your backup is actually 
running.  So it might be safer to schedule the update and reboot if 
needed before the backup starts.  That means one cron driven script does 
it all in the sequence desired.

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Question on Unattended Upgrades

[l0f4r0]

Hi,

12 mai 2020 à 08:22 de keifer@gmail.com:

> Is there a way to configure it to automatically restart when a package that 
> needs to be restarted is upgraded?
>
I think 'Unattended-Upgrade::Automatic-Reboot "true";' should do it in 
/etc/apt/apt.conf.d/50unattended-upgrades.
If I were you, I would check /etc/apt/apt.conf.d/20auto-upgrades as well 
because those are the 2 most important configuration files for 
unattended-upgrades.

Best regards,
l0f4r0

Re: SystemVirtualization: Debian-wiki page update?

[Andrei POPESCU]

On Ma, 12 mai 20, 10:24:51, l0f...@tuta.io wrote:
> Hi,
> 
> 12 mai 2020 à 09:55 de riveravaldezm...@gmail.com:
> 
> > not sure if this is the place for this, but I've found a little
> > confusing to find where to mention a debian-wiki issue...
> >
> I'm not answering the "issue" part itself but here are two pointers regarding 
> how to contact the Debian Wiki team:
> * https://wiki.debian.org/DebianWiki/Contact
> * https://wiki.debian.org/Teams/DebianWiki

The Debian Wiki team is responsible for maintaining the service itself, 
not the content.
 
> I think you should combine feedbacks from Debian-User (daily 
> operational) with those from Debian Wiki people (maybe more about 
> public policy/approach).

It's a wiki, just go ahead and make the change.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: SystemVirtualization: Debian-wiki page update?

[l0f4r0]

Hi,

12 mai 2020 à 09:55 de riveravaldezm...@gmail.com:

> not sure if this is the place for this, but I've found a little
> confusing to find where to mention a debian-wiki issue...
>
I'm not answering the "issue" part itself but here are two pointers regarding 
how to contact the Debian Wiki team:
* https://wiki.debian.org/DebianWiki/Contact
* https://wiki.debian.org/Teams/DebianWiki

I think you should combine feedbacks from Debian-User (daily operational) with 
those from Debian Wiki people (maybe more about public policy/approach).

Best regards,
l0f4r0

SystemVirtualization: Debian-wiki page update?

[riveravaldez]

Hi, not sure if this is the place for this, but I've found a little
confusing to find where to mention a debian-wiki issue...

The SystemVirtualization[1] wiki-page offers as first 'Debian
solution' VirtualBox[2], which is non-free and "not available in
Debian 10 and won't be in buster-backports either[3]. A recommended
alternative is Virtual Machine Manager (buster/virt-manager)", so, I
suppose virt-manager[4] should be the first offered Debian-solution,
wouldn't be?

Best regards!

[1] https://wiki.debian.org/SystemVirtualization
[2] https://wiki.debian.org/VirtualBox
[3] https://bugs.debian.org/794466
[4] https://packages.debian.org/bullseye/virt-manager

Re: Why do I have so many packages to upgrade with Debian 10.4?

[Andrei POPESCU]

On Lu, 11 mai 20, 19:12:52, l0f...@tuta.io wrote:
> Below were the results before I applied the upgrades:
> 
> apt list --upgradable

[snip]

Nothing unusual. You also have i386 packages installed so this will also 
increase the number of updates.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature