On Ma, 02 iul 19, 08:02:22, The Wanderer wrote:
> On 2019-07-01 at 03:47, Curt wrote:
> >
> > https://www.debian.org/releases///buster/s390x/release-notes/ch-information.en.html#migrate-interface-names
>
> I'm skeptical as to whether this is (still/currently) accurate.
This was fixed in the mean
On 2/07/19 9:13 PM, Gene Heskett wrote:
> On Monday 01 July 2019 19:42:08 David Wright wrote:
>
>> On Mon 01 Jul 2019 at 15:56:14 (-0400), Gene Heskett wrote:
>>> On Monday 01 July 2019 09:33:35 David Wright wrote:
On Mon 01 Jul 2019 at 06:05:52 (-0400), Gene Heskett wrote:
>>> Whole filesys
The Wanderer wrote:
On 2019-07-02 at 10:10, Curt wrote:
On 2019-07-02, The Wanderer wrote:
Not even that, it seems (no longer affects systemd).
Have you confirmed that? It seems possible that on a systemd
machine, things in other packages (such as whatever would provide
that 99-default.lin
On Tue 02 Jul 2019 at 10:22:56 -0400, The Wanderer wrote:
> On 2019-07-02 at 10:10, Curt wrote:
>
> > On 2019-07-02, The Wanderer wrote:
> >
> >>> Not even that, it seems (no longer affects systemd).
> >>
> >> Have you confirmed that? It seems possible that on a systemd
> >> machine, things in
On 2019-07-02 at 10:10, Curt wrote:
> On 2019-07-02, The Wanderer wrote:
>
>>> Not even that, it seems (no longer affects systemd).
>>
>> Have you confirmed that? It seems possible that on a systemd
>> machine, things in other packages (such as whatever would provide
>> that 99-default.link fil
On 2019-07-02, The Wanderer wrote:
>> Not even that, it seems (no longer affects systemd).
>
> Have you confirmed that? It seems possible that on a systemd machine,
> things in other packages (such as whatever would provide that
> 99-default.link file, which unfortunately - because it's under /et
On 2019-07-02 at 09:10, Greg Wooledge wrote:
> On Tue, Jul 02, 2019 at 08:51:10AM -0400, The Wanderer wrote:
>
>> On 2019-07-02 at 08:37, Curt wrote:
>>
>>> Not even that, it seems (no longer affects systemd).
>>
>> Have you confirmed that?
>
> I'm using systemd, and the 70-* file was used whe
On Tue, Jul 02, 2019 at 08:51:10AM -0400, The Wanderer wrote:
> On 2019-07-02 at 08:37, Curt wrote:
> > Not even that, it seems (no longer affects systemd).
>
> Have you confirmed that?
I'm using systemd, and the 70-* file was used when I upgraded to buster,
but that was roughly 2 months ago. I
On 2019-07-02 at 08:37, Curt wrote:
> On 2019-07-02, The Wanderer wrote:
>> /usr/share/doc/udev/README.Debian.gz has a section on the subject
>> of migration from the old naming scheme to the new one. Although it
>> does not seem to state as much explicitly, from that section (and
>> other parts
On 2019-07-02, The Wanderer wrote:
>> https://www.debian.org/releases///buster/s390x/release-notes/ch-informa=
> tion.en.html#migrate-interface-names
>
> (Any particular reason you linked to the s390x version of the release
> notes? It seems to match e.g. the amd64 one for this purpose, so it
> s
On 2019-07-01 at 03:47, Curt wrote:
> Another, less serious, gotcha for those inveterate upgraders and
> newbies who don't read the release notes is that
> '/etc/udev/rules.d/70-persistent-net.rules' is no longer a valid
> mechanism for defining device names. This mechanism (automagically)
> pe
On Monday 01 July 2019 19:42:08 David Wright wrote:
> On Mon 01 Jul 2019 at 15:56:14 (-0400), Gene Heskett wrote:
> > On Monday 01 July 2019 09:33:35 David Wright wrote:
> > > On Mon 01 Jul 2019 at 06:05:52 (-0400), Gene Heskett wrote:
> > > > On Monday 01 July 2019 03:52:55 Jonathan Dowland wrote
On Mon 01 Jul 2019 at 15:56:14 (-0400), Gene Heskett wrote:
> On Monday 01 July 2019 09:33:35 David Wright wrote:
> > On Mon 01 Jul 2019 at 06:05:52 (-0400), Gene Heskett wrote:
> > > On Monday 01 July 2019 03:52:55 Jonathan Dowland wrote:
> > > > On Sun, Jun 30, 2019 at 12:45:57PM -0400, Gene Hesk
On Mon, Jul 01, 2019 at 03:56:14PM -0400, Gene Heskett wrote:
Whole filesystem encryption would be a total non-starter for me. File by
file with different passwd's according to whats in the file would make
far more sense to me. Thats my $0.02.
In which case none of cryptsetup/luks/dm-crypt, ec
On Monday 01 July 2019 09:33:35 David Wright wrote:
> On Mon 01 Jul 2019 at 06:05:52 (-0400), Gene Heskett wrote:
> > On Monday 01 July 2019 03:52:55 Jonathan Dowland wrote:
> > > On Sun, Jun 30, 2019 at 12:45:57PM -0400, Gene Heskett wrote:
> > > >At this point, I'd call it a buster delaying bug.
On Monday 01 July 2019 09:14:07 Curt wrote:
> On 2019-07-01, Gene Heskett wrote:
> > On Monday 01 July 2019 03:52:55 Jonathan Dowland wrote:
> >> On Sun, Jun 30, 2019 at 12:45:57PM -0400, Gene Heskett wrote:
> >> >At this point, I'd call it a buster delaying bug. That last is
> >> > going to cos
On 2019-07-01, Greg Wooledge wrote:
>> >
>> > For whatever it's worth, when I upgraded this machine from stretch to
>> > buster a couple months ago, it continued using eth0 as the interface
>> > name without any immediately obvious issues. I did the conversion to
>> > "predictable interface names
On Mon, Jul 01, 2019 at 02:15:50PM -, Curt wrote:
> On 2019-07-01, Greg Wooledge wrote:
> > On Mon, Jul 01, 2019 at 07:47:35AM -, Curt wrote:
> >> Another, less serious, gotcha for those inveterate upgraders and newbies
> >> who don't read the release notes is that
> >> '/etc/udev/rules.d/
On 2019-07-01, Greg Wooledge wrote:
> On Mon, Jul 01, 2019 at 07:47:35AM -, Curt wrote:
>> Another, less serious, gotcha for those inveterate upgraders and newbies
>> who don't read the release notes is that
>> '/etc/udev/rules.d/70-persistent-net.rules' is no longer a valid
>> mechanism for d
On Mon, Jul 01, 2019 at 07:47:35AM -, Curt wrote:
> Another, less serious, gotcha for those inveterate upgraders and newbies
> who don't read the release notes is that
> '/etc/udev/rules.d/70-persistent-net.rules' is no longer a valid
> mechanism for defining device names.
For whatever it's wo
On 2019-07-01, Jonathan Dowland wrote:
> On Mon, Jul 01, 2019 at 01:14:07PM -, Curt wrote:
>>The second triad of NUMBER % RANK columns corresponds to the number of people
>>using the package regularly* and by that metric ecryptfs-utils beats encfs by
>>a
>>relative long shot (1066 to 630, 0.5
On Mon, Jul 01, 2019 at 01:14:07PM -, Curt wrote:
The second triad of NUMBER % RANK columns corresponds to the number of people
using the package regularly* and by that metric ecryptfs-utils beats encfs by a
relative long shot (1066 to 630, 0.58% to 0.34%).
"relative" to what? That's what t
On Mon, Jul 01, 2019 at 08:33:35AM -0500, David Wright wrote:
The grey area is for me is the relative benefit of encrypting file by
file compared with the whole partition. Assuming that there's just one
passphrase involved in each scenario, is more protection given by the
former method? After all
On Mon 01 Jul 2019 at 06:05:52 (-0400), Gene Heskett wrote:
> On Monday 01 July 2019 03:52:55 Jonathan Dowland wrote:
> > On Sun, Jun 30, 2019 at 12:45:57PM -0400, Gene Heskett wrote:
> > >At this point, I'd call it a buster delaying bug. That last is going
> > > to cost too many that can't ignore
On 2019-07-01, Gene Heskett wrote:
> On Monday 01 July 2019 03:52:55 Jonathan Dowland wrote:
>
>> On Sun, Jun 30, 2019 at 12:45:57PM -0400, Gene Heskett wrote:
>> >At this point, I'd call it a buster delaying bug. That last is going
>> > to cost too many that can't ignore it and don't have unencr
On Monday 01 July 2019 03:52:55 Jonathan Dowland wrote:
> On Sun, Jun 30, 2019 at 12:45:57PM -0400, Gene Heskett wrote:
> >At this point, I'd call it a buster delaying bug. That last is going
> > to cost too many that can't ignore it and don't have unencrypted
> > backups. Thats going to be a lot
On Sun, Jun 30, 2019 at 12:45:57PM -0400, Gene Heskett wrote:
At this point, I'd call it a buster delaying bug. That last is going to
cost too many that can't ignore it and don't have unencrypted backups.
Thats going to be a lot of very bad PR.
It's the release teams call, generally speaking,
On 2019-06-30, Andrea Borgia wrote:
> Il 30/06/19 11:52, Curt ha scritto:
>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928956
>>
>> Due to #765854 ecryptfs-utils has been removed from Buster.
>> The kernel module (ecryptfs.ko) is still built but depending on the
>> upgrade path us
Tixy wrote:
> Or if you have (or can make) a new disk partition, use dm-crypt to
> encrypt that and put the file system on that that people want encrypted
> (for /home?).
>
> Personally, for several releases I've used dm-crypt with LUKS for a
> partiton containing everything apart from /boot. (Do
On Sun, 2019-06-30 at 18:17 +0200, Sven Hartge wrote:
> Andrea Borgia wrote:
> > Il 30/06/19 11:52, Curt ha scritto:
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928956
> > >
> > > Due to #765854 ecryptfs-utils has been removed from Buster.
> > > The kernel module (ecryptfs.ko) is
Il 30/06/19 18:17, Sven Hartge ha scritto:
Other than that: Reinstalling the system with full disk encryption or
just copying the files from the ecryptfs and then removing it are the
only real other options.
I'll explore f.d.e. for the laptop, I guess the desktop can live just
fine with a pl
On Sunday 30 June 2019 12:17:48 Sven Hartge wrote:
> Andrea Borgia wrote:
> > Il 30/06/19 11:52, Curt ha scritto:
> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928956
> >>
> >> Due to #765854 ecryptfs-utils has been removed from Buster.
> >> The kernel module (ecryptfs.ko) is still b
Andrea Borgia wrote:
> Il 30/06/19 11:52, Curt ha scritto:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928956
>>
>> Due to #765854 ecryptfs-utils has been removed from Buster.
>> The kernel module (ecryptfs.ko) is still built but depending on the
>> upgrade path users will be unab
Il 30/06/19 11:52, Curt ha scritto:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928956
Due to #765854 ecryptfs-utils has been removed from Buster.
The kernel module (ecryptfs.ko) is still built but depending on the
upgrade path users will be unable to mount their encrypted home
di
I was preparing an upgrade to Buster until I saw this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928956
Due to #765854 ecryptfs-utils has been removed from Buster.
The kernel module (ecryptfs.ko) is still built but depending on the
upgrade path users will be unable to mount their encr
35 matches
Mail list logo
