[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Document removal of ecryptfs-utils from Buster



On 2019-06-30, Andrea Borgia <andrea@borgia.bo.it> 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 unable to mount their encrypted home
>>   directories (pam module, ecryptfs-mount-private missing).
>>   So they should probably be strongly advised to not upgrade.
>
> Should I count myself lucky that I have two systems running "testing" 
> with also "stable" sources? Perhaps it's time to mark the package as 
> "hold" :)
>
> I'd be interested to know if there is an alternative: not so much for my 
> desktop but my laptop really needs it. Thanks for the heads up, though.

I haven't yet investigated the alternatives. 

I guess I will be rolling back the encryption and purging the
incriminated software. I have nagging doubts about my encrypted swap and
whether I need to roll that back, too. I guess I will.

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)
permitted users upgrading from Wheezy to Stretch (where the old-style
names were deprecated) to continue using their obsolete, legacy
interface names (eth0, anyone?).  

Me, I migrated to the new-fangled denominations as per the instructions
at the link below to obviate the eventual loss of network connectivity,
which is a bummer when you don't what you're doing and all the help
available is at the other end of the severed wire.

https://www.debian.org/releases///buster/s390x/release-notes/ch-information.en.html#migrate-interface-names

The Wanderer and other recalcitrants allergic to progress (just kidding)
can still resort to the 'net.ifname=0 kernel' command line option for
relief.

> Regards,
> Andrea.
>
>



Reply to: