Re: [SOLVED] System broken after yesterday's upgrade

[solitone]

On Thursday, 13 April 2017 12:44:06 CEST solitone wrote:
>  I tried and reset NVRAM, a nonvolatile random-access memory that
> Macs use to store certain settings like sound volume, display resolution,
> and (I realise only now) startup disk selection.. and GRUB doesn't start
> any longer, it boots up directly into MacOS.
> 
> After that, I also reset the System Management Controller (SMC) and at least
> now the initial bootup phase into MacOS is much quicker.
> 
> Now I managed to restore GRUB, using the rescue mode option of my
> installation USB stick. Everything is as before: very slow keystrokes
> response in grub, integrated keyboard and mouse working after some time in
> login screen only when external usb mouse and keyboard plugged in (both of
> them!)
> 
> I've noticed that also Apple Startup Manager suffers from the same issue
> that GRUB has: I press keys and it responds after tens of seconds! Trackpad
> is also very slow or doesn't work at all. I need to check my updates on
> Apple side..

The thing I didn't explain there is that after I reset the SMC, MacOS boot 
seemed to be quicker, however it still tooked 30 seconds or more to start the 
Startup Manager when pressing the alt button at startup. Besides, Startup 
Manager responded very slowly to keypresses, and the trackpad didn't work, or 
was really slow. This clarifies the issue wasn't a consequence of reinstalling 
GRUB, and I suspected it depended either on Apple's hardware or in some low 
level Apple software component.

I found a few posts around that described exactly the same problem I had, like 
this one:
https://apple.stackexchange.com/questions/270248/macos-startup-manager-is-very-slow-and-laggy

Some people said that MacOS Siera 10.12.4 would solve that issue. So I tried 
and upgraded (I was on 10.12.3), and I can confirm it is indeed true. That 
system update must contain also a firmware update that addresses that I/O 
issue. Now everything works very well again.

Re: Fecha de última modificación de archivos

[Esteban Monge]

Hola:

Hay una aplicación que se llama photorec esa permite recuperar archivos luego 
de borrar archivos, conserva la ultima fecha de modificación.

Si has formateado el disco puede recuperar la partición con testdisk.

Ambas herramientas son muy buenas y son de la misma gente , pero tienen el 
inconveniente de que si se ha escrito en el disco datos, la información se 
perderá, existen empresas que cobran muy caro para recuperar ese tipo de datos.

Puede instalarlo en Debian con:
$ sudo apt-get install testdisk

La página de ellos es:
http://www.cgsecurity.org/

Debes de tener un segundo disco en el cual recuperar los archivos para 
garantizar la mayor cantidad de archivos.

On April 14, 2017 4:50:11 PM CST, laura  wrote:
>2017-04-13 17:54 GMT+02:00 JavierDebian
>:
>
>> El 12/04/17 a las 21:39, luis godoy escribió:
>>
>>> Una consulta, en una instalación nueva es posible encontrar archivos
>con
>>> distintas fechas?  Por ejemplo de hace 6 meses atras, y con disco
>duro
>>> formateado antes de la instacion.
>>>
>>
>> Sí.
>> La instalación copia archivos, y mantiene la fecha original de los
>mismo.
>>
>> JAP
>>
>
>
>
>aunque hayas formateado para reinstalar? el instalador copia archivos
>antes
>del formateo?
>
>
> laura

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Possibly erroneous "device not present" message during boot

[David Wright]

On Fri 14 Apr 2017 at 12:05:38 (-0500), Richard Owlett wrote:
> On 04/13/2017 05:55 PM, Brian wrote:
> >On Thu 13 Apr 2017 at 20:05:22 +0200, Pascal Hambourg wrote:
> >
> >>David is right : you don't really boot from the SD card.
> >
> >The OP never claimed he was booting from the SD card. He particularly
> >said he did not install GRUB to the card.
> >
> >>GRUB is on the HDD. The kernel is on the HDD. Only the root filesystem is on
> >>the SD card.
> >
> >Yes. That's what the linux line says too.
> >
> 
> I'll try to clarify some details.
> 
> My installation protocol.
>  1. I always use "Expert" as that way the installer will
> do fewer things I'm not aware of.
>  2. I only install Grub the *first* time I do a Debian install.
> By poor design Grub puts the current install first on menu.

When are you going to let this drop?

On Thu, 05 Jul 2012 08:23:19 (-0500), Richard Owlett wrote:

| What I need:
|   1. newest install to be on bottom of the list

On Sat, 24 Nov 2012 15:33:49 (-0600), Richard Owlett wrote:

| The GRUB team made many reasonable design decisions.
| Though they match vast MAJORITY of users, their choices annoy me every
| time I boot ;<
|
| What would fit best with my habits is that the precedence of OS to
| boot would be
| "first installed -> first boot choice" *NOT* "last installed -> first
| boot choice".

On Sat, 02 Feb 2013 08:47:37 (-0600), Richard Owlett wrote:

| The latest installation goes to the top of the displayed list and is
| also selected as the default OS to boot.
| That is unsatisfactory as the first OS will will always be closest to
| a standard install - i.e. most likely to run.

On Sun, 24 Jul 2016 13:53:59 (-0500), Richard Owlett wrote:

| What I *REQUIRE* is that GRUB2's menu list available OS monotonically
| by partition number. For reasons of logic and sanity the menu items
| should be in the order of
| sda1, sda2, ..., sdaMAX. I could work with sdaMAX, ..., sda2, sda1 .
|
| The purpose AND rationale SHALL be that the default OS choice *SHALL
| BE* the first OS installed.



> When experimenting with configuration as I do, the least
> likely install to be functional is the latest.
> This requires me to run update-grub on the "good" install.
>  3. Similarly a swap partition is specified only on the first
> install as the installer insists on destroying the UUID of
> the existing swap partition. It is simpler to edit only the
> fstab of latest install than to edit those for all other
> installs each time.
>  4. All installs in this thread have been done using DVD 1 of
> 13 of Debian 8.6.0 - thus all intrinsically use the same
> kernel.
> 
> I've done some additional observations and test installs.
> 1. The BIOS of the Lenovo T510 can be directed to boot from
>the CD/DVD drive, hard disk, or any attached USB flash
>drive. It *cannot* be directed to boot from the SD card.
> 2. I did an install to a USB flash drive including installing
>Grub2 to the MBR of that flash drive. When selecting the
>SD card from the grub menu I see nothing different.
> 3. I did a new install to the SD card specifying a different set
>of packages and installing grub to the MBR of the SD card.
>Once again no behavioral difference.

Observation 1 would make that inevitable, wouldn't it. Unless, of
course, you stick your SD card in a card reader. These little gizmos
used to be bundled with SD cards when you bought them; I don't know if
they still are. I have a large one that came free with the first
(only) SD card I bought, and a couple of tiny ones that came with
SDmicros bought a long while back. The latter also come with
converters so that you can put an SDmicro in the SD reader or an SD
slot.

> Does any of this justify a bug report. Especially as I do not
> have the bandwidth to do a netinstall of a pre-release version?

You've posted your grub.cfg but I haven't bothered to try and
reverse engineer how you produced it. I haven't seen any
behaviour yet that I would call a bug. What did you have in mind?
You could say whether you think the bug is in the _generation_ of
grub.cfg or in its _execution_ when you boot.

Cheers,
David.

Re: Possibly erroneous "device not present" message during boot

[David Wright]

On Fri 14 Apr 2017 at 20:02:11 (-0400), songbird wrote:
> Richard Owlett wrote:
> ...
> [file a bug?]
> 
>   i'm not sure this is a bug.  you've
> done an expert install, but not let grub
> finish so by my estimate you've left the
> install where manual patching is needed.

I would agree with that. It's not clear to me why an SD is being used
in this way as the OP has at last revealed that the computer is unable
to boot from an SD plugged in directly. (Of course, an SD card can be
made to look like a USB stick just by sticking it in a card reader.
Then it will boot.)

>   right now this thread is showing up via
> go ogle so people will find it if they have
> similar issues and they can maybe sort it
> out.
> 
>   what i would do for grins is unplug the
> devices other than the SSD and the installation 
> media and then do a base system (simple install 
> - not expert) and see what the installer does 
> detect and writes in the fstab and grub menu 
> (it may even boot).  you may then use those 
> things in the previously installed grub and
> fstab files (for the system which boots and
> runs but does not mount the SSD).

Googling may now throw up this thread when people are searching for
SSD installation. SSDs are a different animal from SD cards.

Cheers,
David.

Re: Possibly erroneous "device not present" message during boot

[songbird]

Richard Owlett wrote:
...
[file a bug?]

  i'm not sure this is a bug.  you've
done an expert install, but not let grub
finish so by my estimate you've left the
install where manual patching is needed.

  right now this thread is showing up via
go ogle so people will find it if they have
similar issues and they can maybe sort it
out.

  what i would do for grins is unplug the
devices other than the SSD and the installation 
media and then do a base system (simple install 
- not expert) and see what the installer does 
detect and writes in the fstab and grub menu 
(it may even boot).  you may then use those 
things in the previously installed grub and
fstab files (for the system which boots and
runs but does not mount the SSD).

  if you do this report the contents of the 
fstab and the grub.cfg


> Especially as I do not
> have the bandwidth to do a netinstall of a pre-release version?

  that's really unfortunate.


  songbird

Re: Inittab

[Elias Albuquerque de Oliveira]

Muito obrigado, testarei.Le 14 avr. 2017 12:35, Elias Albuquerque de Oliveira  a écrit :Bom dia pessoal.Faz muitos anos que não mexia com linux e estou voltando, ainda bem.Porem estou usando debian e me incomoda muito que tudo inicia em interface grafica.Antigamente eu pegava o inittab e colocava init 3 e tudo se resolvia.Onde foi parar o inittab e como faço para não subir a interface grafica direto, somente se eu digitar starx.Gostaria de uma ajuda, não achei nada muito interessante na net.Att.

Other's opinions about best/safest method to migrate LUN's while online

[Joshua Schaeffer]

Howdy all,

