[Touch-packages] [Bug 1447282] Re: Does not use encrypted swap when using GPT partitioning + encrypted home directory (ecryptfs)

2015-05-23 Thread Launchpad Bug Tracker
Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: systemd (Ubuntu)
   Status: New = Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1447282

Title:
  Does not use encrypted swap when using GPT partitioning + encrypted
  home directory (ecryptfs)

Status in ecryptfs-utils:
  New
Status in ecryptfs-utils package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Confirmed
Status in ecryptfs-utils source package in Vivid:
  Fix Released
Status in systemd source package in Vivid:
  Confirmed

Bug description:
  I'm still sorting out the details and eliminating variables, but as
  far as I can tell:

  Steps to reproduce
  ===

  1) Install Ubuntu using GPT partitioning for the OS drive[*]

  2) Choose require my password to login, and check encrypt my home
  directory

  Expected behavior
  ===

  No special user interaction should be required to initialized the
  crytposwap other than normally logging in

  Actual behavior
  

  Prior to lightdm coming up, you will be prompted to enter your
  passphrase to unlock the cryptoswap, similar to how you would be
  prompted to unlock the OS drive when using full disk encryption (see
  attached photo).

  When lightdm comes up, you have to enter your password/passphrase
  again to login.

  Work-arounds
  ===

  1) This only seems to happen when using GTP partitioning, not MBR...
  so use MBR if you can

  2) Even with GTP partitioning, booting with init=/sbin/upstart seems
  to reliably fix the problem, so it certainly seems systemd related

  Notes
  =

  * As far as I can tell, there isn't a way to force Ubiquity to create
  a GPT partition table when the OS drive is  2TB, but it will
  automatically use GPT partitioning when the OS drive is = 2TB. My
  particular test was done using the System76 imaging server, which by
  default uses GPT partitioning even when the OS drive is  2TB.

  
  SRU INFORMATION
  
  Regression potential:
  This is delicate as we need to fix existing installations with a post-install 
script. This needs to happen as defensively as possible, but errors in this can 
still potentially completely break your partition information. Apart from 
testing that in the above scenario the unencrypted swap partition is marked as 
no-auto and thus after a new boot you are actually using the cryptswap1 one, 
we also need to verify that it does not destroy working systems.

  Test case:
  (1) Install an EFI system with encrypt my home directory (You can do this 
in QEMU with -bios OVMF.fd); after booting the first time you will be asked to 
enter a passprase for the swap partition, just press enter. sudo swapon -s 
will say something like /dev/sda3, i. e. using unencrypted swap. After 
installing this update and rebooting, the bogus passphrase prompt on boot 
should be gone, and sudo swapon -s should say /dev/dm-0, i. e. using 
encrypted swap.

  In all these other cases the update should not do anything and booting 
continues to work:
  (2) In the above system, sudo apt-get install --reinstall ecryptfs-utils 
should not change partitions again, but say something like is already marked 
as no-auto.
  (3) Install an EFI system without home dir encryption
  (4) Install an MBR system with home dir encryption
  (5) Install an MBR system without home dir encryption

  
  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: systemd 219-7ubuntu3
  ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3
  Uname: Linux 3.19.0-15-generic x86_64
  ApportVersion: 2.17.2-0ubuntu1
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Wed Apr 22 11:40:29 2015
  EcryptfsInUse: Yes
  MachineType: System76, Inc. Kudu Professional
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-15-generic 
root=UUID=e6c5aea5-d57c-410d-abce-66e96175e946 ro quiet splash vt.handoff=7
  SourcePackage: systemd
  UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 01/15/2014
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 1.03.03RS76
  dmi.board.asset.tag: Tag 12345
  dmi.board.name: Kudu Professional
  dmi.board.vendor: System76, Inc.
  dmi.board.version: kudp1
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 9
  dmi.chassis.vendor: System76, Inc.
  dmi.chassis.version: kudp1
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr1.03.03RS76:bd01/15/2014:svnSystem76,Inc.:pnKuduProfessional:pvrkudp1:rvnSystem76,Inc.:rnKuduProfessional:rvrkudp1:cvnSystem76,Inc.:ct9:cvrkudp1:
  dmi.product.name: Kudu Professional
  dmi.product.version: kudp1
  dmi.sys.vendor: System76, Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ecryptfs-utils/+bug/1447282/+subscriptions

