Ottavio Caruso wrote:
> Am 03/10/2023 um 10:43 schrieb Bret Busby:
> > Also, why do you not use, instead of the command that you specified,
> > shutdown -h
> > or, (if instead, wanted, for example, after doing a kernel update)
> > shutdown -r
> > ?
>
>
On Tue 03 Oct 2023 at 13:15:48 (+), Ottavio Caruso wrote:
> Am 03/10/2023 um 11:47 schrieb Ottavio Caruso:
> > Am 03/10/2023 um 10:43 schrieb Bret Busby:
> > > Also, why do you not use, instead of the command that you specified,
> > > shutdown -h
> > >
no idea if the laptop is completely off or
just thinking about it.
Is there a way to force verbosity during shutdown without opening a
terminal window or creating a keyboard shortcut?
Thanks
It is not the answer to your question, but, it may be the answer that
you seek;
"the screen
On 03/10/2023 16:14, Ottavio Caruso wrote:
$ sudo systemctl poweroff
...
Is there a way to force verbosity during shutdown without opening a
terminal window or creating a keyboard shortcut?
Perhaps all you need is
sudo journalctl -b -1 -e
when you boot your machine next time. Likely
On Sun, Mar 26, 2023 at 11:33 PM Ram Ramesh wrote:
> Hi Ramesh,
>
> this might help. The bug is fixed with kernel 6.0.2-1
>
> https://groups.google.com/g/linux.debian.bugs.dist/c/p-sgJiTR00A?pli=1
>
> All the best to you
> Eike
>
> Elke,
>
> Thanks. v6.1 is available on bullseye-backports. I
Hi Ramesh,
this might help. The bug is fixed with kernel 6.0.2-1
https://groups.google.com/g/linux.debian.bugs.dist/c/p-sgJiTR00A?pli=1
All the best to you
Eike
Elke,
Thanks. v6.1 is available on bullseye-backports. I installed it and the
trouble is gone now.
BTW, does non-free firmware
On Sonntag, 26. März 2023 18:08:15 -04 Ram Ramesh wrote:
> I wanted to upgrade my server from 10 year old HW to something newer.
> THis server runs debian bullseye with v5.19 kernel from backports.
[snip]
>
> The only trouble I have is that it refuses to
> reboot/shutdown/poweroff
my RAID disks are working. No issue as long as it runs.
The only trouble I have is that it refuses to reboot/shutdown/poweroff.
It seem to go through all steps and reach the end but seem to get stuck
in this endless cycle complaining about some blkdev issue. Here are the
last lines printed
On Thu 15 Dec 2022 at 16:12:32 (+0100), Tobias Diekershoff wrote:
>
> > > perhaps someone of you can help me with tool / log file I have not
> > > investigated
> > > so far. I have a Thinkpad with Debian Bullseye on it, running KDE/Plasma
> > > as main
> > > desktop environment and from time to
ptoms) would be appreciated!
> A good place to start is to check journald logs for previous boot:
> # journalctl --boot -1
Thanks for that hint, I'll have a look when the shutdown happens next time.
Right now I don't have the time to figure out which last boot process was the
last that failed ;-)
Tobias
Hey David!
> > perhaps someone of you can help me with tool / log file I have not
> > investigated
> > so far. I have a Thinkpad with Debian Bullseye on it, running KDE/Plasma as
> > main
> > desktop environment and from time to time it just turn off without prior
> > indication to do so.
>
>
Gesendet: Mittwoch, 14. Dezember 2022 um 10:00 Uhr
> On Wed, Dec 14, 2022 at 01:40:06PM +0500, Alexander V. Makartsev wrote:
> > On 14.12.2022 12:22, Tobias Diekershoff wrote:
> > > Hey everyone,
> > >
> > > perhaps someone of you can help me with tool / log file I have not
> > > investigated
On Wed 14 Dec 2022 at 08:22:01 (+0100), Tobias Diekershoff wrote:
>
> perhaps someone of you can help me with tool / log file I have not
> investigated
> so far. I have a Thinkpad with Debian Bullseye on it, running KDE/Plasma as
> main
> desktop environment and from time to time it just turn
On Wed, Dec 14, 2022 at 01:40:06PM +0500, Alexander V. Makartsev wrote:
> On 14.12.2022 12:22, Tobias Diekershoff wrote:
> > Hey everyone,
> >
> > perhaps someone of you can help me with tool / log file I have not
> > investigated
> > so far. I have a Thinkpad with Debian Bullseye on it, running
On 14.12.2022 12:22, Tobias Diekershoff wrote:
Hey everyone,
perhaps someone of you can help me with tool / log file I have not investigated
so far. I have a Thinkpad with Debian Bullseye on it, running KDE/Plasma as main
desktop environment and from time to time it just turn off without prior
Hey everyone,
perhaps someone of you can help me with tool / log file I have not investigated
so far. I have a Thinkpad with Debian Bullseye on it, running KDE/Plasma as main
desktop environment and from time to time it just turn off without prior
indication to do so.
It it not particular warm
Greg Wooledge wrote:
> On Tue, Nov 22, 2022 at 06:22:57PM +0100, to...@tuxteam.de wrote:
>> Hm. With SysV, you can't either (spoiler alert: the shutdown process
>> itself is the one doing the timing by sleeping until fulfillment of
>> its task). But you always can cancel it (
Sven Joachim writes:
> Perhaps that the --show option was only added in systemd 250 and is not
> available in Bullseye and older Debian releases.
Except as a backport, Bullseye backports has systemd 251.3.
Sven Joachim writes:
[...]
>
> Perhaps that the --show option was only added in systemd 250 and is not
> available in Bullseye and older Debian releases.
>
> Cheers,
>Sven
Ach, indeed. Sorry.
KJ
--
http://wolnelektury.pl/wesprzyj/teraz/
Kamil Joñca writes:
> kjonca@alfa:~%man shutdown
> SHUTDOWN(8)
>
&
On Tue, Nov 22, 2022 at 10:11:15PM +0100, Ximo wrote:
> El 22/11/2022 a las 13:23, Urs Thuermann escribió:
> > After shutdown -h I see no way to see this scheduled shutdown.
> > Before systemd, I could always see the shutdown process with its
> > arguments using ps(1).
&g
On Tue, 22 Nov 2022 21:11:55 +0100
Sven Joachim wrote:
> > kjonca@alfa:~%sudo shutdown --show
> > No scheduled shutdown.
> >
> > Am I overlooked something?
>
> Perhaps that the --show option was only added in systemd 250 and is
> not available in Bulls
El 22/11/2022 a las 13:23, Urs Thuermann escribió:
After shutdown -h I see no way to see this scheduled shutdown.
Before systemd, I could always see the shutdown process with its
arguments using ps(1).
# date --date @$(head -1 /run/systemd/shutdown/scheduled |cut -c6-15)
On 2022-11-22 20:18 +0100, Kamil Jońca wrote:
> Urs Thuermann writes:
>
>> After shutdown -h I see no way to see this scheduled shutdown.
>> Before systemd, I could always see the shutdown process with its
>> arguments using ps(1).
>
> Hm.
> kjonca
On Tue, Nov 22, 2022 at 08:18:31PM +0100, Kamil Jońca wrote:
> Urs Thuermann writes:
>
> > After shutdown -h I see no way to see this scheduled shutdown.
> > Before systemd, I could always see the shutdown process with its
> > arguments using ps(1).
>
> Hm
Urs Thuermann writes:
> After shutdown -h I see no way to see this scheduled shutdown.
> Before systemd, I could always see the shutdown process with its
> arguments using ps(1).
Hm.
kjonca@alfa:~%man shutdown
S
On Tue, Nov 22, 2022 at 12:29:49PM -0500, Greg Wooledge wrote:
> On Tue, Nov 22, 2022 at 06:22:57PM +0100, to...@tuxteam.de wrote:
> > Hm. With SysV, you can't either [change the time, but you can cancel]
> The systemd shutdown(8) man page has a -c option for canceling a pending
&g
On Tue, Nov 22, 2022 at 06:22:57PM +0100, to...@tuxteam.de wrote:
> Hm. With SysV, you can't either (spoiler alert: the shutdown process
> itself is the one doing the timing by sleeping until fulfillment of
> its task). But you always can cancel it (shutdown -c with SysV, dunno
On Tue, Nov 22, 2022 at 09:09:56AM -0600, David Wright wrote:
> On Tue 22 Nov 2022 at 15:56:48 (+0100), to...@tuxteam.de wrote:
> > On Tue, Nov 22, 2022 at 08:48:25AM -0600, David Wright wrote:
> >
> > [...]
> >
> > > There's a file, "scheduled&
On Tue, 22 Nov 2022 09:09:56 -0600
David Wright wrote:
> > > I haven't tried editing, say, the noisiness, to see whether I can
> > > stop the flow of Wall messages on all my xterms.
> >
> > *My* shutdown has a command line option (-Q) for the
On Tue 22 Nov 2022 at 15:56:48 (+0100), to...@tuxteam.de wrote:
> On Tue, Nov 22, 2022 at 08:48:25AM -0600, David Wright wrote:
>
> [...]
>
> > There's a file, "scheduled", that's created in /run/systemd/shutdown,
> > which contains the time, noisiness and dest
On Tue, Nov 22, 2022 at 08:48:25AM -0600, David Wright wrote:
[...]
> There's a file, "scheduled", that's created in /run/systemd/shutdown,
> which contains the time, noisiness and destiny of the shutdown.
> I haven't tried editing, say, the noisiness, to see whether I
On Tue 22 Nov 2022 at 13:23:14 (+0100), Urs Thuermann wrote:
> After shutdown -h I see no way to see this scheduled shutdown.
> Before systemd, I could always see the shutdown process with its
> arguments using ps(1).
>
> Now, the call to shutdown returns to the shell imme
After shutdown -h I see no way to see this scheduled shutdown.
Before systemd, I could always see the shutdown process with its
arguments using ps(1).
Now, the call to shutdown returns to the shell immediately leaving no
process. It probably communicates to the init process 1, but, as
usual
g job, make Cups quicker for external" or something like that.
> > and it takes 1 minute 30 seconds to stop that and start shutdown.
> > What could be causing that ?
> >
> > mick
> >
> That method of stopping the pc is quite dangerous to the hard drive, you
> may kill the po
On Wed 29 Jun 2022 at 20:49:40 (+0200), to...@tuxteam.de wrote:
> On Wed, Jun 29, 2022 at 08:42:44PM +0200, Thomas Schmitt wrote:
> > Will Mengarini wrote:
> > > I feel old.
> > > http://www.catb.org/jargon/html/B/Big-Red-Switch.html
> >
> > Me too. This bu
am.de [22-06/29=We 16:46 +0200]:
[...] the button triggers an orderly shutdown (otherwise
the PC wouldn't get a chance to output a message) [...]
I feel old.
Go right ahead, or is that behind me? I'm 87, down to one eye
as I just had laser surgery on the other. One of the hazards of
the ultima
On Wed, Jun 29, 2022 at 08:42:44PM +0200, Thomas Schmitt wrote:
> Hi,
>
> Will Mengarini wrote:
> > I feel old.
> > http://www.catb.org/jargon/html/B/Big-Red-Switch.html
>
> Me too. This button pressing for shutdown frightens me.
> Two years ago i had to craft a mol
Hi,
Will Mengarini wrote:
> I feel old.
> http://www.catb.org/jargon/html/B/Big-Red-Switch.html
Me too. This button pressing for shutdown frightens me.
Two years ago i had to craft a molly-guard for the on-off-button
on top of this box:
https://static3.caseking.de/media/image/thumbnai
make Cups quicker for external" or something like that.
> > > and it takes 1 minute 30 seconds to stop that and start shutdown.
> > > What could be causing that ?
> > >
> > > mick
> > >
> > That method of stopping the pc is qui
xteam.de [22-06/29=We 16:46 +0200]:
> [...] the button triggers an orderly shutdown (otherwise
> the PC wouldn't get a chance to output a message) [...]
I feel old.
http://www.catb.org/jargon/html/B/Big-Red-Switch.html
t; It usually is very quick and to start up again.
> > There is printer attached to other PC.
> > Recent update of bookworm when turning off PC with power button there is
> > the message,
> > " stopping job, make Cups quicker for external" or something like that.
> &g
attached to other PC.
Recent update of bookworm when turning off PC with power button there
is the message,
" stopping job, make Cups quicker for external" or something like that.
and it takes 1 minute 30 seconds to stop that and start shutdown.
What could be causing that ?
mick
T
when turning off PC with power button there
is the message,
" stopping job, make Cups quicker for external" or something like that.
and it takes 1 minute 30 seconds to stop that and start shutdown.
What could be causing that ?
mick
That method of stopping the pc is quite dangerous t
button there is
the message,
" stopping job, make Cups quicker for external" or something like that.
and it takes 1 minute 30 seconds to stop that and start shutdown.
What could be causing that ?
mick
Ola,
On Tue, Mar 8, 2022 at 6:55 PM Antonio Terceiro wrote:
>
> Em princípio você pode colocar um script em
> /lib/systemd/system-shutdown/ que chama um sleep de quanto tempo você
> quiser, e o processo de desligamento vai esperar ele terminar. Veja a
> manpage de `systemd-shutdo
' para poder rodar um
fsck e reparar.
O processo de shutdown atualmente está muito rápido, então estou
especulando que a causa da corrupção seja o corte no fornecimento de
energia antes que o SSD grave de fato os dados.
Para comprovar ou não essa especulação precisaria atrasar o power off
após
On Tue, Mar 08, 2022 at 04:24:11PM -0300, Paulino Kenji Sato wrote:
> Ola,
> Estou tendo problemas de corrupção de FS em um SSD.
> De vez em quando preciso iniciar um 'live linux' para poder rodar um fsck e
> reparar.
> O processo de shutdown atualmente está muito rápido, então esto
Ola,
Estou tendo problemas de corrupção de FS em um SSD.
De vez em quando preciso iniciar um 'live linux' para poder rodar um fsck e
reparar.
O processo de shutdown atualmente está muito rápido, então estou
especulando que a causa da corrupção seja o corte no fornecimento de
energia antes que o
On Sat, 12 Feb 2022 19:13:28 -0600
Flacusbigotis wrote:
> > I wonder if the package ntopng is necessary for something.
>
> See manpage gor ntopng it's for monitoring network resources/activity.
>
> So if you aren't interested in doing that then you don't need it installed.
Yes, I have
> I wonder if the package ntopng is necessary for something.
See manpage gor ntopng it's for monitoring network resources/activity.
So if you aren't interested in doing that then you don't need it installed.
On Vi, 11 feb 22, 13:36:09, José Luis González wrote:
>
> I wonder if the package ntopng is necessary for something. If I remove
> it nothing else complains. I didn't know this package before.
At least on buster/arm64 nothing depends on it.
Was the package manually installed or does the
On Thu, 10 Feb 2022 21:03:14 -0600
Flacusbigotis wrote:
> Just a question to help you start troubleshooting:
>
> Does the shutdown finish quickly/quicker if you first stop the ntopng
> systemd service manually before doing the full shutdown?
I did a "# service status nto
On 2/11/22, Tixy wrote:
> On Fri, 2022-02-11 at 00:58 +0100, José Luis González wrote:
>> Hi,
>>
>> When shutting down, after upgrading to Debian 11, system shutdown hangs
>> (freezes) for some time (about 1-2 minutes) anytime, making it
>> bothersome to shut
On Fri, 2022-02-11 at 00:58 +0100, José Luis González wrote:
> Hi,
>
> When shutting down, after upgrading to Debian 11, system shutdown hangs
> (freezes) for some time (about 1-2 minutes) anytime, making it
> bothersome to shut the system down.
>
> The freeze happens afthe
Just a question to help you start troubleshooting:
Does the shutdown finish quickly/quicker if you first stop the ntopng
systemd service manually before doing the full shutdown?
On Thu, Feb 10, 2022, 5:59 PM José Luis González wrote:
> Hi,
>
> When shutting down, after upgrading to
Hi,
When shutting down, after upgrading to Debian 11, system shutdown hangs
(freezes) for some time (about 1-2 minutes) anytime, making it
bothersome to shut the system down.
The freeze happens afther the "Stopped target remote filesystems"
status line. After a while "A stop
Le 11/11/2021 à 17:55, Erwan David a écrit :
Le 11/11/2021 à 06:16, David Wright a écrit :
A workaround that might shorten the wait, but only if you're confident
that there aren't processes that need that long to complete, is to edit
the line DefaultTimeoutStopSec=90s in
(for user erwan is said).
How can I debug this, know which service is blocking the shutdown ?
Assuming you system is using systemd then look at the logs for the last
boot with:
#journalctl -b-1
and scroll to the end where you will see what was going on during
shutdown. Errors will likely
top (for user erwan is said).
> > >
> > > How can I debug this, know which service is blocking the shutdown ?
> > Assuming you system is using systemd then look at the logs for the last
> > boot with:
> >
> > #journalctl -b-1
> >
> > and scroll to the
Le mardi 14 septembre 2021 à 00:45 -0300, Gilberto F da Silva a écrit :
> Estou surpreso commuma coisa. Achava que essas coisas de linha de
> comando eram iguais em todas as distribuções.
Na verdade em geral é, mas o Slackware em particular segue o SysV mais
de perto, enquanto as outras são mais
never be
> called directly. From release 2.74 on halt and reboot invoke
> shutdown(8) if the system is not in runlevel 0 or 6. This means
> that if halt or reboot cannot find out the current runlevel (for
> example, when /var/run/utmp hasn't been initialized correctly and
> /va
caso no
systemd, e nada fala sobre o Slackware.
>> ¿Que diz o man do Slackware?
>
> NOTES
>
> Under older sysvinit releases, reboot and halt should never be
> called directly. From release 2.74 on halt and reboot invoke
> shutdown(8) if the system is not in runlevel 0 or 6. Thi
10 set 2021 9:40 −3, Gilberto F da Silva:
> No Slackware o halt desliga a máquina.
man halt:
‘Note that on many SysV systems halt used to be synonymous
to poweroff, i.e. both commands would equally result in
powering the machine off. systemd is more accurate here, and
, é a mesma coisa que os outros, mas sem desligar a
>máquina. Ou seja, encerra o sistema operacional, mas deixa a máquina
>ligada. Não vejo muita utilidade, na minha ignorância.
Shutdown é uma palavra muito comprida para quando você
morrendo de sono e só quer desligar a má
Olha... a classica diferenca entre poweroff, shutdown e halt eh:
halt - termina todos os processos e encerra a CPU
poweroff - exatamente igual ao halt, mas envia um comando ACPI para a placa-mae
e para o PSU para que corte a energia.
shutdown - eh igual ao poweroff, mas executa os scripts de
On 09/09/2021 17:24, Leandro Guimarães Faria Corcete DUTRA wrote:
Le jeudi 09 septembre 2021 à 15:26 -0300, Ednardo Lobo a écrit :
Desconfio que:
1) shutdown
Encerra o SO.
E a máquina. Pelo menos esse é o uso mais comum, embora ele seja
versátil.
Sim, você está certo! Grato, por corrigir
Le jeudi 09 septembre 2021 à 15:26 -0300, Ednardo Lobo a écrit :
> Desconfio que:
>
> 1) shutdown
>
> Encerra o SO.
E a máquina. Pelo menos esse é o uso mais comum, embora ele seja
versátil.
> 2) halt
>
> Encerra o SO (shutdown) e para, ou seja, não desliga o
Desconfio que:
1) shutdown
Encerra o SO.
2) halt
Encerra o SO (shutdown) e para, ou seja, não desliga o hardware.
3) poweroff
Encerra o SO (shutdown) e desliga o hardware.
No Debian (10.10) os comandos shutdown, halt e poweroff são uma
referência (link) simbólica para o comando: systemctl
Le jeudi 09 septembre 2021 à 12:24 -0300, Sinval Júnior a écrit :
> nunca vi em máquinas i386, contudo era bastante comum em
> arquiteturas, SUN
Tinha Sun i386, mas imagino que fosse outro nível também.
> IBM, SPARC, usando o comando halt, podíamos
> inclusive trocar alguns processadores,
Leandro, nunca vi em máquinas i386, contudo era bastante comum em
arquiteturas, SUN, IBM, SPARC, usando o comando halt, podíamos inclusive
trocar alguns processadores, memória...Antigamente essas arquitetura eram
bastante usadas em storage etc... Atualmente não sei como funciona. Com
relação à
9 set 2021 9:21 −3, Sinval Júnior:
> poderá fazer sentido, pelo menos em computadores antigos, efetuar
> alguma manutenção
Que manutenção faz‐se sem sistema operacional mas com a máquina
ligada? O mais próximo que consigo imaginar seria ou /firmware/,
que exige a reinicialização até onde eu
9 set 2021 à 7:37 −3, Vitor Hugo:
> no caso de se utilizar um Wake-On-Lan seria mais aconselhável
> utilizar o halt uma vez que a maquina não ficará desligada
> totalmente?
Não, a máquina fica completamente ligada, só sem sistema operacional
ativo. O nível de energização, digamos assim, que
Entendo, no caso de se utilizar um Wake-On-Lan seria mais aconselhável
utilizar o halt uma vez que a maquina não ficará desligada totalmente?
Obrigado;
Em 08/09/2021 17:33, Guimarães Faria Corcete DUTRA, Leandro escreveu:
Il giorno mer 8 set 2021 alle ore 16:03 Vitor Hugo
ha scritto:
Boa
Boa tarde, o halt seria hibernar a maquina?
Em 08/09/2021 15:54, Leandro Guimarães Faria Corcete DUTRA escreveu:
Le mercredi 08 septembre 2021 à 09:08 -0300, Vitor Hugo a écrit :
Qual a diferença entre halt, shutdown e poweroff?
Simplesmente evocações diferentes da mesma ação, mas o halt não
Il giorno mer 8 set 2021 alle ore 16:03 Vitor Hugo
ha scritto:
>
> Boa tarde, o halt seria hibernar a maquina?
Não. Como disse, é a mesma coisa que os outros, mas sem desligar a
máquina. Ou seja, encerra o sistema operacional, mas deixa a máquina
ligada. Não vejo muita utilidade, na minha
Le mercredi 08 septembre 2021 à 09:08 -0300, Vitor Hugo a écrit :
> Qual a diferença entre halt, shutdown e poweroff?
Simplesmente evocações diferentes da mesma ação, mas o halt não desliga
a máquina, enquanto o shutdown e o poweroff sim.
--
Leandro Guimarães Faria Corcete DUTRA
Qual a diferença entre halt, shutdown e poweroff?
On Thu, Sep 10, 2020 at 12:15:56PM +, Long Wind wrote:
3rd installation failure is probably not caused by problem disk
but 1st and 2nd installation failure is
Almost certainly not. Turning off *is not* a symptom of a bad disk. You
have at least a cooling issue, and who knows what other
On Thu, Sep 10, 2020 at 12:36:21PM +, Long Wind wrote:
i've been warned "Core temperature above threshold" for a long time
i just ignore it. probably it isn't cause of shutdown
if it is, it can warn explicitly in /var/log that it will shutdown
surely it can beep before shutd
i've been warned "Core temperature above threshold" for a long timei just
ignore it. probably it isn't cause of shutdownif it is, it can warn explicitly
in /var/log that it will shutdownsurely it can beep before shutdown, but i
didn't hear any beep
it shutdown unexpectedly, it me
On Thursday, September 10, 2020, 8:03:16 AM EDT, Michael Stone
wrote:
there was never anything reported that sounded remotely like a hard disk
problem.
3rd installation failure is probably not caused by problem diskbut 1st and 2nd
installation failure is
the pc is stable, it
On Thu, Sep 10, 2020 at 12:03:22PM +0200, Marco Möller wrote:
After you recently already have had difficult to explain problems with
a hard disk,
there was never anything reported that sounded remotely like a hard disk
problem.
as pc maintenance. i have removed heat sink but
unable to install back. before that i have tested memory with
memtest86+, it quickly shutdown. i think it's not memory's fault, if it
is memtest86+ shall report error in red.
Of course your hardware needs all fans clean and also the thermal
heat sink but unable
to install back. before that i have tested memory with memtest86+, it quickly
shutdown. i think it's not memory's fault, if it is memtest86+ shall report
error in red.
Long Wind composed on 2020-09-10 04:52 (UTC):
> possible cause : cpu too hot?
> Sep 10 00:00:54 debian kernel: [ 9858.515989] CPU0: Core temperature/speed
> normal
> Sep 10 00:15:46 debian kernel: [10751.125312] CPU0: Core temperature/speed
> normal
> Sep 10 00:20:50 debian kernel:
On Ma, 14 iul 20, 12:04:51, basti wrote:
> Hello, when i try to shutdown from my lxde session i get:|
>
> GDBus.Error:org.freedesktop.DBus.Error.InteractiveAuthorizationRequired:
> Interactive authentication required.
Hmm, this worked for me out of the box. Is your user a mem
Hello, when i try to shutdown from my lxde session i get:|
GDBus.Error:org.freedesktop.DBus.Error.InteractiveAuthorizationRequired:
Interactive authentication required.
When i frist logout then I can Shutdown from ligthdm.
OS: Debian Buster
Best Regards
|
On Mon, 18 May 2020 11:24:17 +0200
Frank Weißer wrote:
Hello Frank,
>Everytime I start my workstation (DebianEdu 9) I have to re-run setup
>of the HP Device Manager , because the LaserJet Pro 200 color,
>connected via network, is lost. The setup routine dousn't need to
>connect to hp again, as
Hi!
Everytime I start my workstation (DebianEdu 9) I have to re-run setup of
the HP Device Manager , because the LaserJet Pro 200 color, connected
via network, is lost. The setup routine dousn't need to connect to hp
again, as id did at the first installation of the printer.
Where do I have
On Tue, 15 Oct 2019 17:03:19 +1100
Keith Bainbridge wrote:
> Also, there is a process to get one PC to download the updates, and
> share that /var/cache/apt/archives/ to your other PCs
You might look into apt-cacher or apt-cacher-ng for that.
--
Does anybody read signatures any more?
this (not sure if it's your issue or not):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837155
If /var resides on a separate file-system which is unmounted before
unattended-upgrade-shutdown is run, it may repeatedly (by default for
10 minutes) try to acquire it's lock-file but fail since
's this (not sure if it's your issue or not):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837155
If /var resides on a separate file-system which is unmounted before
unattended-upgrade-shutdown is run, it may repeatedly (by default for
10 minutes) try to acquire it's lock-file but fail since
Le 15/10/2019 à 09:19, Yvan Masson a écrit :
Le 15/10/2019 à 08:03, Keith Bainbridge a écrit :
On 15/10/19 11:31 am, Keith Bainbridge wrote:
How to prevent a repeat is the real question. My only suggestion is
extend the time-out, but how long. Maybe run manual upgrades on one
machine every
Le 15/10/2019 à 08:03, Keith Bainbridge a écrit :
On 15/10/19 11:31 am, Keith Bainbridge wrote:
How to prevent a repeat is the real question. My only suggestion is
extend the time-out, but how long. Maybe run manual upgrades on one
machine every day, before shutting down the others??
On 15/10/19 11:31 am, Keith Bainbridge wrote:
How to prevent a repeat is the real question. My only suggestion is
extend the time-out, but how long. Maybe run manual upgrades on one
machine every day, before shutting down the others??
There was a response suggesting getting cron to run
On Tue, 15 Oct 2019 11:31:22 +1100
Keith Bainbridge wrote:
> It was intuition rather than any knowledge I had - beyond the fact
> that sometimes upgrade takes longer than normal.
>
> How to prevent a repeat is the real question.
Upgrades and updates often require fetching across the network,
On 14/10/19 7:42 pm, Yvan Masson wrote:
You were right Keith: after applying some updates manually, remaining
updates are
properly installed with unattended-upgrade… Now I need to understand
what was
blocking.
It was intuition rather than any knowledge I had - beyond the fact that
12/10/2019 à 18:45, Yvan Masson a écrit :
Hi list,
I configured some Buster desktops in a school to upgrade
automatically on shutdown via unattended-upgrades. I am almost sure
it worked at first but it does not anymore. I would really appreciate
any suggestion as I already spent a few hours
,
I configured some Buster desktops in a school to upgrade automatically
on shutdown via unattended-upgrades. I am almost sure it worked at
first but it does not anymore. I would really appreciate any
suggestion as I already spent a few hours on this issue without any
result.
Symptoms
1 - 100 of 2323 matches
Mail list logo