We are planning on migrating several LUN's we have on an oracle box to a
new NetApp all flash storage backend. We've gone through a few tests
ourselves to ensure that we don't cause impact to the box and everything
has been successful so far. The server will remain up during the migration
and we are not planning on bring down any services. I just wanted to see if
others had any similar experience and wouldn't mind sharing. Particularly,
does anyone see any steps that might cause impact, halt the box, or cause
path's to fail where the storage itself becomes unavailable. This is our
current high level steps:


   1. Zone the host to include the new HA NetApp pair *[no impact, no
   server changes, only SAN fabric additions (very safe)]*
   2. Create a volume on the destination HA NetApp pair *[no impact, no
   server changes (very safe)]*
   3. Validate the portset on NetApp to include the destination HA pair *[no
   impact, no changes, verification only (very safe)]*
   4. Add reporting nodes to LUN *[no impact, no server changes, NetApp
   additions only (very safe)]*
   5. LUN scan each HBA individually ($echo "- - -" >
   /sys/class/scsi_host/host3/scan && sleep 5 && echo "- - -" >
   /sys/class/scsi_host/host4/scan) *[Should not cause impact (generally
   safe)]*
   6. Validate that 8 new non-optimized paths now appear on the server
   ($multipath -ll) *[no impact, command does not make changes (very safe)]*
   7. Validate the new paths are secondary ($sanlun lun show -p -v) *[no
   impact, command does not make changes (very safe)]*
   8. Perform the NetApp LUN move *[no impact, no server changes (very
   safe)]*
   9. Remove the reporting nodes from LUN *[no impact, no server changes,
   NetApp deletion only (generally safe)]*
   10. Validate the 8 original paths are now failed ($multipath -ll) *[no
   impact, command does not make changes (very safe)]*
   11. Validate that Linux automatically sees 4 optimized paths among the 8
   new paths ($sanlun lun show -p -v) *[no impact, command does not make
   changes (very safe)]*
   12. Delete the failed paths (echo 1 > /sys/block/sdX/device/delete) *[Should
   not cause impact (generally safe)]*

My only concern is related to part of some Red Hat documentation I came
across [1] that states the following:

"interconnect scanning is not recommended when the system is under
memory pressure. To determine the level of memory pressure, run the
command vmstat
1 100; interconnect scanning is not recommended if free memory is less than
5% of the total memory in more than 10 samples per 100. It is also not
recommended if swapping is active (non-zero si and so columns in the
vmstat output).
The command free can also display the total memory."

These oracle boxes typically have all their memory used (I see the cached
39G).

[root@oraspace01 ~]# free -g
 total   used   free sharedbuffers
cached
Mem:   188187  1  0  0
39
-/+ buffers/cache:147 41
Swap:   79  0 79

I'm not an oracle DBA so I don't know a lot of specifics about their
inter-workings, but from what I understand some oracle systems/processes
can use all the memory a machine has, no matter how much you give it. I've
seen ZFS and VMWare do this as well. They claim a large amount of memory,
but aren't using it until they actually need it. It's more efficient and
allows for higher throughput and processing. So the fact that free thinks
the machine is low on memory isn't really an issue for me, I'm just
concerned with the documentation shown earlier.