-- 
Mailing list: 

[Touch-packages] [Bug 1447282] Re: Does not use encrypted swap when using GPT partitioning + encrypted home directory (ecryptfs)

2015-05-23 Thread Launchpad Bug Tracker
Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: systemd (Ubuntu Vivid)
   Status: New = Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1447282

Title:
  Does not use encrypted swap when using GPT partitioning + encrypted
  home directory (ecryptfs)

Status in ecryptfs-utils:
  New
Status in ecryptfs-utils package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Confirmed
Status in ecryptfs-utils source package in Vivid:
  Fix Released
Status in systemd source package in Vivid:
  Confirmed

Bug description:
  I'm still sorting out the details and eliminating variables, but as
  far as I can tell:

  Steps to reproduce
  ===

  1) Install Ubuntu using GPT partitioning for the OS drive[*]

  2) Choose require my password to login, and check encrypt my home
  directory

  Expected behavior
  ===

  No special user interaction should be required to initialized the
  crytposwap other than normally logging in

  Actual behavior
  

  Prior to lightdm coming up, you will be prompted to enter your
  passphrase to unlock the cryptoswap, similar to how you would be
  prompted to unlock the OS drive when using full disk encryption (see
  attached photo).

  When lightdm comes up, you have to enter your password/passphrase
  again to login.

  Work-arounds
  ===

  1) This only seems to happen when using GTP partitioning, not MBR...
  so use MBR if you can

  2) Even with GTP partitioning, booting with init=/sbin/upstart seems
  to reliably fix the problem, so it certainly seems systemd related

  Notes
  =

  * As far as I can tell, there isn't a way to force Ubiquity to create
  a GPT partition table when the OS drive is  2TB, but it will
  automatically use GPT partitioning when the OS drive is = 2TB. My
  particular test was done using the System76 imaging server, which by
  default uses GPT partitioning even when the OS drive is  2TB.

  
  SRU INFORMATION
  
  Regression potential:
  This is delicate as we need to fix existing installations with a post-install 
script. This needs to happen as defensively as possible, but errors in this can 
still potentially completely break your partition information. Apart from 
testing that in the above scenario the unencrypted swap partition is marked as 
no-auto and thus after a new boot you are actually using the cryptswap1 one, 
we also need to verify that it does not destroy working systems.

  Test case:
  (1) Install an EFI system with encrypt my home directory (You can do this 
in QEMU with -bios OVMF.fd); after booting the first time you will be asked to 
enter a passprase for the swap partition, just press enter. sudo swapon -s 
will say something like /dev/sda3, i. e. using unencrypted swap. After 
installing this update and rebooting, the bogus passphrase prompt on boot 
should be gone, and sudo swapon -s should say /dev/dm-0, i. e. using 
encrypted swap.

  In all these other cases the update should not do anything and booting 
continues to work:
  (2) In the above system, sudo apt-get install --reinstall ecryptfs-utils 
should not change partitions again, but say something like is already marked 
as no-auto.
  (3) Install an EFI system without home dir encryption
  (4) Install an MBR system with home dir encryption
  (5) Install an MBR system without home dir encryption

  
  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: systemd 219-7ubuntu3
  ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3
  Uname: Linux 3.19.0-15-generic x86_64
  ApportVersion: 2.17.2-0ubuntu1
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Wed Apr 22 11:40:29 2015
  EcryptfsInUse: Yes
  MachineType: System76, Inc. Kudu Professional
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-15-generic 
root=UUID=e6c5aea5-d57c-410d-abce-66e96175e946 ro quiet splash vt.handoff=7
  SourcePackage: systemd
  UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 01/15/2014
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 1.03.03RS76
  dmi.board.asset.tag: Tag 12345
  dmi.board.name: Kudu Professional
  dmi.board.vendor: System76, Inc.
  dmi.board.version: kudp1
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 9
  dmi.chassis.vendor: System76, Inc.
  dmi.chassis.version: kudp1
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr1.03.03RS76:bd01/15/2014:svnSystem76,Inc.:pnKuduProfessional:pvrkudp1:rvnSystem76,Inc.:rnKuduProfessional:rvrkudp1:cvnSystem76,Inc.:ct9:cvrkudp1:
  dmi.product.name: Kudu Professional
  dmi.product.version: kudp1
  dmi.sys.vendor: System76, Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ecryptfs-utils/+bug/1447282/+subscriptions

