Bug#1064624: Hard to short-stroke an encrypted drive

[Matthew Wilcox]

On Mon, Feb 26, 2024 at 12:34:50AM +0100, Pascal Hambourg wrote:
> Not if you do not write anything to them, or if you TRIM them.

You can stop explaining to me how TRIM works.

commit 0c659b82d11e
Author: Matthew Wilcox 
Date:   Thu Apr 2 10:37:25 2009 -0400

ata: Add TRIM infrastructure

> You may either
> - tell the installer not to erase (=write) the encrypted partition (if
> guided partitioning prompts it, not sure)
> or
> - enable "discard" in /etc/crypttab (should be the default)
> - create a logical volume in the free VG space
> - blkdiscard the logical volume

Last time I checked, dm-crypt did not pass DISCARD requests through to
the underlying device because it's a security hazard.

Bug#1064624: Hard to short-stroke an encrypted drive

[Pascal Hambourg]

On 25/02/2024 at 23:55, Matthew Wilcox wrote:


I want "use largest contiguous space and set up encrypted LVM".
That would let me reserve 200GB of my SSD as unencrypted free space,
which will improve the write endurance of my SSD.


Alternatively, the installer allows to reserve free space in the encrypted
volume group.


That does not accomplish my goal of extending the life of my SSD.  The
SSD will see those blocks as "in use" because they have encrypted data
written to them


Not if you do not write anything to them, or if you TRIM them.

You may either
- tell the installer not to erase (=write) the encrypted partition (if 
guided partitioning prompts it, not sure)

or
- enable "discard" in /etc/crypttab (should be the default)
- create a logical volume in the free VG space
- blkdiscard the logical volume


(it cannot tell that they are encrypted blocks of zeroes
because, well, they're encrypted).


Irrelevant. Once written, even with plaintext zeroes, a block is 
considered used until it is TRIMmed.

Bug#1064624: Hard to short-stroke an encrypted drive

[Matthew Wilcox]

On Sun, Feb 25, 2024 at 11:42:37PM +0100, Pascal Hambourg wrote:
> On 25/02/2024 at 05:40, Matthew Wilcox wrote:
> > 
> > The partitioner "guided partitioning" offers me:
> > 
> >   - use the largest continuous free space
> >   - use entire disk
> >   - use entire disk and set up LVM
> >   - use entire disk and set up encrypted LVM
> > 
> > I want "use largest contiguous space and set up encrypted LVM".
> > That would let me reserve 200GB of my SSD as unencrypted free space,
> > which will improve the write endurance of my SSD.
> 
> Alternatively, the installer allows to reserve free space in the encrypted
> volume group.

That does not accomplish my goal of extending the life of my SSD.  The
SSD will see those blocks as "in use" because they have encrypted data
written to them (it cannot tell that they are encrypted blocks of zeroes
because, well, they're encrypted).

The unused area has to be part of the unencrypted disk.  And then I have
to call TRIM on it.

> > Also once I start partitioning, eg, "and set up LVM", I can't delete the
> > partitions again.
> 
> The installer allows to delete logical volumes, volume groups and
> unencrypted partitions formerly used as physical volumes, but not encrypted
> volumes nor their underlying partitions.

Yes.  This is a poor experience.

Bug#1064624: Hard to short-stroke an encrypted drive

[Pascal Hambourg]

On 25/02/2024 at 05:40, Matthew Wilcox wrote:


The partitioner "guided partitioning" offers me:

  - use the largest continuous free space
  - use entire disk
  - use entire disk and set up LVM
  - use entire disk and set up encrypted LVM

I want "use largest contiguous space and set up encrypted LVM".
That would let me reserve 200GB of my SSD as unencrypted free space,
which will improve the write endurance of my SSD.


Alternatively, the installer allows to reserve free space in the 
encrypted volume group.



Also once I start partitioning, eg, "and set up LVM", I can't delete the
partitions again.


The installer allows to delete logical volumes, volume groups and 
unencrypted partitions formerly used as physical volumes, but not 
encrypted volumes nor their underlying partitions.

Bug#1064617: Passwords should not be changed frequently

[Pascal Hambourg]

On 25/02/2024 at 01:17, Matthew Wilcox wrote:


I just did an installation with the 2024-02-24
debian-testing-amd64-netinst.iso image.  I forget the exact wording
used, but when setting up a user, d-i printed advice that user passwords
should be changed frequently.  This is no longer current good advice
(since 2017):


This topic has some history, see

Bug#1064791: No ethernet card in a laptop

[Matthew Wilcox]

Package: debian-installer

On my new laptop, d-i prints "No Ethernet card was detected.  If you know
the name of the driver (etc)".  This confused me, as I thought it _also_
couldn't find the wifi driver (since it's a new laptop, it's possible
the d-i kernel doesn't know about the wifi device).

I suggest that if d-i can find a wifi device, it skips the step where
it gives me a long inscrutable list of module names and asks me to
choose one to make the network work.

Re: Bug#1064588: bookworm-pu: package glibc/2.36-9+deb12u5

[Jonathan Wiltshire]

Control: tag -1 d-i

Hi,

On Sat, Feb 24, 2024 at 04:59:10PM +0100, Aurelien Jarno wrote:
> [ Reason ]
> The upstream stable branch got a few fixes in the last months, and this
> update pulls them into the debian package.
> 
> [ Impact ]
> In case the update isn't approved, systems will be left with a few
> issues, and the differences with upstream will increase, which might
> make next fixes more difficult to review.

I'm happy with it from SRM point of view, but as you say d-i ack needed.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1