Does anyone know if running a scan on the SCSI bus while the system thinks
there isn't much available memory would cause issues? Has anyone done
similar types of migrations (doesn't have to be with NetApp). In essence
all we are doing is presenting additional paths temporarily, moving the
storage, then deleting the old paths. Is there a better way to delete
paths? A rescan of the SCSI bus only adds paths (at least from what I found
and read). Anybody have some nifty or cleaver step to add that makes things
easier/safer/better/faster/etc?

Thanks,
Joshua Schaeffer

[1]
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/scanning-storage-interconnects.html

Re: Fecha de última modificación de archivos

[laura]

2017-04-13 17:54 GMT+02:00 JavierDebian :

> El 12/04/17 a las 21:39, luis godoy escribió:
>
>> Una consulta, en una instalación nueva es posible encontrar archivos con
>> distintas fechas?  Por ejemplo de hace 6 meses atras, y con disco duro
>> formateado antes de la instacion.
>>
>
> Sí.
> La instalación copia archivos, y mantiene la fecha original de los mismo.
>
> JAP
>



aunque hayas formateado para reinstalar? el instalador copia archivos antes
del formateo?


 laura

Re: Systemd services (was Re: If Linux Is About Choice, Why Then ...)

[Joel Rees]

On Fri, Apr 14, 2017 at 9:37 PM, Greg Wooledge  wrote:
> [...]
>Don't even get me started on sshd.service vs. ssh.service.  Do you
>have any idea how hard it is to notice that extra/missing "d", and
>figure out why things Simply Do Not Work?

Well, that demonstrates that the concept of tagging a "d" on the end
of a name to indicate the daemon part well predates systemd, and
probably should be reconsidered in a world where short names are no
longer required.

Not sure how that relates to the rest of the issues you are trying to
work through.

-- 
Joel Rees

I'm imagining I'm a novelist:
http://joel-rees-economics.blogspot.com/2017/01/soc500-00-00-toc.html
More of my delusions:
http://reiisi.blogspot.jp/p/novels-i-am-writing.html

Re: Exim4 problem?

[Charlie]

On 14/04/2017, deloptes  wrote:
> Charlie wrote:
>
>> It doesn't matter. This system needs to be reinstalled, so I won't
>> bother with updates and upgrades and when I reinstall it, I will
>> remove exim4 right from the word go and see how that works.
>
> you could identify the reason for the misbehavior by looking at paniclog
> and
> mainlog
>
> but proceed as you wish
>
> regards

Thank you for your help and advice. There was no enlightenment that
would assist me in those either of those.

Everything is working well. One thing I have noticed working even
better since purging exim4, but that could also be due to the updates
installed. When I rebuild this system I will think twice before
installing exim again.

It's all good. Thank you.
Charlie

Re: Possibly erroneous "device not present" message during boot

[Pascal Hambourg]

Le 14/04/2017 à 19:05, Richard Owlett a écrit :


 2. I only install Grub the *first* time I do a Debian install.
By poor design Grub puts the current install first on menu.


It's not poor design. It is perfectly normal that the system which 
installs GRUB is first in the menu. If you don't like it, you can change it.



When experimenting with configuration as I do, the least
likely install to be functional is the latest.


When experimenting, it is wise not to replace the existing working boot 
loader with a new one which depends on the newly installed system. It 
has nothing to do with GRUB's supposedly poor design.



 3. Similarly a swap partition is specified only on the first
install as the installer insists on destroying the UUID of
the existing swap partition.


No, it doesn't insist. It just marks the existing swaps as to be used by 
default, which in turns marks them to be formatted with a new UUID. You 
are free to mark them as not to be used and they won't be reformatted. 
It just insist on using a swap, but it does not have to be any of the 
existing ones.



Does any of this justify a bug report.


No. The only bug is that the system installed on the SD card boots while 
it should not.

Re: If Linux Is About Choice, Why Then ...

[Joel Rees]

On Fri, Apr 14, 2017 at 6:46 PM, Nicolas George  wrote:
> Le quintidi 25 germinal, an CCXXV, Joel Rees a écrit :
>> > Summary: Linux has a new system call to allow process to register as
>> > adopters for orphan processes.
>> Ick. I hope they don't register directly with pid1.
>
> I am sorry, but that does not even make sense.

Well, this is where the conversation does seem to fall apart.

I'm looking at the problem from the point of view of someone who has
seen the ins and outs of an engineering principle called complexity. I
know enough about complexity to understand that you cannot guarantee
response time without properly constraining certain processes -- or,
perhaps I should say, supported recurring paths of execution, because
you might think I mean a specific entity with a process id on a Unix
system, and systemd itself is an example of a unix system process that
has multiple actual supported recurring paths of execution.

>> Or you could have pid1 monitor only the monitoring process, to keep pid1 
>> simple.
>
> Or you could have PID 1 monitor a process that monitors a process that
> monitors a process that monitors a process that monitors the monitoring
> process.

Talk about strawman arguments.

If you care to listen, I am not saying add process redirection to
process redirection ad infinitum. There are, of course, limits to what
one can do that direction, as well, and caution has to be applied in
constructing the redirections.

What I'm suggesting does require changes to the kernel. In particular,
16 bits of process id is not enough.

How we change that requires some thought, but it is not enough.

Systemd already takes a certain approach. Actually, it appears that
they are trying two, maybe three approaches. Ultimately it will have
to end up being able to resolve the identity of a process at a greater
resolution of 1 in 2^16, and distinguish between processes in
different ways than just the arbitrary distinction between threads and
processes, and the arbitrary distinction between system and user.

> Sorry, I do not share your religious imperative of keeping PID 1 simple
> at the cost of making everything else more complex.

It is easy to call things you don't want to think about "religious".
Doing so doesn't solve any problems.

If I had time, maybe I could construct a demonstration of the problem
of complexity that would make the issues clear.

But the demonstrations do exist already.

>> pid1 seems to be doing a lot of other things in systemd. Is it
>> cooperatively multitasking with itself yet? Or have they borrowed
>> threads to define a new kind of process concept, so that pid1 can
>> multitask with itself preemptively?
>>
>> I should go look at the source to see, I suppose
>
> Obviously you find burning straw men more entertaining. Please go ahead,
> I will try not to trouble further.

Working out the set of possible execution paths that a critical
process can take may look like burning straw men to you, or it may
look like wasting time in strawman arguments to you. It appears to
look like a waste of time to many people in management.

I do hope that what you are saying is that you assume that Poettering
and company at least are walking through an informal analysis of the
execution paths in systemd. (Formal analysis would be preferred.)

Otherwise, your reference in other branches of this conversation to
guarantees better than "most of the time" would seem rather, I hate to
use the word, but there it is -- duplicitous.

-- 
Joel Rees

I'm imagining I'm a novelist:
http://joel-rees-economics.blogspot.com/2017/01/soc500-00-00-toc.html
More of my delusions:
http://reiisi.blogspot.jp/p/novels-i-am-writing.html

Re: comment faite-vous pour installer flashplayer?

[Marc]

En suivant les commentaires de ce fil j'ai décompressé et copié le 
fichier dans ~/.mozilla/plugins (que j'ai créé) et ça marche top !


Merci pour vos échanges toujours intéressant.


On 14/04/2017 19:50, Jean Bernon wrote:
Alex au départ de ce fil de discussion notait qu'il avait décompressé 
libflashplayer.so mais qu'il n'y avait plus de dossier 
~/mozilla/plugins où le mettre.
Personnellement je le copie effectivement dans 
/usr/lib/flashplugin-nonfree à chaque nouvelle version et ça marche bien.




*De: *"hamster" 
*À: *debian-user-french@lists.debian.org
*Envoyé: *Vendredi 14 Avril 2017 15:23:49
*Objet: *Re: comment faite-vous pour installer flashplayer?

Le 14/04/2017 à 15:17, Stephane Ascoet a écrit :
> Le 05/04/2017 à 18:26, hamster a écrit :
>> Le 05/04/2017 à 17:54, Haricophile a écrit :
>>> De fait j'ai assez longtemps utilisé la méthode de télécharger
le >
>>> .tar.gz chez Adobe, de le décompresser et de copier le .so dans >
>> ~/.mozilla/plugins
>>
>> Aaaahhh, merci pour cette astuce d'une grande simplicité et qui
>> marche. En effet, c'est hallucinant qu'on passe autant de temps et
>> d'énergie pour mettre en place un système qui va simplement…
copier un
>> fichier.
>>
>> Pour les mises a jour, vu que de toutes facons il faut les
faire a la
>> main, autant refaire la copie du .so plutot que refaire
>> update-pepperflashplugin-nonfree --install
>>
>
> J'ai telecharge l'archive depuis
https://get.adobe.com/flashplayer/ mais
> a l'interieur il y a juste des trucs pour KDE que je n'utilise pas.

Heu non. Quand tu décompresse, ca te fait un dossier
"flash_player_npapi_linux.x86_64" avec dedans :
- un dossier LGPL avec la licence (a ignorer)
- un dossier usr avec des trucs pour kde (a ingorer)
- un fichier libflashplayer.so
- un fichier licence.pdf
- un fichier readme.txt

Tu prend le fichier libflashplayer.so, tu le met dans un dossier
~/.mozilla/plugins et ca marche. Y'a rien d'autre a faire.

Re: Postfix Dovecot et SSL : SSL23: unknown protocol

[andre_debian]

On Tuesday 04 April 2017 10:43:15 Thierry Bugier Pineau wrote:
> le sujet a achevé de me motiver pour m'y remettre aussi. D'où mon
> silence.  J'ai préparé postfix, je continue avec Dovecot dans les jours
> à venir et ensuite je m'attaque au TLS pour atteindre le même niveau de
> progression et donner un coup de main.
> J'essaie aussi de créer un script shell (très sommaire) pour rendre la
> configuration maintenable et reproductible (que je partagerai
> volontiers sur github).

On Tuesday 04 April 2017 14:12:45 andre_deb...@numericable.fr wrote:
> Je l'attends avec plaisir, merci d'avance.
> Ça fait longtemps que dovecot + certificats me posent soucis... :-)
> Bonne journée,  André

Je n'ai pas reçu de réponse à cette promesse ci-dessus... :-)

André

Re: Inittab

[Rodolfo]

Olá Ricardo,

somente apontei sugestões, não recomendei desinstalar, na verdade, sugeri
que não remova, releia o que escrevi.

Abraços.

Em 14 de abril de 2017 12:44, Ricardo Ramos 
escreveu:

> Olá Rodolfo,
>
> Penso que não há necessidade de desinstalar o lightdm (nem gdm ou kdm), se
> o que ele necessita é somente de desactivar o modo gráfico ele pode mudar o
> runtime (agora chamado de target por causa do systemd).
>
> Para isso ele só precisa de apontar o default target de graphical para
> multi-user com o seguinte comando.
>
> # ln -s /lib/systemd/system/multi-user.target /lib/systemd/system/default.
> target
>
> Esse comando muda o link do arquivo default.target que o systemd usa para
> saber qual "runtime"/target ele deve iniciar.
>
> Para mais informações use o comando abaixo para ver mas informações sobre
> o equivalente ao inittab do systemd.
>
> # man runlevel
>
> A Sex, 14 de abr de 2017, 17:01, Rodolfo  escreveu:
>
>> Olá Elias,
>>
>> primeira coisa a se fazer é remover ou desabilitar o atual gerenciador de
>> sessão, existem gdm3, lightdm, kdm, etc, por padrão, se não me engano, o
>> que vem instalado no Debian Jessie é o ligthdm, você precisa desinstalar
>> ele ou desabilitá-lo:
>>
>> Desinstalar:
>>
>> # apt-get remove --purge ligthdm
>>
>> ou pode fazer melhor, que não remove, caso precise um dia:
>>
>> Parar o serviço da interface gráfica:
>>
>> # systemctl stop ligthdm
>>
>> Impedir que o mesmo seja inicializado durante o boot:
>>
>> # systemctl disable ligthdm
>>
>> Fazendo isso o mesmo não irá mais iniciar a interface gráfica(acredito eu
>> '-'), porém nunca fiz isso, na teoria deve funcionar, teste e veja se
>> funciona.
>>
>> As atuais versões do Debian vem por padrão agora com o Systemd(antes era
>> o Sysvinit), tornando algumas tarefas diferentes do que éramos acostumados,
>> porém na minha opinião ficou mais simples algumas coisas. Enfim, boa sorte
>> :D
>>
>> Abraços.
>>
>>
>> Em 14 de abril de 2017 11:35, Elias Albuquerque de Oliveira <
>> elias_albuquer...@yahoo.com.br> escreveu:
>>
>>> Bom dia pessoal.
>>> Faz muitos anos que não mexia com linux e estou voltando, ainda bem.
>>> Porem estou usando debian e me incomoda muito que tudo inicia em
>>> interface grafica.
>>> Antigamente eu pegava o inittab e colocava init 3 e tudo se resolvia.
>>> Onde foi parar o inittab e como faço para não subir a interface grafica
>>> direto, somente se eu digitar starx.
>>> Gostaria de uma ajuda, não achei nada muito interessante na net.
>>> Att.
>>>
>>
>> --
>
> Ricardo Ramos
> Tel: +244 927 953 770 <+244%20927%20953%20770>
> Email: cesar.ricki...@gmail.com
> Website: www.rickinho.com
> Técnico de Informática
>

Re: Systemd services (was Re: If Linux Is About Choice, Why Then ...)

[Jonathan de Boyne Pollard]

Greg Wooledge:
> Don't even get me started on sshd.service vs. ssh.service.  Do
> you have any idea how hard it is to notice that extra/missing “d”, 
> and figure out why things Simply Do Not Work?

* http://www.mail-archive.com/supervision@list.skarnet.org/msg01486.html

* https://unix.stackexchange.com/a/303302/5132

Yes.

Re: Possibly erroneous "device not present" message during boot

[Richard Owlett]

On 04/14/2017 12:33 PM, Brian wrote:

On Thu 13 Apr 2017 at 10:58:10 -0500, Richard Owlett wrote:


On 04/12/2017 01:49 PM, songbird wrote:


 another thing you can do is construct your own
menu entry and put it in /etc/grub.d/40_custom file


I don't see that being informative for this problem.


Quite the opposite; this is a very useful suggestion. Imagine that
update-grub didn't give you something workable. You would (or should)
be glad of the opportunity to roll your own. I do it all the time with
removable devices.

In your case, if grub-install had given you a "root=" line in a stanza
it is possible you would not be booting the SD card. A 40_custom file
needn't have it in.



I'll add it to my TODO list.
I've never attempted to edit /etc/grub.d/40_custom file or its cousins.
I've just received some need documentation for something I'm doing for 
someone else.

Anyone have a few spare 100 hour days ;/

Re: Possibly erroneous "device not present" message during boot

[Brian]

On Fri 14 Apr 2017 at 12:05:38 -0500, Richard Owlett wrote:

> On 04/13/2017 05:55 PM, Brian wrote:
> >On Thu 13 Apr 2017 at 20:05:22 +0200, Pascal Hambourg wrote:
> >
> >>David is right : you don't really boot from the SD card.
> >
> >The OP never claimed he was booting from the SD card. He particularly
> >said he did not install GRUB to the card.
> >
> >>GRUB is on the HDD. The kernel is on the HDD. Only the root filesystem is on
> >>the SD card.
> >
> >Yes. That's what the linux line says too.
> 
> I'll try to clarify some details.

Your previous descriptions were good; clarification cannot do any harm.

> My installation protocol.
>  1. I always use "Expert" as that way the installer will
> do fewer things I'm not aware of.

Very wise. If you are familiar with each stage of the installation you
can more more easily spot anomalies. "Expert"=="more control".

>  2. I only install Grub the *first* time I do a Debian install.
> By poor design Grub puts the current install first on menu.
> When experimenting with configuration as I do, the least
> likely install to be functional is the latest.
> This requires me to run update-grub on the "good" install.

That's ok. I tend to be more promiscuous; usually on a whim, like
wanting to put a particular entry at the top of GRUB's menu list.

When you do 'update-grub' do you still get no "set root=" line for the
SD card in the grub.cfg?

>  3. Similarly a swap partition is specified only on the first
> install as the installer insists on destroying the UUID of
> the existing swap partition. It is simpler to edit only the
> fstab of latest install than to edit those for all other
> installs each time.

That's ok too. I often don't bother with a swap partition. Some of my
machines have less than 4 GB of disk space. I see space for packages as
more important than swap space. 

>  4. All installs in this thread have been done using DVD 1 of
> 13 of Debian 8.6.0 - thus all intrinsically use the same
> kernel.

Yes.

> I've done some additional observations and test installs.
> 1. The BIOS of the Lenovo T510 can be directed to boot from
>the CD/DVD drive, hard disk, or any attached USB flash
>drive. It *cannot* be directed to boot from the SD card.

I'm at a disadvantage here. I do not have an SD card. I do not have a
USB hub. However, I thought USB sticks and SD cards were the same (or
at least similar) when it came to booting.

> 2. I did an install to a USB flash drive including installing
>Grub2 to the MBR of that flash drive. When selecting the
>SD card from the grub menu I see nothing different.

Does that not substantiate what I said just now? 

> 3. I did a new install to the SD card specifying a different set
>of packages and installing grub to the MBR of the SD card.
>Once again no behavioral difference.

I cannot believe your install to the card would be capable of criticism.

> Does any of this justify a bug report. Especially as I do not
> have the bandwidth to do a netinstall of a pre-release version?

I mentioned "bug" in another mail. I wish I hadn't. It is not that bugs
in GRUB or the Debian grub package do not arise, but I'd want to know
more about SD cards before committing myself.

-- 
Brian.

Re: Possibly erroneous "device not present" message during boot

[Richard Owlett]

On 04/14/2017 12:24 PM, Brian wrote:

On Wed 12 Apr 2017 at 10:14:59 -0500, Richard Owlett wrote:


On 04/12/2017 07:39 AM, songbird wrote:


- the bios may not be set correctly to find the device.


I do not see how the bios might be involved.
Grub2 has been installed to the MBR of /dev/sda .
The only known reference to Grub2 is in the instance of Debian residing on
/dev/sda1 .


Everything GRUB knows about devices comes from what the BIOS tells it.
They are more than just good friends. :)

It appears from 'ls' at a GRUB prompt that your GRUB does not know about
your SD card. Booting takes place but GRUB takes its time to think about
what it should do about not finding something it has been told to search
for. In the end, it decides to go ahead, but in some cases it wouldn't.
That would dispel your present mood of happiness.

While we are it it: your update-grub stanza does not contain a line with
set root=" in it. Could this possibly be a copy and paste error? I ask
because the line is present on Jessie and testing when the device is a
USB stick.