-- 
Mailing list: 

[Touch-packages] [Bug 1447282] Re: Does not use encrypted swap when using GPT partitioning + encrypted home directory (ecryptfs)

2015-05-23 Thread Martin Pitt
** No longer affects: systemd (Ubuntu Vivid)

** No longer affects: systemd (Ubuntu)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1447282

Title:
  Does not use encrypted swap when using GPT partitioning + encrypted
  home directory (ecryptfs)

Status in ecryptfs-utils:
  New
Status in ecryptfs-utils package in Ubuntu:
  Fix Released
Status in ecryptfs-utils source package in Vivid:
  Fix Released

Bug description:
  I'm still sorting out the details and eliminating variables, but as
  far as I can tell:

  Steps to reproduce
  ===

  1) Install Ubuntu using GPT partitioning for the OS drive[*]

  2) Choose require my password to login, and check encrypt my home
  directory

  Expected behavior
  ===

  No special user interaction should be required to initialized the
  crytposwap other than normally logging in

  Actual behavior
  

  Prior to lightdm coming up, you will be prompted to enter your
  passphrase to unlock the cryptoswap, similar to how you would be
  prompted to unlock the OS drive when using full disk encryption (see
  attached photo).

  When lightdm comes up, you have to enter your password/passphrase
  again to login.

  Work-arounds
  ===

  1) This only seems to happen when using GTP partitioning, not MBR...
  so use MBR if you can

  2) Even with GTP partitioning, booting with init=/sbin/upstart seems
  to reliably fix the problem, so it certainly seems systemd related

  Notes
  =

  * As far as I can tell, there isn't a way to force Ubiquity to create
  a GPT partition table when the OS drive is  2TB, but it will
  automatically use GPT partitioning when the OS drive is = 2TB. My
  particular test was done using the System76 imaging server, which by
  default uses GPT partitioning even when the OS drive is  2TB.

  
  SRU INFORMATION
  
  Regression potential:
  This is delicate as we need to fix existing installations with a post-install 
script. This needs to happen as defensively as possible, but errors in this can 
still potentially completely break your partition information. Apart from 
testing that in the above scenario the unencrypted swap partition is marked as 
no-auto and thus after a new boot you are actually using the cryptswap1 one, 
we also need to verify that it does not destroy working systems.

  Test case:
  (1) Install an EFI system with encrypt my home directory (You can do this 
in QEMU with -bios OVMF.fd); after booting the first time you will be asked to 
enter a passprase for the swap partition, just press enter. sudo swapon -s 
will say something like /dev/sda3, i. e. using unencrypted swap. After 
installing this update and rebooting, the bogus passphrase prompt on boot 
should be gone, and sudo swapon -s should say /dev/dm-0, i. e. using 
encrypted swap.

  In all these other cases the update should not do anything and booting 
continues to work:
  (2) In the above system, sudo apt-get install --reinstall ecryptfs-utils 
