Partitionnement d'un serveur web

[Fabrice Delvallée]

Bonjour


J'ai le projet d'installer un serveur dans mon lycée pour :

- héberger une plate-forme d'apprentissage en ligne (moodle)

- créer à la volée des images dockers contenant des notebooks python


je partirai sur :

- 2x256GO SSD en raid1 pour l'os

- 2x1TO SATA en raid1+LVM pour les données

- 64Go de mémoire


Je suis un peu perdu pour le partitionnement :(


faut-il mettre aussi LVM sur les SSD ? J'ai cru comprendre que grub

n'est pas compatible LVM, dans ce cas il me faut une partition /boot

séparée.


Merci pour votre aide

Re: Migrate Stretch to New UEFI Build?

[Stefan Monnier]

>> > more research, I've concluded I have no need for LVM, but encryption  
>> Side note: whether I need LVM or not, I just always use it.
> I never could understand that type of "reasoning." With me, if there's
> no NEED, it's not done.  I'm very much the pragmatist.

Not sure if pragmatism has much to do with it: I use LVM because it's
more convenient, even if in the end what I do with it could have been
done with partitions.


Stefan

Re: Software RAID blocks

[deloptes]

Tom Bachreier wrote:

> So it is most likely that I have a problem with the software raid or the
> harddisks, isn't it? SMART is activated on all disks and does not show
> any error.

don't know exactly but I replaced all Seagate drives with WD - especially WD
Red 2TB NAS (WD20EFRX). Now just ordered couple of them for a RAID5 storage
solution. The 2TB Red seems to be very good from all I have seen on the
customer market.

Re: Migrate Stretch to New UEFI Build?

[deloptes]

Patrick Bartek wrote:

> I never could understand that type of "reasoning." With me, if there's
> no NEED, it's not done. I'm very much the pragmatist. Always have
> been even as a child, and never likely to change.

you need it but you don't know yet
For example I leave some percentage of the disc unused and can increase the
any partition when needed - because I do not know which one will get filled
first. Now this can be challengeing without lvm and lvm does not come with
significant overhead. So why not?!

Re: kernel regression from stable to testing (acpi lid / EEEpc 1215p)

[Andrea Borgia]

quick note, the bug report has been filed: 919227

Re: Migrate Stretch to New UEFI Build?

[Patrick Bartek]

On Sun, 13 Jan 2019 09:34:06 -0500
Stefan Monnier  wrote:

> > more research, I've concluded I have no need for LVM, but encryption  
> 
> Side note: whether I need LVM or not, I just always use it.

I never could understand that type of "reasoning." With me, if there's
no NEED, it's not done. I'm very much the pragmatist. Always have
been even as a child, and never likely to change.

> It's just a much nicer option than partitions and UUIDs.

At least with Linux (unlike Windows), you can choose how YOU want to do
things.  And even though I may not agree, I support your right to do so.

B

Re: php7.3-fpm segfaults

[Georgi Naplatanov]

On 1/13/19 7:17 PM, Lucio wrote:
> Il 13/01/19 15:37, Roberto C. S�nchez ha scritto:
> I suspect the problem could be some old library files lingering around,
> because this system was first installed several years ago and tracked
> testing/sid throughout all those years. That would explain why there
> aren't any reports out there of similar problems.
> 

Hi Lucio,

you can uninstall absolute packages with aptitude.

Don't worry about your old initial installation, I did mine 8 years ago
and I've never had any problem.

HTH

Kind regards
Georgi

Re: php7.3-fpm segfaults

[Lucio]

Il 13/01/19 15:37, Roberto C. Sánchez ha scritto:

I would lean toward hardware.  Have you considered
running memtest on your system?


The problem is perfectly reproducible on my system.
Removing php7.3-mysql the problem goes away. When I install it again I 
get the problem back too. I hardly see that being caused by a faulty RAM 
module. Besides in my experience the first consequence of faulty RAM on 
Linux is a filesystem corruption.


Anyway I've double checked and ran memtest86+. No errors reported.

I suspect the problem could be some old library files lingering around, 
because this system was first installed several years ago and tracked 
testing/sid throughout all those years. That would explain why there 
aren't any reports out there of similar problems.


However I don't know how to verify my hypothesis.

Re: Unable to Access a Foreign Volume Group

[Martin]

Hi Jens,

my first shot would be setting the actual system id to 'zaphod1105820973' like 
described in the lvmsystemid man page. I'm not sure, how this uname or lvmlocal 
work, so I would try setting system_id_source to machineid or file.
First, look if /etc/machine-id matches. If not, put is may be in a 
/etc/lvm/system-id.

As this alters nothing in the LVM itself, this should not be harmful as a try.


Am 13.01.19 um 17:10 schrieb Jens Holzhäuser:
> Hello,
> 
> I have a buster/sid system with two volume groups that have made no
> issue for years.

[...]

> 
> # lvm systemid
>   system ID:
> # vgs -o systemid vg00
>   Cannot access VG vg00 with system ID zaphod1105820973 with unknown local 
> system ID.
>   Cannot access VG vg00 with system ID zaphod1105820973 with unknown local 
> system ID.
> # vgs --foreign -o +systemid
>   VG   #PV #LV #SN Attr   VSize   VFree   System ID
>   vg00   1   8   0 wz--n- 930.55g  20.00g zaphod1105820973
>   vg01   1   9   0 wz--n-  <1.50t 534.37g
> # vgchange --config 'local/extra_system_ids=["zaphod1105820973"]' --systemid 
> "" vg00
>   Cannot access VG vg00 with system ID zaphod1105820973 with unknown local 
> system ID.
>   Cannot access VG vg00 with system ID zaphod1105820973 with unknown local 
> system ID.
> 
> 
> Any help is appreciated to get back acess to the VG, vgchange (and
> vgexport) seem to be ignoring it despite providing the extra system id.


[...]

> Thanks,
> 
> 
>   Jens

Martin

Unable to Access a Foreign Volume Group

[Jens Holzhäuser]

Hello,

I have a buster/sid system with two volume groups that have made no
issue for years.
vg00 has not been actively used for a longer time, I migrated off of it,
but keep it up and around.
vg01 is holding most of the data for the system and works with no
issues. 
Both are on two separate raid1's (see details at the end).

The server has no lvm system id set (never had) and both VGs worked
flawlessly for years. I've never concerned myself with setting a system
id for the standalone server, and am assuming neither VG ever had one
set.

During a recent package update apparently vg00 got a system ID set (see
below) and lvm now is ignoring it.

I am struggling to get access back to this VG, going by the
documentation:

# lvm systemid
  system ID:
# vgs -o systemid vg00
  Cannot access VG vg00 with system ID zaphod1105820973 with unknown local 
system ID.
  Cannot access VG vg00 with system ID zaphod1105820973 with unknown local 
system ID.
# vgs --foreign -o +systemid
  VG   #PV #LV #SN Attr   VSize   VFree   System ID
  vg00   1   8   0 wz--n- 930.55g  20.00g zaphod1105820973
  vg01   1   9   0 wz--n-  <1.50t 534.37g
# vgchange --config 'local/extra_system_ids=["zaphod1105820973"]' --systemid "" 
vg00
  Cannot access VG vg00 with system ID zaphod1105820973 with unknown local 
system ID.
  Cannot access VG vg00 with system ID zaphod1105820973 with unknown local 
system ID.


Any help is appreciated to get back acess to the VG, vgchange (and
vgexport) seem to be ignoring it despite providing the extra system id.




Here are more details on how I think the situation arose, and the system
setup.

During an update via aptitude (2019-01-06  12:08:38 to 2019-01-06  12:15:32)

# grep liblvm2cmd2 /var/log/apt/term.log
Selecting previously unselected package liblvm2cmd2.03:amd64.
Preparing to unpack .../liblvm2cmd2.03_2.03.02-1_amd64.deb ...
Unpacking liblvm2cmd2.03:amd64 (2.03.02-1) ...
Removing liblvm2cmd2.02:amd64 (2.02.176-4.1) ...
Setting up liblvm2cmd2.03:amd64 (2.03.02-1) ...


the following was logged in syslog, the first time the "foreign system
ID" is showing up in my logs:


Jan  6 12:14:39 localhost systemd[1]: lvm2-lvmetad.socket: Socket unit 
configuration has changed whi
le unit has been running, no open socket file descriptor left. The socket unit 
is not functional unt
il restarted.
Jan  6 12:14:39 localhost systemd[1]: Stopping Monitoring of LVM2 mirrors, 
snapshots etc. using dmev
entd or progress polling...
Jan  6 12:14:40 localhost lvm[32256]:   9 logical volume(s) in volume group 
"vg01" unmonitored
Jan  6 12:14:40 localhost lvm[32256]:   WARNING: Found LVs active in VG vg00 
with foreign system ID zaphod1105820973.  Possible data corruption.
Jan  6 12:14:40 localhost systemd[1]: lvm2-monitor.service: Succeeded.
Jan  6 12:14:40 localhost systemd[1]: Stopped Monitoring of LVM2 mirrors, 
snapshots etc. using dmeventd or progress polling.
Jan  6 12:14:40 localhost systemd[1]: dm-event.socket: Succeeded.
Jan  6 12:14:40 localhost systemd[1]: Closed Device-mapper event daemon FIFOs.
Jan  6 12:14:40 localhost systemd[1]: Stopping Device-mapper event daemon FIFOs.
Jan  6 12:14:40 localhost systemd[1]: Listening on Device-mapper event daemon 
FIFOs.
Jan  6 12:14:40 localhost systemd[1]: Starting Monitoring of LVM2 mirrors, 
snapshots etc. using dmeventd or progress polling...
Jan  6 12:14:40 localhost lvm[32257]:   9 logical volume(s) in volume group 
"vg01" monitored
Jan  6 12:14:40 localhost lvm[32257]:   WARNING: Found LVs active in VG vg00 
with foreign system ID zaphod1105820973.  Possible data corruption.
Jan  6 12:14:40 localhost systemd[1]: Started Monitoring of LVM2 mirrors, 
snapshots etc. using dmeventd or progress polling.


Apparently lvm2 was already updated at that point to a newer version
earlier that day (2019-01-04  08:28:56 to 2019-01-04  08:32:37), not
sure how/why this happened:

# grep lvm2 /var/log/apt/term.log
Preparing to unpack .../lvm2_2.03.02-1_amd64.deb ...
Unpacking lvm2 (2.03.02-1) over (2.02.176-4.1) ...
Removing liblvm2app2.2:amd64 (2.02.176-4.1) ...
Setting up lvm2 (2.03.02-1) ...


# apt-cache policy lvm2 liblvm2cmd2.03
lvm2:
  Installed: 2.03.02-1
  Candidate: 2.03.02-1
  Version table:
 *** 2.03.02-1 500
500 http://ftp.us.debian.org/debian testing/main amd64 Packages
   -100 http://ftp.us.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status
liblvm2cmd2.03:
  Installed: 2.03.02-1
  Candidate: 2.03.02-1
  Version table:
 *** 2.03.02-1 500
500 http://ftp.us.debian.org/debian testing/main amd64 Packages
   -100 http://ftp.us.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status


# uname -a
Linux zaphod 4.20.1-20190110.zaphod #1 SMP Thu Jan 10 11:38:55 EST 2019 x86_64 
GNU/Linux

Relevant output from lsblk only, vg00 is on md1, vg01 is on md2:

# lsblk -i
sdb  8:16   0 931.5G  0 disk
|-sdb1   8:17   0   979M  0 part
`-sdb2   8:18   0 930.6G  

Re: Npostart werkt niet meer

[Paul van der Vlis]

Op 11-01-19 om 18:36 schreef Paul van der Vlis:
> Hoi,
> 
> Sinds kort werkt npostart.nl niet meer met firefox 60.4.0esr. Ik zag dit
> gistervond, wat later functioneerde het weer even. Maar vandaag weer
> niet. Verschillende klanten hebben zich gemeld met hetzelfde probleem.
> 
> De reclame doet het, maar daarna blijft hij "rondjes draaien".
> 
> Het probleem speelt met zowel Debian9 als met Debian10.
> 
> Met Firefox 64 schijnt het wel te werken op Debian9 hoorde ik van
> iemand. Vervelende zaak, ik wil geen Firefox 64 maar firefox-esr!
> 
> Widevine 1.4.8.1008 is in gebruik, dat is de laatste.

Er is iets veranderd, of ik heb eerst niet goed getest. Sommige
programma's doen het nu wel, bijvoorbeeld:
https://www.npostart.nl/heel-holland-bakt/06-01-2019/POW_03991654
En andere programma's niet, zoals:
https://www.npostart.nl/oudejaarsconference-2018/31-12-2018/BV_101390840
Live TV werkt niet.

Met Mplayer lukt het echter wel. Ook op een systeem zonder DRM en zonder
flash, zoals de PC waar ik dit op type.

Je hebt ook het programma youtube-dl nodig (ik heb youtube-dl uit
backports gebruikt). Anders werkt het niet.

Hiermee kun je live-tv kijken:
mpv https://www.npo.nl/live/npo-1

Let wel op de URL, gebruik voor live-tv "npo.nl" en niet "npostart.nl".

Bij niet-live lijkt het wel weer te werken met npostart, dit werkt:
mpv https://www.npostart.nl/oudejaarsconference-2018/31-12-2018/BV_101390840

Blijkbaar kan het dus ook zonder DRM!

Groeten,
Paul




-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: php7.3-fpm segfaults

[Roberto C . Sánchez]

On Sun, Jan 13, 2019 at 09:13:24AM -0500, Roberto C. Sánchez wrote:
> On Sun, Jan 13, 2019 at 01:31:07PM +0100, Lucio wrote:
> > Il 13/01/19 01:36, Roberto C. Sánchez ha scritto:
> > > Are there corresponding entries in the Apache log?
> > 
> > Not much to care about actually, because Apache is configured as reverse
> > proxy for php-fpm. Even raising log level I only get details about what
> > Apache is doing, not about what PHP is doing.
> > 
> > However here is the Apache error log at debug level, just in case I'm wrong:
> > 
> > https://t2m.io/82KHik8J
> > 
> 
> I agree that there is nothing much interesting there.
> 
I forgot to add that the persistent segfault looks like it could be
either a defect in php-fpm or a hardware problem (faulty memory).  Given
the absence of similar reports (which would indicate software as the
more likely culprit), I would lean toward hardware.  Have you considered
running memtest on your system?

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Software RAID blocks

[Jens Holzhäuser]

Hi!


On Sun, Jan 13, 2019 at 12:27:19PM +0100, Tom Bachreier wrote:
> Last night I got a "blocked for more than 300 seconds." message in syslog -
> see > 
> (link valid for 90 days).
> 
> Log summary:
> Jan 13 02:34:44 osprey kernel: [969696.242745] INFO: task md127_raid5:238 
> blocked for more than 300 seconds.
> Jan 13 02:34:44 osprey kernel: [969696.242772] Call Trace:
> Jan 13 02:34:44 osprey kernel: [969696.242789]  ? __schedule+0x2a2/0x870
> Jan 13 02:34:44 osprey kernel: [969696.242995] INFO: task dmcrypt_write:904 
> blocked for more than 300 seconds.
> Jan 13 02:34:44 osprey kernel: [969696.243223] INFO: task jbd2/dm-2-8:917 
> blocked for more than 300 seconds.
> Jan 13 02:34:44 osprey kernel: [969696.243525] INFO: task mpc:6622 blocked 
> for more than 300 seconds.
> Jan 13 02:34:44 osprey kernel: [969696.243997] INFO: task kworker/u8:0:6625 
> blocked for more than 300 seconds.

I am occasionally having very similar issues with my RAID1, task
blocking for more than 120 seconds, for no obvious reason.

I've started playing around with the vm.dirty_background_ratio and
vm.dirty_ratio kernel parameters, suspecting file system caching being
slow and the issue. [1]

While lowering the values does seem to have helped, it has not
completely eliminated the issue. So the jury for me is still out.

> In this case I did a
>   $ fdisk -l /dev/sdf
> and everything worked again.

Not sure if/how this would interact with ongoing cache flushing.

Jens


[1] 
https://www.blackmoreops.com/2014/09/22/linux-kernel-panic-issue-fix-hung_task_timeout_secs-blocked-120-seconds-problem/

Re: Migrate Stretch to New UEFI Build?

[Stefan Monnier]

> more research, I've concluded I have no need for LVM, but encryption

Side note: whether I need LVM or not, I just always use it.
It's just a much nicer option than partitions and UUIDs.


Stefan

Re: php7.3-fpm segfaults

[Roberto C . Sánchez]

On Sun, Jan 13, 2019 at 01:31:07PM +0100, Lucio wrote:
> Il 13/01/19 01:36, Roberto C. Sánchez ha scritto:
> > Are there corresponding entries in the Apache log?
> 
> Not much to care about actually, because Apache is configured as reverse
> proxy for php-fpm. Even raising log level I only get details about what
> Apache is doing, not about what PHP is doing.
> 
> However here is the Apache error log at debug level, just in case I'm wrong:
> 
> https://t2m.io/82KHik8J
> 

I agree that there is nothing much interesting there.

Regards,

-Roberto
-- 
Roberto C. Sánchez

Re: Software RAID blocks

[Reco]

On Sun, Jan 13, 2019 at 02:22:09PM +0100, Tom Bachreier wrote:
> 
> Hi Reco!
> 
> Jan 13, 2019, 1:47 PM by recovery...@enotuniq.net:
> 
> > On Sun, Jan 13, 2019 at 01:20:50PM +0100, Tom Bachreier wrote:
> >
> >> Jan 13, 2019, 12:46 PM by >> recovery...@enotuniq.net 
> >> >> :
> >>
> >> > On Sun, Jan 13, 2019 at 12:27:19PM +0100, Tom Bachreier wrote:
> >> >
> >> >> TLDR;
> >> >> My /home on dmcrypt -> software Raid5 blocks irregular usually without
> >> >> any error messages.
> >> >>
> >> >> I can get it going again with "fdisk -l /dev/sdx".
> >> >>
> >> >> Do you have an ideas how I can debug this issue further? Is it a 
> >> >> dmcrypt,
> >> >> a dm-softraid or a hardware issue?
> >> >>
> >> >
> >> > Let's start with something uncommon:
> >> >
> >>
> >> Thanks for your suggestions.
> >>
> >
> > My suspicion is that either some/all HDDs' firmware or disk controller
> > puts drive(s) in sleep mode.
> >
> 
> In this case: Why don't they awake with a write from dm-raid but with
> a read from fdisk? I don't see the logic behind.

RAID5 may be the reason. If you're reading a short sequence of bytes
from the array it does not mean you're utilizing all the drives.


> >> hdparm seems OK. Keep in mind only sdc and sdf ar WD drives.
> >>
> >
> > Since you have Seagates, please check them with 'hdparm -Z'.
> >
> 
> I don't think that did much to my drives.

I agree. It seems that drive's firmware rejected the request.


> $ smartctl -l scterc,70,70 /dev/sdd
> SCT Error Recovery Control set to:
>    Read: 70 (7.0 seconds)
>   Write: 70 (7.0 seconds)
> 

This setting may not survive the powercycle. Happen to have four such
drives. I just apply it at every reboot.

Reco

Re: Software RAID blocks

[Tom Bachreier]

Hi Reco!

Jan 13, 2019, 1:47 PM by recovery...@enotuniq.net:

> On Sun, Jan 13, 2019 at 01:20:50PM +0100, Tom Bachreier wrote:
>
>> Jan 13, 2019, 12:46 PM by >> recovery...@enotuniq.net 
>> >> :
>>
>> > On Sun, Jan 13, 2019 at 12:27:19PM +0100, Tom Bachreier wrote:
>> >
>> >> TLDR;
>> >> My /home on dmcrypt -> software Raid5 blocks irregular usually without
>> >> any error messages.
>> >>
>> >> I can get it going again with "fdisk -l /dev/sdx".
>> >>
>> >> Do you have an ideas how I can debug this issue further? Is it a dmcrypt,
>> >> a dm-softraid or a hardware issue?
>> >>
>> >
>> > Let's start with something uncommon:
>> >
>>
>> Thanks for your suggestions.
>>
>
> My suspicion is that either some/all HDDs' firmware or disk controller
> puts drive(s) in sleep mode.
>

In this case: Why don't they awake with a write from dm-raid but with
a read from fdisk? I don't see the logic behind.


>> hdparm seems OK. Keep in mind only sdc and sdf ar WD drives.
>>
>
> Since you have Seagates, please check them with 'hdparm -Z'.
>

I don't think that did much to my drives.

$ hdparm -Z /dev/sdb
/dev/sdb:
disabling Seagate auto powersaving mode
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 04 51 40 00 21 04 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

$ hdparm -Z /dev/sde
/dev/sde:
disabling Seagate auto powersaving mode
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 04 51 40 00 21 04 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


> Unsure about that Toshiba drive, though.
>
> I'd be wary of including those into the RAID (a single bad block can
> paralyze your whole RAID):
>
>> DISK: /dev/sdc
>> DISK: /dev/sde
>>

Thanks, I keep that in mind. I try to replace them in the near future.


> And I'd enable it for sdd.
>

Done.

$ smartctl -l scterc,70,70 /dev/sdd
SCT Error Recovery Control set to:
   Read: 70 (7.0 seconds)
  Write: 70 (7.0 seconds)

Tom

Re: allocating disk space

[David Wright]

On Fri 11 Jan 2019 at 02:12:19 (-0500), Felix Miata wrote:
> David Wright composed on 2019-01-09 14:26 (UTC-0600):
> 
> > On Fri 04 Jan 2019 at 19:36:42 (-0500), Felix Miata wrote:
> 
> >> Yes, when filling the disk at the outset. With the escalation of disk 
> >> sizes over the years, it's
> >> become more common not to allocate 100% at the outset. In non-ancient 
> >> memory I only ever fully
> >> allocated with my own disks at the outset with data disks, until small 
> >> SDDs became cheap.
> 
> > I don't understand the reasoning.
> 
> A Murphy corollary: Junk accumulates according to the amount of space 
> available for it to fill.
> Make the space available when you really need it, and it won't be preoccupied 
> with junk.

Fine, if it helps you. I was unaware that anyone did this for that
reason. I know there are more technical difficulties with shrinking
partitions than with expanding them, and thought it might be to do
with that.

> >> Note the relative vastness of unused space.
> 
> > You're not the guy who boots >>100 systems off one disk, are you?
> 
> The one I remember was long ago, not 100 I think, but more than 50, likely 
> before libata
> introduction's 15 partition limit. I recently looked for his page but failed 
> to find.

100 was superceded long ago; it was 145 by August 2016 when I last looked.
http://forums.justlinux.com/showthread.php?147959-How-to-install-and-boot-145-operating-systems-in-a-PC

> >> BTW, 36 is near an average count here. I have one with 57, more than one 
> >> with >40, and
> >> probably 8 with >30. My newest PC has 50, though spread across 3 disks, 
> >> with 20
> >> comprising 10 RAID1 devices, and zero freespace remaining for partition 
> >> creation.
> 
> > Oh, perhaps you're a rival. :) I assume you foresee adding a lot more
> > versions of linux; only three Debian so far? And I would miss a real
> > DOS like the old favourite 6.22.
> 
> Except for Etch, I was only using Kubuntu's miscreant Debians until Jessie. 
> All my 6.22s got
> replaced with PC DOS 2000 as soon as impending Y2K caused its availability. 
> DOS 5 remains available
> under cover of OS/2's eComStation progeny (which here runs 24/7).
> 
> > ... if I get my hands on an old newer machine (or is that new older?).
> 
> I get those more often than new-in-original-box, more often broken, which I 
> am often able to
> resurrect. Maybe call them nacqres, for newly acquired 
> resurrection/recycle/refurb. :-)

In the past, the (desktop) systems I acquired were mainly deficient in
diskspace. Fortunately I managed to tap the source of 1GB disks that
were being used to make it possible to upgrade the secretaries'
windows systems (whose older PCs I was acquiring). Occasionally I
added memory (or "stole" it from other machines). Since I retired,
I've only bought disks. I've never had a new PC. The three desktops
I run date from 2000 and 2006 (2).

Cheers,
David.

Re: Debian 9 /boot && /boot/efi partition

[Pascal Hambourg]

Le 10/01/2019 à 22:02, Jonathan Dowland a écrit :


I think EFI also mandates the layout of the filesystem to the extent
that one could not simply use /boot as the EFI partition, formatted
as FAT32, but I'm not entirely sure.


/boot can be the EFI partition in the systemd boot specification.


But is may disrupt Debian kernel updates because FAT does not support 
hard links.

Re: Software RAID blocks

[Reco]

Hi.

On Sun, Jan 13, 2019 at 01:20:50PM +0100, Tom Bachreier wrote:
> 
> Hi Reco!
> 
> Jan 13, 2019, 12:46 PM by recovery...@enotuniq.net:
> 
> > On Sun, Jan 13, 2019 at 12:27:19PM +0100, Tom Bachreier wrote:
> >
> >> TLDR;
> >> My /home on dmcrypt -> software Raid5 blocks irregular usually without
> >> any error messages.
> >>
> >> I can get it going again with "fdisk -l /dev/sdx".
> >>
> >> Do you have an ideas how I can debug this issue further? Is it a dmcrypt,
> >> a dm-softraid or a hardware issue?
> >>
> >
> > Let's start with something uncommon:
> >
> > for x in /dev/sd{b..f}; do
> >  smartctl -l scterc $x
> >  hdparm -J $x
> > done
>
> Thanks for your suggestions.

My suspicion is that either some/all HDDs' firmware or disk controller
puts drive(s) in sleep mode.


> hdparm seems OK. Keep in mind only sdc and sdf ar WD drives.

Since you have Seagates, please check them with 'hdparm -Z'.
Unsure about that Toshiba drive, though.


That looks good, though:

> /dev/sdc:
> wdidle3  = disabled
> 
> /dev/sdf:
> wdidle3  = disabled


I'd be wary of including those into the RAID (a single bad block can
paralyze your whole RAID):

> -
> And here comes the SCT state:
> 
> DISK: /dev/sdc
> SCT Error Recovery Control command not supported
> 
> 
> DISK: /dev/sde
> SCT Error Recovery Control command not supported

And I'd enable it for sdd.

Reco

Re: php7.3-fpm segfaults

[Lucio]

Il 13/01/19 01:36, Roberto C. Sánchez ha scritto:

Are there corresponding entries in the Apache log?


Not much to care about actually, because Apache is configured as reverse 
proxy for php-fpm. Even raising log level I only get details about what 
Apache is doing, not about what PHP is doing.


However here is the Apache error log at debug level, just in case I'm wrong:

https://t2m.io/82KHik8J

Re: Software RAID blocks

[Tom Bachreier]

Hi Reco!

Jan 13, 2019, 12:46 PM by recovery...@enotuniq.net:

> On Sun, Jan 13, 2019 at 12:27:19PM +0100, Tom Bachreier wrote:
>
>> TLDR;
>> My /home on dmcrypt -> software Raid5 blocks irregular usually without
>> any error messages.
>>
>> I can get it going again with "fdisk -l /dev/sdx".
>>
>> Do you have an ideas how I can debug this issue further? Is it a dmcrypt,
>> a dm-softraid or a hardware issue?
>>
>
> Let's start with something uncommon:
>
> for x in /dev/sd{b..f}; do
>  smartctl -l scterc $x
>  hdparm -J $x
> done
>
Thanks for your suggestions.

hdparm seems OK. Keep in mind only sdc and sdf ar WD drives.

$ hdparm -J /dev/sd[bcdef]
/dev/sdb:
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 04 51 a0 00 21 04 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 04 51 a0 00 21 04 
00 00 00 be 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 04 51 a0 00 21 04 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
wdidle3  = 1 ??

/dev/sdc:
wdidle3  = disabled

/dev/sdd:
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 04 51 00 00 21 04 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 04 51 00 00 21 04 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
wdidle3  = disabled

/dev/sde:
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 04 51 a0 00 21 04 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 04 51 a0 00 21 04 
00 00 00 be 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 04 51 a0 00 21 04 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
wdidle3  = 1 ??

/dev/sdf:
wdidle3  = disabled

-
And here comes the SCT state:

$ for i in /dev/sd{b..f}; do echo "DISK: ${i}"; smartctl -l scterc "${i}"; done
DISK: /dev/sdb
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.19.0-1-amd64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org 


SCT Error Recovery Control:
   Read: 70 (7.0 seconds)
  Write: 70 (7.0 seconds)

DISK: /dev/sdc
SCT Error Recovery Control command not supported

DISK: /dev/sdd
SCT Error Recovery Control:
   Read: Disabled
  Write: Disabled

DISK: /dev/sde
SCT Error Recovery Control command not supported

DISK: /dev/sdf
SCT Error Recovery Control:
   Read: 70 (7.0 seconds)
  Write: 70 (7.0 seconds)

Hope this helps...
Tom

Re: Software RAID blocks

[Reco]

Hi.

On Sun, Jan 13, 2019 at 12:27:19PM +0100, Tom Bachreier wrote:
> TLDR;
> My /home on dmcrypt -> software Raid5 blocks irregular usually without
> any error messages.
> 
> I can get it going again with "fdisk -l /dev/sdx".
> 
> Do you have an ideas how I can debug this issue further? Is it a dmcrypt,
> a dm-softraid or a hardware issue?

Let's start with something uncommon:

for x in /dev/sd{b..f}; do
smartctl -l scterc $x
hdparm -J $x
done

Reco

Software RAID blocks

[Tom Bachreier]

Hi!

TLDR;
My /home on dmcrypt -> software Raid5 blocks irregular usually without
any error messages.

I can get it going again with "fdisk -l /dev/sdx".

Do you have an ideas how I can debug this issue further? Is it a dmcrypt,
a dm-softraid or a hardware issue?

---

Long version:
My /home "partition" is a dmcrypt on software RAID5 with 5 SATA disks.
See System info further down in this mail.
Once in a while user programs freeze because the dmcrypt or something
else further down the chain blocks during a write? on /home.
Am I lycky and had a running root shell open I can run a
  $ fdisk -l /dev/sdx
to one of the harddisks in the RAID and the block disappears instantly.

I checked if it could be a spindown power management problem but all
disks which have a PM feature have it disabled. So I don't think this is
the problem.

Last night I got a "blocked for more than 300 seconds." message in syslog -
see > 
(link valid for 90 days).

Log summary:
Jan 13 02:34:44 osprey kernel: [969696.242745] INFO: task md127_raid5:238 
blocked for more than 300 seconds.
Jan 13 02:34:44 osprey kernel: [969696.242772] Call Trace:
Jan 13 02:34:44 osprey kernel: [969696.242789]  ? __schedule+0x2a2/0x870
Jan 13 02:34:44 osprey kernel: [969696.242995] INFO: task dmcrypt_write:904 
blocked for more than 300 seconds.
Jan 13 02:34:44 osprey kernel: [969696.243223] INFO: task jbd2/dm-2-8:917 
blocked for more than 300 seconds.
Jan 13 02:34:44 osprey kernel: [969696.243525] INFO: task mpc:6622 blocked for 
more than 300 seconds.
Jan 13 02:34:44 osprey kernel: [969696.243997] INFO: task kworker/u8:0:6625 
blocked for more than 300 seconds.

In this case I did a
  $ fdisk -l /dev/sdf
and everything worked again.

As I understand the log mpc (user program) started and maybe accessed the
config file on /home. The ext4 tried to save the new access time which
got down the chain jbd2 -> dmcrypt and blocked in the end in md127_raid5.

So it is most likely that I have a problem with the software raid or the
harddisks, isn't it? SMART is activated on all disks and does not show
any error.

How can I debug this further to solve the problem? Thanks in advance for
your suggestions.

Tom

---
System info:

Debian testing

$ uname -a
Linux osprey 4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 (2018-12-22) x86_64 
GNU/Linux

$ lsblk -i
NAME  MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda 8:0    0 74.5G  0 disk
|-sda1  8:1    0    4G  0 part
| `-cswap1    253:1    0    4G  0 crypt [SWAP]
`-sda2  8:2    0 70.5G  0 part
  `-osprey_root   253:0    0 70.5G  0 crypt /
sdb 8:16   0  2.7T  0 disk
`-sdb1  8:17   0  2.7T  0 part
  `-md127   9:127  0 10.9T  0 raid5
    `-osprey_home 253:2    0 10.9T  0 crypt /home
sdc 8:32   0  2.7T  0 disk
`-sdc1  8:33   0  2.7T  0 part
  `-md127   9:127  0 10.9T  0 raid5
    `-osprey_home 253:2    0 10.9T  0 crypt /home
sdd 8:48   0  2.7T  0 disk
`-sdd1  8:49   0  2.7T  0 part
  `-md127   9:127  0 10.9T  0 raid5
    `-osprey_home 253:2    0 10.9T  0 crypt /home
sde 8:64   0  2.7T  0 disk
`-sde1  8:65   0  2.7T  0 part
  `-md127   9:127  0 10.9T  0 raid5
    `-osprey_home 253:2    0 10.9T  0 crypt /home
sdf 8:80   0  2.7T  0 disk
`-sdf1  8:81   0  2.7T  0 part
  `-md127   9:127  0 10.9T  0 raid5
    `-osprey_home 253:2    0 10.9T  0 crypt /home

$ sdparm --get STANDBY /dev/sd[bcdef]
    /dev/sdb: ATA   ST3000VN000-1H41  SC43
STANDBY not found in Power condition [po] mode page
    /dev/sdc: ATA   WDC WD30EURX-63T  0A80
STANDBY not found in Power condition [po] mode page
    /dev/sdd: ATA   TOSHIBA DT01ACA3  ABB0
STANDBY not found in Power condition [po] mode page
    /dev/sde: ATA   ST3000DM001-1CH1  CC27
STANDBY not found in Power condition [po] mode page
    /dev/sdf: ATA   WDC WD30EFRX-68E  0A80
STANDBY not found in Power condition [po] mode page

$ hdparm -B /dev/sd[bcdef]
/dev/sdb:
APM_level  = 254
/dev/sdc:
APM_level  = not supported
/dev/sdd:
APM_level  = off
/dev/sde:
APM_level  = 254
/dev/sdf:
APM_level  = not supported

$ cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] 
[raid10]
md127 : active raid5 sdc1[1] sdd1[2] sdb1[0] sdf1[5] sde1[3]
  11719766016 blocks super 1.2 level 5, 512k chunk, algorithm 2 [5/5] 
[U]
  bitmap: 1/22 pages [4KB], 65536KB chunk
unused devices: 

$ for i in {b..f}; do echo "DISK: ${i}"; smartctl -a "/dev/sd${i}" |grep "SMART 
overall-health self-assessment test result"; done
DISK: b
SMART overall-health self-assessment test result: PASSED
DISK: c
SMART overall-health 

Re: The Dark Mod on Stretch?

[Reco]

Hi.

On Sat, Jan 12, 2019 at 11:55:19AM -0500, Boyan Penkov wrote:
> I suspect I am unable to find the default.cfg since I am not running
> through all the stuff  that tdm_updater uses.  Any thoughts here?

Sorry to say, but you're on your own here. This Quake stuff is something
that's I've lost interest to like 10 years ago.
On the bright side - it built, so at least something has gone according
to the plan.

Reco

Re: Em podeu donar un cop de ma amb un bug?

[Ernest Adrogué]

Hola,

2019-01-12, 12:40 (+0100); a...@probeta.net escriu:
> Fins al nucli 4.13 tot anava bé, però en actualitzar al nucli 4.14
> l’escriptori Gnome es «congelava» cada pocs minuts. A tots els següents
> nuclis fins el 4.19 el problema persisteix. A aquest enllaç hi ha els canvis
> que aporta el nucli 4.14 a Radeon, però no els sé interpretar:
> https://kernelnewbies.org/Linux_4.14#Graphics
> 
>  Pista: Es congelava Gnome amb Xorg, però no Gnome amb Wayland
> 
>  Pista: no es congelava XFCE
> 
>  Pista: fent CTRL+ALT+F8 i després CTRL+ALT+F7 tot tornava a funcionar
> 
> Vaig treure Gnome i vaig continuar amb XFCE i amb Mate, però algunes
> aplicacions importants es continuen congelant cada pocs minuts: VLC,
> Mplayer, Chromium, però no Firefox
> 
>  Pista: fent CTRL+ALT+F8 i després CTRL+ALT+F7 tot torna a funcionar
> 
>  Pista: no apareix res als logs amb «dmesg», ni als logs de Xorg, ni als
> logs de VLC
> 
>  Pista potser gran: en realitat he descobert que les aplicacions «no es
> congelen». Continuen funcionant bé, però ja no es «dibuixen» a la finestra,
> el que fa semblar que l’aplicació «s’ha congelat».

Pel que dius, semblaria un problema del compositor, que no actualitza
l'estat de la pantalla correctament.  Ara bé, si et passa amb Gnome i
també amb Xfce, que utilitzen compositors diferents, aleshores m'inclino
a pensar que és una altra cosa.

> Resum: del kernel 4.14 en endavant, amb targetes gràfiques Radeon, i amb
> Xorg però no amb Wayland, alguna cosa fa que aleatòriament les finestres de
> VLC, Mplayer, Chromium es deixin de dibuixar («es congelin») malgrat
> aquestes aplicacions estiguin funcionant perfectament. Tot torna a funcionar
> fent CTRL+ALT+F8 seguit de CTRL+ALT+F7
> 
> No sé ni per on començar. Algun consell?

Els problemes que tenen a veure amb el sistema gràfic són difícils de
solucionar pel teu compte, a no ser que siguis un expert en el tema.  Si
el bug és reproduïble (és a dir es produeix sempre que fas alguna cosa
concreta), pots anar provant diferents versions del programari sospitós
de causar-lo i veure exactament quina versió introdueix el problema.
Amb aquest mètode podries veure fins i tot quina línia de codi és la
culpable, però clar, si has d'anar compilant versions i sub-versions del
kernel, o de altres components complexos, és una feinada considerable.
Probablement és més pràctic tornar a una versió anterior que saps que
funciona i posar-la en estat "hold", i esperar que solucionin el
problema a les versions més recents.

Salut.

Re: zoneminder in experimental

[Dmitry Smirnov]

On Sunday, 13 January 2019 12:14:26 AM AEDT Rainer Dorsch wrote:
> I just saw you manage an incredible amount of Debian packages:
> 
> https://qa.debian.org/developer.php?email=onlyjob%40debian.org

Well, I did some work on all those packages some time ago but now they do not 
receive the same amount of attention...


> Many thanks for that. While looking through the list, I discovered
> brainparty, which I did not know before.

Thank you. Brainparty is awesome but I did not hear from upstream in years.
Project appears to be dormant but the package still works well (at least last 
time I tried it).


> I am using zoneminder here in stretch. I saw you uploaded several new
> versions 1.32.x to experimental. I am just wondering if you intend to
> upload a new version to sid before the release of buster or do the
> versions 1.32.x have severe limitations over the version 1.30.4 which is
> currently in sid and buster?

Current blocker is this:

  https://github.com/ZoneMinder/zoneminder/issues/2220

I hope that the next release might be good enough for "unstable" and then it 
shouldn't take too long until it propagates to "testing" hopefully.

-- 
Best wishes,
 Dmitry Smirnov.

---

Truth — Something somehow discreditable to someone.
-- H. L. Mencken, 1949


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

Re: Looking for advice on tools (or libraries) for unsupervised, bulk symmetric encryption/decryption of files

[John Crawley]

On 13/01/2019 12.46, Celejar wrote:

On Fri, 11 Jan 2019 21:45:57 +

I believe that the most commonly used software for file level
encryption is EncFS. I haven't really used it much, and can't speak to
its long term stablity.


EncFS should not be used for any new file encryption project, IMHO.
There was the following report in 2014:
https://defuse.ca/audits/encfs.htm
This is referenced in the NEWS file in the EncFS package
https://salsa.debian.org/debian/encfs/blob/debian/sid/debian/NEWS

Both the report and the NEWS file are 5 years sold so I am not sure of
its current status but I'd want to seek positive assurance.


Huh - good to know. But I was wondering, along similar (but less
informed) lines, how good some of the other suggestions were, e.g.
ccrypt. I know very little about ccrypt, but has it even been
audited at all? Is it sufficiently widely used that any vulnerablities
or misimplementations of the sort discovered by the EncFS audit would
have been looked for or turned up?


Looking at encfs, gocryptfs showed up, which claims "This project was  
inspired by EncFS and strives to fix its security issues while providing  
good performance":

https://packages.debian.org/stretch/gocryptfs
https://github.com/rfjakob/gocryptfs

No personal experience (yet) of using it though.
--
John

Re: iotop not working

[Curt]

On 2019-01-13, Rob McCathie  wrote:
> Hi List,
>
> I run Stretch, I've just installed iotop and when I try to run it I get 
> this:



> parse_proc_pid_status
>      key, value = line.split(':\t', 1)
> ValueError: not enough values to unpack (expected 2, got 1)
>
>
> Any help appreciated.
>
>

Looks like this bug:

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

For which this is the fix:

https://repo.or.cz/iotop.git/commitdiff/7814f30a5ed65acd07f284bba991ca557788ee80