Just to eliminate any source of copy errors, here is the full contents 
of grub.cfg created just prior to my most recent post 
(https://lists.debian.org/debian-user/2017/04/msg00468.html). It refers 
to the 2 new installs I mentioned in that post.





#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 
8fe2965b-01ed-4227-9155-bc3e47ddf077

else
  search --no-floppy --fs-uuid --set=root 
8fe2965b-01ed-4227-9155-bc3e47ddf077

fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=-1
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 
8fe2965b-01ed-4227-9155-bc3e47ddf077

else
  search --no-floppy --fs-uuid --set=root 
8fe2965b-01ed-4227-9155-bc3e47ddf077

fi
insmod png
if background_image /usr/share/images/desktop-base/lines-grub.png; then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class 
gnu --class os $menuentry_id_option 
'gnulinux-simple-8fe2965b-01ed-4227-9155-bc3e47ddf077' {

load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 
8fe2965b-01ed-4227-9155-bc3e47ddf077

else
	  search --no-floppy --fs-uuid --set=root 
8fe2965b-01ed-4227-9155-bc3e47ddf077

fi
echo'Loading Linux 3.16.0-4-686-pae ...'
	linux	/boot/vmlinuz-3.16.0-4-686-pae 
root=UUID=8fe2965b-01ed-4227-9155-bc3e47ddf077 ro  quiet

echo'Loading initial ramdisk ...'

Re: Possibly erroneous "device not present" message during boot

[Brian]

On Thu 13 Apr 2017 at 10:58:10 -0500, Richard Owlett wrote:

> On 04/12/2017 01:49 PM, songbird wrote:
> >
> >  another thing you can do is construct your own
> >menu entry and put it in /etc/grub.d/40_custom file
> 
> I don't see that being informative for this problem.

Quite the opposite; this is a very useful suggestion. Imagine that
update-grub didn't give you something workable. You would (or should)
be glad of the opportunity to roll your own. I do it all the time with
removable devices.

In your case, if grub-install had given you a "root=" line in a stanza
it is possible you would not be booting the SD card. A 40_custom file
needn't have it in.

-- 
Brian.

Re: comment faite-vous pour installer flashplayer?

[Jean Bernon]

Alex au départ de ce fil de discussion notait qu'il avait décompressé 
libflashplayer.so mais qu'il n'y avait plus de dossier ~/mozilla/plugins où le 
mettre. 
Personnellement je le copie effectivement dans /usr/lib/flashplugin-nonfree à 
chaque nouvelle version et ça marche bien. 

- Mail original -

> De: "hamster" 
> À: debian-user-french@lists.debian.org
> Envoyé: Vendredi 14 Avril 2017 15:23:49
> Objet: Re: comment faite-vous pour installer flashplayer?

> Le 14/04/2017 à 15:17, Stephane Ascoet a écrit :
> > Le 05/04/2017 à 18:26, hamster a écrit :
> >> Le 05/04/2017 à 17:54, Haricophile a écrit :
> >>> De fait j'ai assez longtemps utilisé la méthode de télécharger le
> >>> >
> >>> .tar.gz chez Adobe, de le décompresser et de copier le .so dans >
> >> ~/.mozilla/plugins
> >>
> >> Aaaahhh, merci pour cette astuce d'une grande simplicité et
> >> qui
> >> marche. En effet, c'est hallucinant qu'on passe autant de temps et
> >> d'énergie pour mettre en place un système qui va simplement…
> >> copier un
> >> fichier.
> >>
> >> Pour les mises a jour, vu que de toutes facons il faut les faire a
> >> la
> >> main, autant refaire la copie du .so plutot que refaire
> >> update-pepperflashplugin-nonfree --install
> >>
> >
> > J'ai telecharge l'archive depuis https://get.adobe.com/flashplayer/
> > mais
> > a l'interieur il y a juste des trucs pour KDE que je n'utilise pas.

> Heu non. Quand tu décompresse, ca te fait un dossier
> "flash_player_npapi_linux.x86_64" avec dedans :
> - un dossier LGPL avec la licence (a ignorer)
> - un dossier usr avec des trucs pour kde (a ingorer)
> - un fichier libflashplayer.so
> - un fichier licence.pdf
> - un fichier readme.txt

> Tu prend le fichier libflashplayer.so, tu le met dans un dossier
> ~/.mozilla/plugins et ca marche. Y'a rien d'autre a faire.

Re: Possibly erroneous "device not present" message during boot

[Brian]

On Wed 12 Apr 2017 at 10:14:59 -0500, Richard Owlett wrote:

> On 04/12/2017 07:39 AM, songbird wrote:
> >
> > - the bios may not be set correctly to find the device.
> 
> I do not see how the bios might be involved.
> Grub2 has been installed to the MBR of /dev/sda .
> The only known reference to Grub2 is in the instance of Debian residing on
> /dev/sda1 .

Everything GRUB knows about devices comes from what the BIOS tells it.
They are more than just good friends. :)

It appears from 'ls' at a GRUB prompt that your GRUB does not know about
your SD card. Booting takes place but GRUB takes its time to think about
what it should do about not finding something it has been told to search
for. In the end, it decides to go ahead, but in some cases it wouldn't.
That would dispel your present mood of happiness.

While we are it it: your update-grub stanza does not contain a line with
set root=" in it. Could this possibly be a copy and paste error? I ask
because the line is present on Jessie and testing when the device is a
USB stick.

-- 
Brian.

Re: Possibly erroneous "device not present" message during boot

[Richard Owlett]

On 04/13/2017 05:55 PM, Brian wrote:

On Thu 13 Apr 2017 at 20:05:22 +0200, Pascal Hambourg wrote:


David is right : you don't really boot from the SD card.


The OP never claimed he was booting from the SD card. He particularly
said he did not install GRUB to the card.


GRUB is on the HDD. The kernel is on the HDD. Only the root filesystem is on
the SD card.


Yes. That's what the linux line says too.



I'll try to clarify some details.

My installation protocol.
 1. I always use "Expert" as that way the installer will
do fewer things I'm not aware of.
 2. I only install Grub the *first* time I do a Debian install.
By poor design Grub puts the current install first on menu.
When experimenting with configuration as I do, the least
likely install to be functional is the latest.
This requires me to run update-grub on the "good" install.
 3. Similarly a swap partition is specified only on the first
install as the installer insists on destroying the UUID of
the existing swap partition. It is simpler to edit only the
fstab of latest install than to edit those for all other
installs each time.
 4. All installs in this thread have been done using DVD 1 of
13 of Debian 8.6.0 - thus all intrinsically use the same
kernel.

I've done some additional observations and test installs.
1. The BIOS of the Lenovo T510 can be directed to boot from
   the CD/DVD drive, hard disk, or any attached USB flash
   drive. It *cannot* be directed to boot from the SD card.
2. I did an install to a USB flash drive including installing
   Grub2 to the MBR of that flash drive. When selecting the
   SD card from the grub menu I see nothing different.
3. I did a new install to the SD card specifying a different set
   of packages and installing grub to the MBR of the SD card.
   Once again no behavioral difference.

Does any of this justify a bug report. Especially as I do not
have the bandwidth to do a netinstall of a pre-release version?

Re: Inittab

[Ricardo Ramos]

Olá Rodolfo,

Penso que não há necessidade de desinstalar o lightdm (nem gdm ou kdm), se
o que ele necessita é somente de desactivar o modo gráfico ele pode mudar o
runtime (agora chamado de target por causa do systemd).

Para isso ele só precisa de apontar o default target de graphical para
multi-user com o seguinte comando.

# ln -s /lib/systemd/system/multi-user.target
/lib/systemd/system/default.target

Esse comando muda o link do arquivo default.target que o systemd usa para
saber qual "runtime"/target ele deve iniciar.

Para mais informações use o comando abaixo para ver mas informações sobre o
equivalente ao inittab do systemd.

# man runlevel

A Sex, 14 de abr de 2017, 17:01, Rodolfo  escreveu:

> Olá Elias,
>
> primeira coisa a se fazer é remover ou desabilitar o atual gerenciador de
> sessão, existem gdm3, lightdm, kdm, etc, por padrão, se não me engano, o
> que vem instalado no Debian Jessie é o ligthdm, você precisa desinstalar
> ele ou desabilitá-lo:
>
> Desinstalar:
>
> # apt-get remove --purge ligthdm
>
> ou pode fazer melhor, que não remove, caso precise um dia:
>
> Parar o serviço da interface gráfica:
>
> # systemctl stop ligthdm
>
> Impedir que o mesmo seja inicializado durante o boot:
>
> # systemctl disable ligthdm
>
> Fazendo isso o mesmo não irá mais iniciar a interface gráfica(acredito eu
> '-'), porém nunca fiz isso, na teoria deve funcionar, teste e veja se
> funciona.
>
> As atuais versões do Debian vem por padrão agora com o Systemd(antes era o
> Sysvinit), tornando algumas tarefas diferentes do que éramos acostumados,
> porém na minha opinião ficou mais simples algumas coisas. Enfim, boa sorte
> :D
>
> Abraços.
>
>
> Em 14 de abril de 2017 11:35, Elias Albuquerque de Oliveira <
> elias_albuquer...@yahoo.com.br> escreveu:
>
>> Bom dia pessoal.
>> Faz muitos anos que não mexia com linux e estou voltando, ainda bem.
>> Porem estou usando debian e me incomoda muito que tudo inicia em
>> interface grafica.
>> Antigamente eu pegava o inittab e colocava init 3 e tudo se resolvia.
>> Onde foi parar o inittab e como faço para não subir a interface grafica
>> direto, somente se eu digitar starx.
>> Gostaria de uma ajuda, não achei nada muito interessante na net.
>> Att.
>>
>
> --

Ricardo Ramos
Tel: +244 927 953 770
Email: cesar.ricki...@gmail.com
Website: www.rickinho.com
Técnico de Informática

Need help for bug reports

[Willy]

Hi,

i found three annoying bugs:

1- Since i changed my graphics card from "geforce 8800 gts 512" to 
"geforce 780 ti", my pc powers off only if i add "console=ttyS1,115200" 
to the kernel boot parameters. Otherwise, it reboot.



2- I didn't have these messages with debian jessie 8.4 and i don't have 
these with the debian live cd (sda,sdb,sdc and sdd are logical drives 
handled by a megaraid card):


[5.903136] sd 0:1:1:0: [sdb] Unhandled error code
[5.903148] sd 0:1:1:0: [sdb]
[5.903153] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK
[5.903158] sd 0:1:1:0: [sdb] CDB:
[5.903162] ATA command pass through(16): 85 06 20 00 05 00 fe 00 00 00 00 
00 00 40 ef 00
[5.939504] sd 0:1:2:0: [sdc] Unhandled error code
[5.939517] sd 0:1:2:0: [sdc]
[5.939523] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK
[5.939529] sd 0:1:2:0: [sdc] CDB:
[5.939534] ATA command pass through(16): 85 06 20 00 05 00 fe 00 00 00 00 
00 00 40 ef 00
[5.952965] sd 0:1:1:0: [sdb] Unhandled error code
[5.952973] sd 0:1:1:0: [sdb]
[5.952977] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK
[5.952980] sd 0:1:1:0: [sdb] CDB:
[5.952983] ATA command pass through(16): 85 06 20 00 05 00 fe 00 00 00 00 
00 00 40 ef 00
[5.980244] sd 0:1:2:0: [sdc] Unhandled error code
[5.980252] sd 0:1:2:0: [sdc]
[5.980256] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK
[5.980259] sd 0:1:2:0: [sdc] CDB:
[5.980262] ATA command pass through(16): 85 06 20 00 05 00 fe 00 00 00 00 
00 00 40 ef 00
[5.997642] sd 0:1:2:0: [sdc] Unhandled error code
[5.997651] sd 0:1:2:0: [sdc]
[5.997655] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK
[5.997658] sd 0:1:2:0: [sdc] CDB:
[5.997661] ATA command pass through(16): 85 06 20 00 05 00 fe 00 00 00 00 
00 00 40 ef 00
[6.052163] sd 0:1:0:0: [sda] Unhandled error code
[6.052177] sd 0:1:0:0: [sda]
[6.052182] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK
[6.052187] sd 0:1:0:0: [sda] CDB:
[6.052191] ATA command pass through(16): 85 06 20 00 05 00 fe 00 00 00 00 
00 00 40 ef 00
[6.060136] sd 0:1:0:0: [sda] Unhandled error code
[6.060150] sd 0:1:0:0: [sda]
[6.060157] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK
[6.060164] sd 0:1:0:0: [sda] CDB:
[6.060169] ATA command pass through(16): 85 06 20 00 05 00 fe 00 00 00 00 
00 00 40 ef 00
[6.077558] sd 0:1:0:0: [sda] Unhandled error code
[6.077560] sd 0:1:0:0: [sda] Unhandled error code
[6.077570] sd 0:1:0:0: [sda]
[6.077574] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK



3 - Look at these messages:

[1.283600] sd 0:1:2:0: [sdc] 46080 512-byte logical blocks: (235 GB/219 
GiB)
[1.283627] sd 0:1:1:0: [sdb] 204804096 512-byte logical blocks: (104 
GB/97.6 GiB)
[1.283643] sd 0:1:2:0: [sdc] Write Protect is off
[1.283651] sd 0:1:2:0: [sdc] Mode Sense: 00 00 00 00
[1.283664] sd 0:1:1:0: [sdb] Write Protect is off
[1.283672] sd 0:1:1:0: [sdb] Mode Sense: 00 00 00 00
[1.283688] sd 0:1:2:0: [sdc] Asking for cache data failed
[1.283704] sd 0:1:1:0: [sdb] Asking for cache data failed
[1.283708] sd 0:1:1:0: [sdb] Assuming drive cache: write through
[1.283894] sd 0:1:2:0: [sdc] Assuming drive cache: write through
[1.284130] sd 0:1:0:0: [sda] 716802048 512-byte logical blocks: (367 GB/341 
GiB)
[1.284171] sd 0:1:0:0: [sda] Write Protect is off
[1.284178] sd 0:1:0:0: [sda] Mode Sense: 00 00 00 00
[1.284203] sd 0:1:0:0: [sda] Asking for cache data failed
[1.284268] sd 0:1:0:0: [sda] Assuming drive cache: write through
[1.284798]  sdb: sdb1
[1.284914] sd 0:1:3:0: [sdd] 4294963200 512-byte logical blocks: (2.19 
TB/1.99 TiB)
[1.284952] sd 0:1:3:0: [sdd] Write Protect is off
[1.284958] sd 0:1:3:0: [sdd] Mode Sense: 00 00 00 00
[1.284981] sd 0:1:3:0: [sdd] Asking for cache data failed
[1.285048] sd 0:1:3:0: [sdd] Assuming drive cache: write through
[1.285717] sd 0:1:1:0: [sdb] Attached SCSI disk


sda, sdb, sdc, sdd are logical drives handled by the megaraid card. 
According to these messages, the system is unable to know the 
configuration of the megaraid caches. So, it assumes "write through". 
But i want to enable the "write back" capability of the megaraid card. 
If i do that, does this lead to corruption data on drive especially at 
power off ?




I would like to sent bug reports but i don't know at which packages 
these bugs belong to.


Thanks,

Willy.

Re: Inittab

[Rodolfo]

Olá Elias,

primeira coisa a se fazer é remover ou desabilitar o atual gerenciador de
sessão, existem gdm3, lightdm, kdm, etc, por padrão, se não me engano, o
que vem instalado no Debian Jessie é o ligthdm, você precisa desinstalar
ele ou desabilitá-lo:

Desinstalar:

# apt-get remove --purge ligthdm

ou pode fazer melhor, que não remove, caso precise um dia:

Parar o serviço da interface gráfica:

# systemctl stop ligthdm

Impedir que o mesmo seja inicializado durante o boot:

# systemctl disable ligthdm

Fazendo isso o mesmo não irá mais iniciar a interface gráfica(acredito eu
'-'), porém nunca fiz isso, na teoria deve funcionar, teste e veja se
funciona.

As atuais versões do Debian vem por padrão agora com o Systemd(antes era o
Sysvinit), tornando algumas tarefas diferentes do que éramos acostumados,
porém na minha opinião ficou mais simples algumas coisas. Enfim, boa sorte
:D

Abraços.


Em 14 de abril de 2017 11:35, Elias Albuquerque de Oliveira <
elias_albuquer...@yahoo.com.br> escreveu:

> Bom dia pessoal.
> Faz muitos anos que não mexia com linux e estou voltando, ainda bem.
> Porem estou usando debian e me incomoda muito que tudo inicia em interface
> grafica.
> Antigamente eu pegava o inittab e colocava init 3 e tudo se resolvia.
> Onde foi parar o inittab e como faço para não subir a interface grafica
> direto, somente se eu digitar starx.
> Gostaria de uma ajuda, não achei nada muito interessante na net.
> Att.
>

Re: Systemd services

[Teemu Likonen]

Greg Wooledge [2017-04-14 08:37:55-04] wrote:

> Some day there will be actual end-user-friendly systemd documentation
> somewhere, consolidating all of these pieces of wisdom together. I
> hope.

I learnd by reading systemd's really good man pages:

$ man systemd.unit
$ man systemd.timer
$ man systemd.service
...

And Linux system's are full of real unit file "examples" which can be
read with "systemctl cat foo.service".

-- 
/// Teemu Likonen   - .-..    //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///


signature.asc
Description: PGP signature

Inittab

[Elias Albuquerque de Oliveira]

Bom dia pessoal.Faz muitos anos que não mexia com linux e estou voltando, ainda 
bem.Porem estou usando debian e me incomoda muito que tudo inicia em interface 
grafica.Antigamente eu pegava o inittab e colocava init 3 e tudo se 
resolvia.Onde foi parar o inittab e como faço para não subir a interface 
grafica direto, somente se eu digitar starx.Gostaria de uma ajuda, não achei 
nada muito interessante na net.Att.

Re: Systemd services (was Re: If Linux Is About Choice, Why Then ...)

[Martin Read]

On 14/04/17 14:17, Nicolas George wrote:

Le quintidi 25 germinal, an CCXXV, Greg Wooledge a écrit :

Some day there will be actual end-user-friendly systemd documentation
somewhere, consolidating all of these pieces of wisdom together.  I hope.


Note: systemd is not for end-users, it is for system administrator and
distribution authors.


systemd is absolutely for end-users, because:

* Some systemd-running systems are home desktop computers with a single 
physical user; in this case, the distinction between "administrator" and 
"user" may well only exist as a hallucination of the computer, with no 
basis in the external physical world. If the computer I'm typing this 
e-mail on breaks down, I have to fix it myself.


* systemd can, in any event, be used to manage service-like processes 
that form part of a user's login session, using unit files stored in 
that user's XDG Base Directories.

Re: Systemd services (was Re: If Linux Is About Choice, Why Then ...)

[Greg Wooledge]

On Fri, Apr 14, 2017 at 03:17:00PM +0200, Nicolas George wrote:
> Le quintidi 25 germinal, an CCXXV, Greg Wooledge a écrit :
> > Some day there will be actual end-user-friendly systemd documentation
> > somewhere, consolidating all of these pieces of wisdom together.  I hope.
> 
> Note: systemd is not for end-users, it is for system administrator and
> distribution authors.

The end users of systemd are Linux system administrators.  You and me.
The people on this mailing list.  That's us, the users.  That's why
it's called "debian-user".

If you'd prefer "Some day there will be a system administrator's guide
for systemd", that's an acceptable wording.

Re: Systemd services (was Re: If Linux Is About Choice, Why Then ...)

[Dejan Jocic]

On 14-04-17, Nicolas George wrote:
> Le quintidi 25 germinal, an CCXXV, Greg Wooledge a écrit :
> > Some day there will be actual end-user-friendly systemd documentation
> > somewhere, consolidating all of these pieces of wisdom together.  I hope.
> 
> Note: systemd is not for end-users, it is for system administrator and
> distribution authors.
> 
Actually, it should be for end-user too. On personal computer, that
end-user is system administrator. I also find that systemd is very well
documented. But it could be just me. Now, please carry on, enjoyed this
thread very much, learned thing, or two :)