should not change partitions again, but say something like is already marked 
as no-auto.
  (3) Install an EFI system without home dir encryption
  (4) Install an MBR system with home dir encryption
  (5) Install an MBR system without home dir encryption

  
  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: systemd 219-7ubuntu3
  ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3
  Uname: Linux 3.19.0-15-generic x86_64
  ApportVersion: 2.17.2-0ubuntu1
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Wed Apr 22 11:40:29 2015
  EcryptfsInUse: Yes
  MachineType: System76, Inc. Kudu Professional
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-15-generic 
root=UUID=e6c5aea5-d57c-410d-abce-66e96175e946 ro quiet splash vt.handoff=7
  SourcePackage: systemd
  UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 01/15/2014
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 1.03.03RS76
  dmi.board.asset.tag: Tag 12345
  dmi.board.name: Kudu Professional
  dmi.board.vendor: System76, Inc.
  dmi.board.version: kudp1
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 9
  dmi.chassis.vendor: System76, Inc.
  dmi.chassis.version: kudp1
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr1.03.03RS76:bd01/15/2014:svnSystem76,Inc.:pnKuduProfessional:pvrkudp1:rvnSystem76,Inc.:rnKuduProfessional:rvrkudp1:cvnSystem76,Inc.:ct9:cvrkudp1:
  dmi.product.name: Kudu Professional
  dmi.product.version: kudp1
  dmi.sys.vendor: System76, Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ecryptfs-utils/+bug/1447282/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : 

[Touch-packages] [Bug 1447282] Re: Does not use encrypted swap when using GPT partitioning + encrypted home directory (ecryptfs)

2015-05-22 Thread David Bonner
** Also affects: systemd (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1447282

Title:
  Does not use encrypted swap when using GPT partitioning + encrypted
  home directory (ecryptfs)

Status in ecryptfs-utils:
  New
Status in ecryptfs-utils package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  New
Status in ecryptfs-utils source package in Vivid:
  Fix Released
Status in systemd source package in Vivid:
  New

Bug description:
  I'm still sorting out the details and eliminating variables, but as
  far as I can tell:

  Steps to reproduce
  ===

  1) Install Ubuntu using GPT partitioning for the OS drive[*]

  2) Choose require my password to login, and check encrypt my home
  directory

  Expected behavior
  ===

  No special user interaction should be required to initialized the
  crytposwap other than normally logging in

  Actual behavior
  

  Prior to lightdm coming up, you will be prompted to enter your
  passphrase to unlock the cryptoswap, similar to how you would be
  prompted to unlock the OS drive when using full disk encryption (see
  attached photo).

  When lightdm comes up, you have to enter your password/passphrase
  again to login.

  Work-arounds
  ===

  1) This only seems to happen when using GTP partitioning, not MBR...
  so use MBR if you can

  2) Even with GTP partitioning, booting with init=/sbin/upstart seems
  to reliably fix the problem, so it certainly seems systemd related

  Notes
  =

  * As far as I can tell, there isn't a way to force Ubiquity to create
  a GPT partition table when the OS drive is  2TB, but it will
  automatically use GPT partitioning when the OS drive is = 2TB. My
  particular test was done using the System76 imaging server, which by
  default uses GPT partitioning even when the OS drive is  2TB.

  
  SRU INFORMATION
  
  Regression potential:
  This is delicate as we need to fix existing installations with a post-install 
script. This needs to happen as defensively as possible, but errors in this can 
still potentially completely break your partition information. Apart from 
testing that in the above scenario the unencrypted swap partition is marked as 
no-auto and thus after a new boot you are actually using the cryptswap1 one, 
we also need to verify that it does not destroy working systems.

  Test case:
  (1) Install an EFI system with encrypt my home directory (You can do this 
in QEMU with -bios OVMF.fd); after booting the first time you will be asked to 
enter a passprase for the swap partition, just press enter. sudo swapon -s 
will say something like /dev/sda3, i. e. using unencrypted swap. After 
installing this update and rebooting, the bogus passphrase prompt on boot 
should be gone, and sudo swapon -s should say /dev/dm-0, i. e. using 
encrypted swap.

  In all these other cases the update should not do anything and booting 
continues to work:
  (2) In the above system, sudo apt-get install --reinstall ecryptfs-utils 
should not change partitions again, but say something like is already marked 
as no-auto.
  (3) Install an EFI system without home dir encryption
  (4) Install an MBR system with home dir encryption
  (5) Install an MBR system without home dir encryption

  
  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: systemd 219-7ubuntu3
  ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3
  Uname: Linux 3.19.0-15-generic x86_64
  ApportVersion: 2.17.2-0ubuntu1
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Wed Apr 22 11:40:29 2015
  EcryptfsInUse: Yes
  MachineType: System76, Inc. Kudu Professional
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-15-generic 
root=UUID=e6c5aea5-d57c-410d-abce-66e96175e946 ro quiet splash vt.handoff=7
  SourcePackage: systemd
  UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 01/15/2014
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 1.03.03RS76
  dmi.board.asset.tag: Tag 12345
  dmi.board.name: Kudu Professional
  dmi.board.vendor: System76, Inc.
  dmi.board.version: kudp1
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 9
  dmi.chassis.vendor: System76, Inc.
  dmi.chassis.version: kudp1
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr1.03.03RS76:bd01/15/2014:svnSystem76,Inc.:pnKuduProfessional:pvrkudp1:rvnSystem76,Inc.:rnKuduProfessional:rvrkudp1:cvnSystem76,Inc.:ct9:cvrkudp1:
  dmi.product.name: Kudu Professional
  dmi.product.version: kudp1
  dmi.sys.vendor: System76, Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ecryptfs-utils/+bug/1447282/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : 

[Touch-packages] [Bug 1447282] Re: Does not use encrypted swap when using GPT partitioning + encrypted home directory (ecryptfs)

2015-04-24 Thread Martin Pitt
Two ideas how to fix that:

 * ecryptfs-setup-swap should change the partition type UUID to not be swap 
any more so that we don't try and auto-activate it. This is my preferred 
solution if it works.
 * ecryptfs-setup-swap creates an override .swap unit which disables the 
auto-mounting. But as we would again have to refer to real device names, we 
lose the entire point of keeping the underlying unencrypted swap partition, i. 
e. so that we can refer to it by UUID.

** Package changed: systemd (Ubuntu Vivid) = ecryptfs-utils (Ubuntu
Vivid)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1447282

Title:
  Does not use encrypted swap when using GPT partitioning + encrypted
  home directory (ecryptfs)

Status in ecryptfs-utils package in Ubuntu:
  In Progress
Status in ecryptfs-utils source package in Vivid:
  In Progress

Bug description:
  I'm still sorting out the details and eliminating variables, but as
  far as I can tell:

  Steps to reproduce
  ===

  1) Install Ubuntu using GPT partitioning for the OS drive[*]

  2) Choose require my password to login, and check encrypt my home
  directory

  Expected behavior
  ===

  No special user interaction should be required to initialized the
  crytposwap other than normally logging in

  Actual behavior
  

  Prior to lightdm coming up, you will be prompted to enter your
  passphrase to unlock the cryptoswap, similar to how you would be
  prompted to unlock the OS drive when using full disk encryption (see
  attached photo).

  When lightdm comes up, you have to enter your password/passphrase
  again to login.

  Work-arounds
  ===

  1) This only seems to happen when using GTP partitioning, not MBR...
  so use MBR if you can

  2) Even with GTP partitioning, booting with init=/sbin/upstart seems
  to reliably fix the problem, so it certainly seems systemd related

  Notes
  =

  * As far as I can tell, there isn't a way to force Ubiquity to create
  a GPT partition table when the OS drive is  2TB, but it will
  automatically use GPT partitioning when the OS drive is = 2TB. My
  particular test was done using the System76 imaging server, which by
  default uses GPT partitioning even when the OS drive is  2TB.

  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: systemd 219-7ubuntu3
  ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3
  Uname: Linux 3.19.0-15-generic x86_64
  ApportVersion: 2.17.2-0ubuntu1
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Wed Apr 22 11:40:29 2015
  EcryptfsInUse: Yes
  MachineType: System76, Inc. Kudu Professional
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-15-generic 
root=UUID=e6c5aea5-d57c-410d-abce-66e96175e946 ro quiet splash vt.handoff=7
  SourcePackage: systemd
  UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 01/15/2014
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 1.03.03RS76
  dmi.board.asset.tag: Tag 12345
  dmi.board.name: Kudu Professional
  dmi.board.vendor: System76, Inc.
  dmi.board.version: kudp1
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 9
  dmi.chassis.vendor: System76, Inc.
  dmi.chassis.version: kudp1
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr1.03.03RS76:bd01/15/2014:svnSystem76,Inc.:pnKuduProfessional:pvrkudp1:rvnSystem76,Inc.:rnKuduProfessional:rvrkudp1:cvnSystem76,Inc.:ct9:cvrkudp1:
  dmi.product.name: Kudu Professional
  dmi.product.version: kudp1
  dmi.sys.vendor: System76, Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1447282/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1447282] Re: Does not use encrypted swap when using GPT partitioning + encrypted home directory (ecryptfs)