Thank you for your time.

Re: Exim4 problem?

[deloptes]

Charlie wrote:

> It doesn't matter. This system needs to be reinstalled, so I won't
> bother with updates and upgrades and when I reinstall it, I will
> remove exim4 right from the word go and see how that works.

you could identify the reason for the misbehavior by looking at paniclog and
mainlog

but proceed as you wish

regards

Re: Systemd services (was Re: If Linux Is About Choice, Why Then ...)

[Nicolas George]

Le quintidi 25 germinal, an CCXXV, Greg Wooledge a écrit :
> Some day there will be actual end-user-friendly systemd documentation
> somewhere, consolidating all of these pieces of wisdom together.  I hope.

Note: systemd is not for end-users, it is for system administrator and
distribution authors.

> 1) To override parts of a distribution's systemd unit locally, you MUST
>use the foo.service.d/ method.  You can't just put the override bits
>into an /etc/systemd/system/foo.service file.  That would be too easy.

foo.service.d/*.confis for overriding bits.
/etc/systemd/system/foo.service is for overriding the whole file.

I find that fairly natural. Otherwise, how would you override the whole
file?

> 2) The files inside foo.service.d/ MUST end with a .conf suffix.  (Cf.
>the wheezy->jessie apache2 upgrade, and having to rename every single
>one of my virtual domain config files AND the symlinks to them.)

After having been bitten by old *.conf~ backup files left by an editor,
I must say I find that restriction quite useful.

> 3) foo.service.d/ must use the CANONICAL service name of whatever it is
>that you're trying to override.  This may not be the same as the
>Debian package name.  For example, the nfs-kernel-server package
>creates a systemd unit named nfs-server.service with an ALIAS of
>nfs-kernel-server.service.  If you try to create override files in
>nfs-kernel-server.service.d/ it will not work correctly.  They have
>to be in nfs-server.service.d/ instead.
> 
>Don't even get me started on sshd.service vs. ssh.service.  Do you
>have any idea how hard it is to notice that extra/missing "d", and
>figure out why things Simply Do Not Work?

On the other hand, if systemd were to read snippets of configuration
with a subtly different name, someone else (or maybe be even yourself!)
would have complained about wasted time because of a stale config
snippet that should not have been read.

I find that strict rules are usually more convenient in the long run.

Note that you can use "systemctl edit" to have an editor started on the
exact correct file.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: comment faite-vous pour installer flashplayer?

[Stephane Ascoet]

Le 14/04/2017 à 15:23, hamster a écrit :

- un fichier libflashplayer.so


Ah oui je ne l'avais pas vu desole! Il est bien la!

--
Bien cordialement, Stephane Ascoet

Re: comment faite-vous pour installer flashplayer?

[hamster]

Le 14/04/2017 à 15:17, Stephane Ascoet a écrit :
> Le 05/04/2017 à 18:26, hamster a écrit :
>> Le 05/04/2017 à 17:54, Haricophile a écrit :
>>> De fait j'ai assez longtemps utilisé la méthode de télécharger le >
>>> .tar.gz chez Adobe, de le décompresser et de copier le .so dans >
>> ~/.mozilla/plugins
>>
>> Aaaahhh, merci pour cette astuce d'une grande simplicité et qui
>> marche. En effet, c'est hallucinant qu'on passe autant de temps et
>> d'énergie pour mettre en place un système qui va simplement… copier un
>> fichier.
>>
>> Pour les mises a jour, vu que de toutes facons il faut les faire a la
>> main, autant refaire la copie du .so plutot que refaire
>> update-pepperflashplugin-nonfree --install
>>
> 
> J'ai telecharge l'archive depuis https://get.adobe.com/flashplayer/ mais
> a l'interieur il y a juste des trucs pour KDE que je n'utilise pas.

Heu non. Quand tu décompresse, ca te fait un dossier
"flash_player_npapi_linux.x86_64" avec dedans :
- un dossier LGPL avec la licence (a ignorer)
- un dossier usr avec des trucs pour kde (a ingorer)
- un fichier libflashplayer.so
- un fichier licence.pdf
- un fichier readme.txt

Tu prend le fichier libflashplayer.so, tu le met dans un dossier
~/.mozilla/plugins et ca marche. Y'a rien d'autre a faire.

Re: comment faite-vous pour installer flashplayer?

[Stephane Ascoet]

Le 05/04/2017 à 18:26, hamster a écrit :

Le 05/04/2017 à 17:54, Haricophile a écrit :

De fait j'ai assez longtemps utilisé la méthode de télécharger le > .tar.gz chez 
Adobe, de le décompresser et de copier le .so dans >

~/.mozilla/plugins

Aaaahhh, merci pour cette astuce d'une grande simplicité et qui
marche. En effet, c'est hallucinant qu'on passe autant de temps et
d'énergie pour mettre en place un système qui va simplement… copier un
fichier.

Pour les mises a jour, vu que de toutes facons il faut les faire a la
main, autant refaire la copie du .so plutot que refaire
update-pepperflashplugin-nonfree --install



J'ai telecharge l'archive depuis https://get.adobe.com/flashplayer/ mais 
a l'interieur il y a juste des trucs pour KDE que je n'utilise pas.


PS: coucou hamster :-)
--
Bien cordialement, Stephane Ascoet

Re: Exim4 problem? solved- just for completeness.....

[Charlie]

On 14/04/2017, deloptes  wrote:
> Charlie wrote:
>
>> /var/log/exim4/paniclog has non-zero size, mail system possibly broken
>
> This is common for exim .
> 1. check the paniclog
> 2. take actions if needed based on 1.
> 3. remove paniclog
> 4. proceed with restart
>
> it has nothing to do with systemd. it is exims "normal" behavior
>
> regards

Tried to install exim4 again, same error message came up.

Using synaptic, purged exim4
Then did a normal update upgrade without error. Then rebooted to
ensure everything was working as it should.

The boot messages complained "failed" to find exim4 and all that sails
in her. But otherwise it's all good. I think I won't bring exim4 back
in for a while. I am not pleased with it's normal behaviour, and this
system needs to be reinstalled anyway.

Thank you Songbird, Delopes and Joe for your help. It's much appreciated.

Be well,
Charlie

Re: Systemd services (was Re: If Linux Is About Choice, Why Then ...)

[Greg Wooledge]

On Thu, Apr 13, 2017 at 10:01:25PM +0100, Jonathan de Boyne Pollard wrote:
> ... albeit poorly.  If one wants to run daemontools under systemd, svscanboot 
> is
> not the way; svscanboot is a thing of the past
> http://jdebp.eu./FGA/inittab-is-history.html#svscanboot , and was a source of
> problems long before systemd was invented.

Cool.  I wish my Google searching had stumbled upon that, when I was
trying to figure out how to do all that stuff.

> The world wants you to clean your screen
> http://unix.stackexchange.com/a/233855/5132 , and this is merely one of the 
> ways
> that it makes you do so.

Some day there will be actual end-user-friendly systemd documentation
somewhere, consolidating all of these pieces of wisdom together.  I hope.

My own contributions toward that effort have been riddled with failure and
confusion, for which I am sorry.  I'm honestly *trying*, but this stuff is
really opaque at times.

For instance, just this week I learned three new things:

1) To override parts of a distribution's systemd unit locally, you MUST
   use the foo.service.d/ method.  You can't just put the override bits
   into an /etc/systemd/system/foo.service file.  That would be too easy.

2) The files inside foo.service.d/ MUST end with a .conf suffix.  (Cf.
   the wheezy->jessie apache2 upgrade, and having to rename every single
   one of my virtual domain config files AND the symlinks to them.)

3) foo.service.d/ must use the CANONICAL service name of whatever it is
   that you're trying to override.  This may not be the same as the
   Debian package name.  For example, the nfs-kernel-server package
   creates a systemd unit named nfs-server.service with an ALIAS of
   nfs-kernel-server.service.  If you try to create override files in
   nfs-kernel-server.service.d/ it will not work correctly.  They have
   to be in nfs-server.service.d/ instead.

   Don't even get me started on sshd.service vs. ssh.service.  Do you
   have any idea how hard it is to notice that extra/missing "d", and
   figure out why things Simply Do Not Work?

Re: Exim4 problem?

[Charlie]

On 14/04/2017, Joe  wrote:
> On Fri, 14 Apr 2017 10:35:42 +1000
> Charlie  wrote:
>
>> Received this on attempted upgrade:
>>
>> systemctl status exim4.service
>> ● exim4.service - LSB: exim Mail Transport Agent
>>Loaded: loaded (/etc/init.d/exim4; generated; vendor preset:
>> enabled) Active: failed (Result: resources) since Fri 2017-04-14
>> 10:24:05 AEST; 4min 44s ago
>>  Docs: man:systemd-sysv-generator(8)
>>   Process: 9436 ExecStart=/etc/init.d/exim4 start (code=exited,
>> status=0/SUCCESS)
>>
>> Assume nothing I can do? Something that needs to be done higher up
>> the scale?
>>
>> Can't uninstall or purge exim4 either.
>>
>
>
> I don't know if it helps, it may be a red herring, but...
>
>  ..years ago, long before systemd, I had this happen to exim4 during a
> dist-upgrade of one stable to the next. The exim4 upgrade stuck part of
> the way through, and would go neither forward nor back nor run, and even
> dpkg was not able to remove it to reinstall. In the end, I had to
> manually delete files to get it to the point where I could reinstall
> from scratch.
>
> The reason turned out to be that exim4 needed a version upgrade to one
> which not only didn't honour debconf statements in the configuration
> file, but was violently sick on finding them, to the extent of breaking
> the upgrade. It installed fine with a default config file, and I then
> transferred my configurations to that.
>
> So this just *might* be an incompatible configuration issue, and you
> just *might* have to rip files out by hand. There was certainly an
> issue with exim4, which may not have been fixed, which resulted in some
> kind of deadlock over old and new parts during the upgrade. Exim4
> seemed to need to restart part of the way through the upgrade, and
> couldn't restart with an incompatible config file.
>
> I didn't have the means to reproduce the situation and file a useful
> bug, and in any case, the developer would just have told me I should
> have read the release notes for the new exim4 and not been so stupid as
> to try to re-use the old config file.
>
> --
> Joe

Thank you.

It didn't work.

Put exim4 on hold, purged it with dpkg at some point.

Then systematically removed everything I could find of exim4, piece by
piece and at each step tried to upgrade the system with the same error
message. Removed the panic.log each time as well and finally the
/var/exim4 directory as the last thing. Several reboots, almost after
each step.

Still came up with the same error message.

It doesn't matter. This system needs to be reinstalled, so I won't
bother with updates and upgrades and when I reinstall it, I will
remove exim4 right from the word go and see how that works.

Thank you for your suggestion, it was another path to follow.
Charlie

Re: Exim4 problem?

[Charlie]

On 14/04/2017, deloptes  wrote:
> Charlie wrote:
>
>> /var/log/exim4/paniclog has non-zero size, mail system possibly broken
>
> This is common for exim .
> 1. check the paniclog
> 2. take actions if needed based on 1.
> 3. remove paniclog
> 4. proceed with restart
>
> it has nothing to do with systemd. it is exims "normal" behavior
>
> regards

Thank you for that suggestion.

It didn't work. But doesn't matter as this system has been up and
running many years and it's time to reinstall at any rate.

Thank you again,
Charlie

Re: If Linux Is About Choice, Why Then ...

[Reco]

On Thu, Apr 13, 2017 at 06:37:03PM +0100, Jonathan Dowland wrote:
> On Thu, Apr 13, 2017 at 06:44:08PM +0300, Reco wrote:
> > Describing Fedora as 'community-driven' distribution is a gross
> > oversimplification. It's not that I disagree with initial assessment -
> > they don't sell you Debian stable like Red Hat does for RHEL.
> 
> Red Hat employees do have significant involvement in Fedora. This is true.
> May I ask, what model would you prefer?
> 
> Disclaimer: I am a Red Hat employee, but I have nothing to do with Fedora.

Both, actually.

Debian stable works for me. RHEL works for my current employer.

Being realist I have to accept that it's much easier to use a Linux
distribution for *commercial purposes* if there's some price tag attached
to it (or to the support of said distribution). An ablility to redirect
responsibility to support is priceless.

But for the non-commercial purposes and personal use RHEL is way too
enterprisey for my taste. Too little software, too much 'do it our way'
approach. Hence - Debian for my needs.

Reco

Re: If Linux Is About Choice, Why Then ...

[Nicolas George]

Le quintidi 25 germinal, an CCXXV, to...@tuxteam.de a écrit :
> Thanks for you nice, condescending tone. Very much appreciated.

I am sorry you take it that way. It was not meant to, and thinking about
it again, I see nothing condescending in assuming, based on your
statement, that you are not familiar with the obsession of a fringe of
the Libre software developer community.

> Besides, PERFECTLY, oh, well. ECC RAM. Redundant processors. Formally
> validated software.

Well, your irritation made you do something dishonest: ridiculing a
point of my discourse ignoring that I addressed exactly the same issue
in the next paragraph.

> I never said SysV's PID scheme is a good idea. For me it's "good enough",

Well, you realize it is good enough *for you*, there are a lot of people
who consider it not good enough for them.

> but I mentioned enough alternatives. You have to make sure that the
> monitor process doesn't die (modulo things which can happen to PID 1
> too), and that's pretty feasible whithin a current Linux system (the
> OOM killer you mention, for example: PostgreSQL excludes its postmaster
> from that; you've to make sure that the monitor process doesn't get
> out of control, but that's achieved by keeping it simple and small).

You can do all you want, PID 1 is still the only immortal process on the
system.

And if every single daemon must implement workarounds for the
limitations of SysV init, I say this is a seriously flawed design.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: If Linux Is About Choice, Why Then ...

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Apr 14, 2017 at 11:40:29AM +0200, Nicolas George wrote:
> Le quintidi 25 germinal, an CCXXV, to...@tuxteam.de a écrit :
> > You keep repeating this misconception. "Could be" "nobody would". By your
> > logic, Apache and PostgreSQL (among many following this model) wouldn't
> > work. They do. Pretty reliably, at that.
> 
> I am sorry, but you are mistaken here, possibly because you have only a
> vague idea of what "monitoring system" is exactly about.

Thanks for you nice, condescending tone. Very much appreciated.

> You see, when people talk about "monitoring systems", they are not after
> "pretty" reliable, they are after PERFECTLY reliable. They want
> reliability even against million-to-one coincidences.

Your condescending tone doesn't really help in keepig a good discussion.

Besides, PERFECTLY, oh, well. ECC RAM. Redundant processors. Formally
validated software.

> (With the default kernel configuration, "being killed due to a stale PID
> file" is a 1/65535 coincidence, much higher than million-to-one, except
> in Discworld logic.)

I never said SysV's PID scheme is a good idea. For me it's "good enough",
but I mentioned enough alternatives. You have to make sure that the
monitor process doesn't die (modulo things which can happen to PID 1
too), and that's pretty feasible whithin a current Linux system (the
OOM killer you mention, for example: PostgreSQL excludes its postmaster
from that; you've to make sure that the monitor process doesn't get
out of control, but that's achieved by keeping it simple and small).

[...]

> And I can say that it happened to me: I have, not often but not just
> once either, found that Apache or another daemon was not running, and
> could not find the reason easily.
> 
> If you are still not convinced, look at the other serious monitoring
> systems: all of them have at least a provision to run as PID 1.

For you, systemd might be the knee's bees: for me it's not, and I think
I've stated my reasons enough. I think we've reached the end of a
productive discussion now.

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

iEYEARECAAYFAljwprsACgkQBcgs9XrR2kb9lQCaAlTF4ATTK7c9JXXpiTrAeOy1
PP8AnjPHNSyQ1YGdVN2ddP/gKRpm79yS
=cf4l
-END PGP SIGNATURE-

Re: ssl isues are Eating me alive.

[Reco]

Hi.

On Thu, Apr 13, 2017 at 01:01:24PM -0400, Greg Wooledge wrote:
> On Thu, Apr 13, 2017 at 11:54:32AM -0500, Martin McCormick wrote:
> > This started out a year or so ago with the occasional site in
> > which lynx would report that it was unable to establish a TLS
> > connection with this or that site. [...]
> 
> It's not just lynx.  It's EVERY single terminal-based browser, and
> as you noticed, it gets worse every day.
> 
> Apparently all of the terminal-based browsers in wheezy and jessie are
> linked with libgnutls instead of libopenssl, and libgnutls (at least as
> provided by jessie) is completely incapable of forming an SSL connection
> with half of the Web.

There's one notable exception to this in jessie and it's called w3m.

$ ldd /usr/bin/w3m | grep ssl
libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0

Reco

Re: If Linux Is About Choice, Why Then ...

[Nicolas George]

Le quintidi 25 germinal, an CCXXV, Joel Rees a écrit :
> > Summary: Linux has a new system call to allow process to register as
> > adopters for orphan processes.
> Ick. I hope they don't register directly with pid1.

I am sorry, but that does not even make sense.

> Or you could have pid1 monitor only the monitoring process, to keep pid1 
> simple.

Or you could have PID 1 monitor a process that monitors a process that
monitors a process that monitors a process that monitors the monitoring
process.

Sorry, I do not share your religious imperative of keeping PID 1 simple
at the cost of making everything else more complex.

> pid1 seems to be doing a lot of other things in systemd. Is it
> cooperatively multitasking with itself yet? Or have they borrowed
> threads to define a new kind of process concept, so that pid1 can
> multitask with itself preemptively?
> 
> I should go look at the source to see, I suppose

Obviously you find burning straw men more entertaining. Please go ahead,
I will try not to trouble further.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: If Linux Is About Choice, Why Then ...

[Nicolas George]

Le quintidi 25 germinal, an CCXXV, to...@tuxteam.de a écrit :
> You keep repeating this misconception. "Could be" "nobody would". By your
> logic, Apache and PostgreSQL (among many following this model) wouldn't
> work. They do. Pretty reliably, at that.

I am sorry, but you are mistaken here, possibly because you have only a
vague idea of what "monitoring system" is exactly about.

You see, when people talk about "monitoring systems", they are not after
"pretty" reliable, they are after PERFECTLY reliable. They want
reliability even against million-to-one coincidences.

(With the default kernel configuration, "being killed due to a stale PID
file" is a 1/65535 coincidence, much higher than million-to-one, except
in Discworld logic.)

Since perfectly is not possible, they settle for as-much-as-possible.
And SysV init is very far from achieving the optimum.

Look at the process hierarchy of your SysV-init-based system: Apache and
PostgreSQL are direct children of PID 1, but PID 1 does not know about
them. If they exit, PID 1 will reap them, but nothing more. There are
many reasons that can cause that: OOM killer, bug in the program,
hardware problems, stale PID file, admin mistake, etc. Some of them will
leave more or less discreet traces in the logs, but not all of them. And
you may find these reasons unlikely, but when someone interested in
"monitoring systems" hears "unlikely", they understand "possible".

And I can say that it happened to me: I have, not often but not just
once either, found that Apache or another daemon was not running, and
could not find the reason easily.

If you are still not convinced, look at the other serious monitoring
systems: all of them have at least a provision to run as PID 1.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: Petit souci penible avec VirtualBox

[Stephane Ascoet]

Le 13/04/2017 17:57, debheal a écrit :

WDS ? [1]


Bonjour, oui, nous utilisons uniquement ce systeme pour nos 
installations de window$ NT a l'universite. Nous avons deux serveurs: le 
plus ancien fonctionne avec les versions recentes de Virtualbox(d'ou 
l'installation d'une de celles-ci), le plus recent non.



Debian 7.7 (Wheezy) est t'elle à jour ? La dernière update étant la 7: 7.11 [2]


Fait


Ce message : [3]
signifie que vous avais installé virtualbox-5.1 5.1.14 à partir du site 
virtualbox.org,version qui est pas, officiellement, supporté par Wheezy.[4] Le 
paquet ainsi installé; il faudrait résoudre des problèmes de dépendance à la 
main ce que je déconseillerai.





Le paquet virtualbox 4.1.42-dfsg-1+deb7u1 est celui qui correspond à votre 
distribution wheezy (oldstable).

Donc la réponse du message [3], de déinstaller la 5.1 et de remettre la 4.1.42 
(officiel) est la même que je ferai, pour que le système marche rapidement. En 
plus virtualbox-qt 4.1.42 est prévu pour lui.
Pour les modules c'est virtualbox-dkms 4.1.42-dfsg-1+deb7u1

Maintenant, je comprend la démarche de passer à une version plus récente de 
Virtualbox.
Mais prendre la 5.1 de Virtualbox.org et venir la coller dans une pauvre 
Wheezy, oldstable de surcrois elle n'a pas du bien comprendre ce qui lui arrivé 
dessus :)


Non, il n'y a pas de souci, c'est un paquet fait par les equipes adaptes 
a Wheezy.


Alors, migrer, upgrader ?... la liste est bien là [4] et la version la plus 
proche que vous vouliez installer est la 5.1.18-dfsg-1 en sid (unstable) !! 
mieux vaut revenir en arriere ou de bien réfléchir avant de faire un 
dist-upgrade et de tout casser. Ou plutôt faire les choses en douceur : 
wheezy-backports ou jessie..
Finalement, quel est le but de la manœuvre ?


Pas sur de tout comprendre mais en tous cas je ne peux pas me permettre 
de passer en stable actuelle comme ca sur ce poste qui est celui de mon 
travail et qui doit etre fonctionnel a tout moment avec mes parametres 
bien precis, surtout avec le passage a Systemd et autres joyeusetes. 
D'ou l'interet d'avoir un Virtualbox performant pour faire des tests 
intensifs avant. Deja la j'ai peur avec le passage en 7.7.11, je vois 
qu'il m'a remplace Iceweasel par Firefox, j'ai peur de ce que je vais 
decouvrir :-(





--
Bien cordialement, Stephane Ascoet

Re: Exim4 problem?

[deloptes]

Charlie wrote:

> /var/log/exim4/paniclog has non-zero size, mail system possibly broken

This is common for exim . 
1. check the paniclog
2. take actions if needed based on 1.
3. remove paniclog
4. proceed with restart

it has nothing to do with systemd. it is exims "normal" behavior 

regards

Re: If Linux Is About Choice, Why Then ...

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Apr 13, 2017 at 11:20:02PM +0200, Nicolas George wrote:

[...]

> Yet, PID 1 is still the only immortal process, unless you have another
> new mutant power to produce, and that property is needed to have a
> reliable monitoring system. Otherwise, the monitoring process could be
> killed, and nobody would notice.

You keep repeating this misconception. "Could be" "nobody would". By your
logic, Apache and PostgreSQL (among many following this model) wouldn't
work. They do. Pretty reliably, at that.

Don't get me wrong: I think SysV gave up on something BSD init had,
and think it should (and could, in fact) re-gain it, but... it's not
as dramatic as (the less informed) systemd proponents would make you
believe.

Systemd has its strengths. If you managed to concentrate on those,
you would do systemd a bigger service. Spreading FUD, by contrast,
does it a disservice.

Regards
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAljwjn8ACgkQBcgs9XrR2kZgCwCdFJP5Gd9EVsvDSHMepS0K5d8F
eY4An0gimfOX8hTQ+bhfW8p4CJprIeqq
=L8sI
-END PGP SIGNATURE-

Re: Almost all gpg2 operations hang after upgrade to stretch/testing

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Apr 13, 2017 at 09:43:26AM -0500, John Hasler wrote:
> tomas writes:
> > Part of Google's perceived superiority is that it "learns to know
> > you": a couple of search terms thrown in, for Google is "search terms
> > + context", while for DDG, the context is missing.
> 
> Google does not "learn to know you" if you block all its scripts and
> cookies, which is how I use it.  It's still vastly superior to the Duck.

Others have already chimed in. My reading proposal:

  https://panopticlick.eff.org/

It's Google's core business. They even invest a lot of money in clients
(Mozilla, Chrome, Android). Why should they refrain from that?

When I say they "know" you I mean not personally, but statistically. It's
not some Evil Mastermind (TM) who is after you, but simple, plain, cold
business.

It doesn't make sense to go all paranoid over that. I know that even if
I keep my own mail server they analyze all my mails (enough of my peers
have an @gmail address, enough of my stuff is in public mailing lists,
ready for harvesting), but I see it as my duty to not feed that machine
beyond what's "reasonable" (yes, this is a judgement call).

"Just because you're paranoid doesn't mean they are not after you"
  -- Joseph Heller

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

iEYEARECAAYFAljwjJMACgkQBcgs9XrR2kYZ4QCdFCKkBfsXM6luYNOn5apfaE6E
VbwAniQJUd3/lPSNRKJbebxKmdwJ6+O+
=ZFm/
-END PGP SIGNATURE-

Re: Exim4 problem?

[Joe]

On Fri, 14 Apr 2017 10:35:42 +1000
Charlie  wrote:

> Received this on attempted upgrade:
> 
> systemctl status exim4.service
> ● exim4.service - LSB: exim Mail Transport Agent
>Loaded: loaded (/etc/init.d/exim4; generated; vendor preset:
> enabled) Active: failed (Result: resources) since Fri 2017-04-14
> 10:24:05 AEST; 4min 44s ago
>  Docs: man:systemd-sysv-generator(8)
>   Process: 9436 ExecStart=/etc/init.d/exim4 start (code=exited,
> status=0/SUCCESS)
> 
> Assume nothing I can do? Something that needs to be done higher up
> the scale?
> 
> Can't uninstall or purge exim4 either.
> 


I don't know if it helps, it may be a red herring, but...

 ..years ago, long before systemd, I had this happen to exim4 during a
dist-upgrade of one stable to the next. The exim4 upgrade stuck part of
the way through, and would go neither forward nor back nor run, and even
dpkg was not able to remove it to reinstall. In the end, I had to
manually delete files to get it to the point where I could reinstall
from scratch.

The reason turned out to be that exim4 needed a version upgrade to one
which not only didn't honour debconf statements in the configuration
file, but was violently sick on finding them, to the extent of breaking
the upgrade. It installed fine with a default config file, and I then
transferred my configurations to that.

So this just *might* be an incompatible configuration issue, and you
just *might* have to rip files out by hand. There was certainly an
issue with exim4, which may not have been fixed, which resulted in some
kind of deadlock over old and new parts during the upgrade. Exim4
seemed to need to restart part of the way through the upgrade, and
couldn't restart with an incompatible config file.

I didn't have the means to reproduce the situation and file a useful
bug, and in any case, the developer would just have told me I should
have read the release notes for the new exim4 and not been so stupid as
to try to re-use the old config file.

-- 
Joe

Re: Exim4 problem?

[Charlie]

On 14/04/2017, songbird  wrote:
> Charlie wrote:
>> Received this on attempted upgrade:
>>
>> systemctl status exim4.service
>> ● exim4.service - LSB: exim Mail Transport Agent
>>Loaded: loaded (/etc/init.d/exim4; generated; vendor preset: enabled)
>>Active: failed (Result: resources) since Fri 2017-04-14 10:24:05
>> AEST; 4min 44s ago
>>  Docs: man:systemd-sysv-generator(8)
>>   Process: 9436 ExecStart=/etc/init.d/exim4 start (code=exited,
>> status=0/SUCCESS)
>>
>> Assume nothing I can do? Something that needs to be done higher up the
>> scale?
>>
>> Can't uninstall or purge exim4 either.
>
>   hmm...
>
>   i'm assuming this is on testing/stretch version?
>
>
>   is there something still running?  as it looks
> like to me that it tried to restart when perhaps
> another instance was running or something like
> that...
>
>   why would you need to uninstall or purge?  did
> you interrupt the upgrade?  are your apt/dpkg
> files inconsistent or showing dependency problems?
>
>   what does systemctl status exim4 say
> after you do a systemctl stop exim4
>
>   ?
>
>   and then a start?
>
>   does it restart?
>
>   check /var/log/apt/term.log
>   and /var/log/dpkg.log
>
>   or does something show up in the systemd
> journal from that timeframe?
>
>   see if there are any messages in those that may
> give an idea of what is going on.
>
>   i had exim4 upgrade go through today too.
> because there were so many processes still
> out of date according to checkrestart i
> rebooted before doing anything else.
>
>   i didn't see any errors in the upgrade or
> in the reboot and my exim4 has been chugging
> along all day.
>
>
>   songbird

Thanks Songbird,

Debian testing is correct.

Posted the top part of what systemctl status exim4 in the first email.

Hadn't done systemctl stop exim4

After systemctl stop exim4 reads like this:

systemctl status exim4
● exim4.service - LSB: exim Mail Transport Agent
   Loaded: loaded (/etc/init.d/exim4; generated; vendor preset: enabled)
   Active: failed (Result: resources) since Fri 2017-04-14 16:22:17
AEST; 1min 41s ago
 Docs: man:systemd-sysv-generator(8)
  Process: 1489 ExecStart=/etc/init.d/exim4 start (code=exited,
status=0/SUCCESS)

Apr 14 16:22:13 taogypsy systemd[1]: Starting LSB: exim Mail Transport Agent...
Apr 14 16:22:17 taogypsy exim4[1489]: Starting MTA: exim4.
Apr 14 16:22:17 taogypsy exim4[1489]: ALERT: exim paniclog
/var/log/exim4/paniclog has non-zero size, mail system possibly broken
Apr 14 16:22:17 taogypsy systemd[1]: exim4.service: PID file
/run/exim4/exim.pid not readable (yet?) after start: No such file or
directory
Apr 14 16:22:17 taogypsy systemd[1]: exim4.service: Daemon never wrote
its PID file. Failing.
Apr 14 16:22:17 taogypsy systemd[1]: Failed to start LSB: exim Mail
Transport Agent.
Apr 14 16:22:17 taogypsy systemd[1]: exim4.service: Unit entered failed state.
Apr 14 16:22:17 taogypsy systemd[1]: exim4.service: Failed with result
'resources'.

/var/log/exim4/paniclog says:

2017-04-14 10:13:04 IPv6 socket creation failed: Address family not
supported by protocol

ipv6 has been disabled for the 6 years or so I have had this regularly
upgraded Debian system installed.
/etc/default/grub
GRUB_CMDLINE_LINUX="ipv6.disable=1"

The reason: I have a router that doesn't do ipv6. Also I was told that
satellite, which I am locked into, does not do ipv6 I have never
required it and have never changed it.

Then did: systemctl start exim4

 systemctl start exim4

Job for exim4.service failed because of unavailable resources or
another system error.
See "systemctl status exim4.service" and "journalctl -xe" for details.

journalctl -xe

Apr 14 16:40:15 taogypsy systemd[1]: Starting LSB: exim Mail Transport Agent...
-- Subject: Unit exim4.service has begun start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit exim4.service has begun starting up.
Apr 14 16:40:17 taogypsy exim4[2209]: Starting MTA: exim4.
Apr 14 16:40:17 taogypsy exim4[2209]: ALERT: exim paniclog
/var/log/exim4/paniclog has non-zero size, mail system possibly broken
Apr 14 16:40:17 taogypsy systemd[1]: exim4.service: PID file
/run/exim4/exim.pid not readable (yet?) after start: No such file or
directory
Apr 14 16:40:17 taogypsy systemd[1]: exim4.service: Daemon never wrote
its PID file. Failing.
Apr 14 16:40:17 taogypsy systemd[1]: Failed to start LSB: exim Mail
Transport Agent.
-- Subject: Unit exim4.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit exim4.service has failed.
-- 
-- The result is failed.
Apr 14 16:40:17 taogypsy systemd[1]: exim4.service: Unit entered failed state.
Apr 14 16:40:17 taogypsy systemd[1]: exim4.service: Failed with result
'resources'.
Apr 14 16:40:29 taogypsy kernel: iptables denied: IN=eth0 OUT=
MAC=01:00:5e:00:00:01:08:86:3b:89:13:c6:08:00 SRC=192.168.2.1
DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1
Apr 14 16:40:32 taogypsy kernel: iptables denied: 

Re: Petit souci penible avec Virtual Box

[Stephane Ascoet]

Le 13/04/2017 17:55, VieuxGeek DuSystem a écrit :

Mais bon je me lance, ma question : as tu activé la virtualisation dans ton
bios?


Bonjour, oui bien sur, VirtualBox fonctionne, c'est juste qu'a chaque 
demarrage du systeme il faut refaire un vboxconfig, c'est long et penible.


--
Bien cordialement, Stephane Ascoet