2015-04-24 Thread Martin Pitt
So it is as I suspected:

 * ecryptfs-setup-swap creates cryptswap1 at 512KiB offset of the former real 
swap partition (vda3), and adds that to /etc/crypttab; as we need/want the 
UUID, we keep the original swap header
 * During boot, systemd-gpt-generator sees the apparent unencrypted swap 
partition on vda3 and creates a .swap unit for this. This doesn't happen on 
classic MBR partitions, as there are no partition type UUIDs and no 
auto-discovery
 * The real encrypted swap partition (cryptswap1) gets enabled later, and 
that fails with busy as the unencrypted partition is already active.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1447282

Title:
  Does not use encrypted swap when using GPT partitioning + encrypted
  home directory (ecryptfs)

Status in ecryptfs-utils package in Ubuntu:
  In Progress
Status in ecryptfs-utils source package in Vivid:
  In Progress

Bug description:
  I'm still sorting out the details and eliminating variables, but as
  far as I can tell:

  Steps to reproduce
  ===

  1) Install Ubuntu using GPT partitioning for the OS drive[*]

  2) Choose require my password to login, and check encrypt my home
  directory

  Expected behavior
  ===

  No special user interaction should be required to initialized the
  crytposwap other than normally logging in

  Actual behavior
  

  Prior to lightdm coming up, you will be prompted to enter your
  passphrase to unlock the cryptoswap, similar to how you would be
  prompted to unlock the OS drive when using full disk encryption (see
  attached photo).

  When lightdm comes up, you have to enter your password/passphrase
  again to login.

  Work-arounds
  ===

  1) This only seems to happen when using GTP partitioning, not MBR...
  so use MBR if you can

  2) Even with GTP partitioning, booting with init=/sbin/upstart seems
  to reliably fix the problem, so it certainly seems systemd related

  Notes
  =

  * As far as I can tell, there isn't a way to force Ubiquity to create
  a GPT partition table when the OS drive is  2TB, but it will
  automatically use GPT partitioning when the OS drive is = 2TB. My
  particular test was done using the System76 imaging server, which by
  default uses GPT partitioning even when the OS drive is  2TB.

  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: systemd 219-7ubuntu3
  ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3
  Uname: Linux 3.19.0-15-generic x86_64
  ApportVersion: 2.17.2-0ubuntu1
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Wed Apr 22 11:40:29 2015
  EcryptfsInUse: Yes
  MachineType: System76, Inc. Kudu Professional
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-15-generic 
root=UUID=e6c5aea5-d57c-410d-abce-66e96175e946 ro quiet splash vt.handoff=7
  SourcePackage: systemd
  UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 01/15/2014
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 1.03.03RS76
  dmi.board.asset.tag: Tag 12345
  dmi.board.name: Kudu Professional
  dmi.board.vendor: System76, Inc.
  dmi.board.version: kudp1
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 9
  dmi.chassis.vendor: System76, Inc.
  dmi.chassis.version: kudp1
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr1.03.03RS76:bd01/15/2014:svnSystem76,Inc.:pnKuduProfessional:pvrkudp1:rvnSystem76,Inc.:rnKuduProfessional:rvrkudp1:cvnSystem76,Inc.:ct9:cvrkudp1:
  dmi.product.name: Kudu Professional
  dmi.product.version: kudp1
  dmi.sys.vendor: System76, Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1447282/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp