[Touch-packages] [Bug 1354306]
This has been implemented a while back, see 405e116f57b1cf33d4ca0294ab045a9f709bbc96 -- 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/1354306 Title: gpio shutdown trigger for ProLiant m400 cartridges Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Trusty: Fix Released Status in systemd source package in Utopic: Fix Released Bug description: Similar to the m800 case in LP: #1347776, udev/systemd also needs to know how to trigger a graceful shutdown on ProLiant m400 cartridges. [Impact] Without this change, the power down button will not initiate an OS shutdown on this platform. [Test Case] Push button. Watch poweroff occur. [Regression Potential] The new rule is pretty tightly bound to the m400 system - so the risk of this rule matching and impacting behavior on a different platform is minimal. This will presumably cause new code to run and read /proc/device-tree/model on other platforms - but this is already done for the m800 system in both utopic and trusty. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1354306/+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 1347776]
This has been implemented a while back, see
405e116f57b1cf33d4ca0294ab045a9f709bbc96
--
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/1347776
Title:
shutdown trigger on gpio_keys.X for armhf hardware
Status in systemd:
Fix Released
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Trusty:
Fix Released
Status in systemd source package in Utopic:
Fix Released
Bug description:
Some ARM board uses GPIO gpio_key.12 for power control (key=116). The
proposed patch adds entry to logind's 70-power-switch.rules to
initiate soft shutdown of the cartridge from ilo.
Here is the udevadm output for /dev/input/event0
sudo udevadm info --query=all --name=/dev/input/event0 --attribute-
walk
Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/soc.3/gpio_keys.12/input/input0/event0':
KERNEL=="event0"
SUBSYSTEM=="input"
DRIVER==""
looking at parent device '/devices/soc.3/gpio_keys.12/input/input0':
KERNELS=="input0"
SUBSYSTEMS=="input"
DRIVERS==""
ATTRS{name}=="gpio_keys.12"
ATTRS{phys}=="gpio-keys/input0"
ATTRS{uniq}==""
ATTRS{properties}=="0"
looking at parent device '/devices/soc.3/gpio_keys.12':
KERNELS=="gpio_keys.12"
SUBSYSTEMS=="platform"
DRIVERS=="gpio-keys"
ATTRS{keys}=="116"
ATTRS{switches}==""
ATTRS{disabled_keys}==""
ATTRS{disabled_switches}==""
looking at parent device '/devices/soc.3':
KERNELS=="soc.3"
SUBSYSTEMS=="platform"
DRIVERS==""
Regarding the possibility of gpio_key.12 being used by other systems
to map to some other trigger, I put in the check that the gpio_key.12
is associated with power control (keys=116). '116' is supposedly linux
generic power control in DTS. There is no uniq idSystem or idVendor
for device /dev/input/event0 as you can see from udevadm output,
therefore I tried to use the best available combination as a safety
check. This patch will enable power control for any system vendor
(Other than the one the patch in intended for) that describes in DTS,
the trigger gpio_key.12 as power control (116).
SRU Request
==
[Impact]
* User won't be able to initiate a soft shutdown from the chassis
manager.
[Test Case]
* To reproduce this bug, initiate a soft shutdown from the chassis manager,
for example from ilo you could do
set node power off shutdown
[Test Result]
== BEFORE PATCH ==
$ cat /lib/udev/rules.d/70-power-switch.rules
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
ACTION=="remove", GOTO="power_switch_end"
SUBSYSTEM=="input", KERNEL=="event*", SUBSYSTEMS=="acpi", TAG+="power-switch"
SUBSYSTEM=="input", KERNEL=="event*", KERNELS=="thinkpad_acpi",
TAG+="power-switch"
LABEL="power_switch_end"
$
hpiLO-> set node power off shutdown c3n2
c3: #Cartridge 3
c3n2: #Node 2 Shutting node down gracefully
hpiLO-> show node list
Slot ID Proc Manufacturer Architecture Memory Power Health
- -- -- - --
3 c3n1 ARM Architecture 8 GB On OK
3 c3n2 ARM Architecture 8 GB On OK
3 c3n3 ARM Architecture 8 GB On OK
3 c3n4 ARM Architecture 8 GB Off OK
hpiLO->
== AFTER PATCH ==
hpiLO-> set node power off shutdown c3n1
c3: #Cartridge 3
c3n1: #Node 1 Shutting node down gracefully
hpiLO-> show node list
Slot ID Proc Manufacturer Architecture Memory Power Health
- -- -- - --
3 c3n1 ARM Architecture 8 GB Off OK
3 c3n2 ARM Architecture 8 GB On OK
3 c3n3 ARM Architecture 8 GB On OK
3 c3n4 ARM Architecture 8 GB Off OK
hpiLO->
[Regression Potential]
None.
Note: Regarding the possibility of gpio_key.12 being used by other systems to
map to some other trigger, I put in the check that the gpio_key.12 is
associated with power control (keys=116). '116' is supposedly linux generic
power control in DTS.
To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1347776/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.
[Touch-packages] [Bug 953875]
OK, if this is not a bytes value, parse_size() is probably not a good
idea. (that said, I think it's a pretty poor choice to expose this as
512byte block value...)
Anyway, looks good. Please push!
--
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/953875
Title:
Encrypted swap no longer mounted at bootup
Status in eCryptfs:
Fix Released
Status in systemd:
Fix Released
Status in ecryptfs-utils package in Ubuntu:
Fix Released
Status in systemd package in Ubuntu:
Fix Released
Status in ubiquity package in Ubuntu:
Fix Released
Status in ecryptfs-utils source package in Vivid:
Fix Released
Status in systemd source package in Vivid:
Fix Released
Status in ubiquity source package in Vivid:
Fix Released
Status in systemd package in Debian:
Fix Released
Bug description:
SUMMARY
===
During installation with "encrypt my home folder" mode, a broken
/etc/crypttab gets created which defines a non-existing swap device (usually
"cryptswap1") with a UUID. This will also be put into /etc/fstab. As after
installation the UUID does not exist, such systems don't have any actual swap.
UPGRADE FIX
===
An upgrade to Ubuntu 15.04 ("vivid") will detect and comment out these broken
swap devices from /etc/fstab and /etc/crypttab. If you actually want to use
those, do these steps:
- Find the swap device that was meant to be used in "sudo fdisk -l" (it
should say "Linux swap" in the last column), remember the device name
(something like "/dev/sda5")
- Find the UUID in /etc/crypttab (the long alphanumeric ID after UUID=)
- Run "sudo mkswap -U 1234... /dev/sda5", replacing "1234" with the above
UUID, and /dev/sda5 with the device name from step 1.
- Edit /etc/crypttab to append ",offset=1024" in the fourth (last) column of
the cryptswap1 line; ensure that there is *no space* between the
"cipher=aes-cbc-essiv:sha256" and the appended option. If there is a leading
"#" in the file, remove that too.
- If there is a leading "#" in /etc/fstab in the line starting with
/dev/mapper/cryptswap1 line, remove that.
- Run "sudo update-initramfs -u".
ORIGINAL REPORT
===
Clean install of 12.04 and with encrypted home for my user. Did all
updates and now the bootup hangs waiting for swap to become available
and it never seems to ever finish. The 200GB SSD below is my boot
drive and root filesystem.
alan@mesh:~$ sudo swapon -a
[sudo] password for alan:
swapon: /dev/mapper/cryptswap1: stat failed: No such file or directory
alan@mesh:~$ grep swap /etc/fstab
# swap was on /dev/sdg5 during installation
#UUID=22d3f7f0-f715-4582-81ba-dcbd4cdd1495 noneswapsw
0 0
/dev/mapper/cryptswap1 none swap sw 0 0
alan@mesh:~$ sudo fdisk -l
Disk /dev/sda: 115.0 GB, 115033153536 bytes
255 heads, 63 sectors/track, 13985 cylinders, total 224674128 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000ba2ed
Device Boot Start End Blocks Id System
/dev/sda1 *2048 206847 1024007 HPFS/NTFS/exFAT
/dev/sda2 206848 224671743 1122324487 HPFS/NTFS/exFAT
Disk /dev/sdb: 200.0 GB, 200049647616 bytes
255 heads, 63 sectors/track, 24321 cylinders, total 390721968 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xf0fa0806
Device Boot Start End Blocks Id System
/dev/sdb12048 349304831 1746513927 HPFS/NTFS/exFAT
/dev/sdb2 374722558 390721535 79994895 Extended
/dev/sdb3 * 349304832 37472051112707840 83 Linux
/dev/sdb5 374722560 390721535 7999488 82 Linux swap / Solaris
Partition table entries are not in disk order
ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: libecryptfs0 96-0ubuntu2
ProcVersionSignature: Ubuntu 3.2.0-18.29-generic 3.2.9
Uname: Linux 3.2.0-18-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 1.94.1-0ubuntu2
Architecture: amd64
Date: Tue Mar 13 09:56:56 2012
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64
(20120215)
ProcEnviron:
LANGUAGE=en_GB:en
TERM=xterm
LANG=en_GB.UTF-8
SHELL=/bin/bash
SourcePackage: ecryptfs-utils
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ecryptfs/+bug/953875/+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
[Touch-packages] [Bug 953875]
Also, please add the initialization of .offset and .skip into the
declaration of the params variable, as initializer. i.e.:
struct crypt_params_plain params = {
.offset = arg_offset,
.skip = arg_skip,
};
Also, please document the new switches in crypttab(5).
--
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/953875
Title:
Encrypted swap no longer mounted at bootup
Status in eCryptfs:
Fix Released
Status in systemd:
Fix Released
Status in ecryptfs-utils package in Ubuntu:
Fix Released
Status in systemd package in Ubuntu:
Fix Released
Status in ubiquity package in Ubuntu:
Fix Released
Status in ecryptfs-utils source package in Vivid:
Fix Released
Status in systemd source package in Vivid:
Fix Released
Status in ubiquity source package in Vivid:
Fix Released
Status in systemd package in Debian:
Fix Released
Bug description:
SUMMARY
===
During installation with "encrypt my home folder" mode, a broken
/etc/crypttab gets created which defines a non-existing swap device (usually
"cryptswap1") with a UUID. This will also be put into /etc/fstab. As after
installation the UUID does not exist, such systems don't have any actual swap.
UPGRADE FIX
===
An upgrade to Ubuntu 15.04 ("vivid") will detect and comment out these broken
swap devices from /etc/fstab and /etc/crypttab. If you actually want to use
those, do these steps:
- Find the swap device that was meant to be used in "sudo fdisk -l" (it
should say "Linux swap" in the last column), remember the device name
(something like "/dev/sda5")
- Find the UUID in /etc/crypttab (the long alphanumeric ID after UUID=)
- Run "sudo mkswap -U 1234... /dev/sda5", replacing "1234" with the above
UUID, and /dev/sda5 with the device name from step 1.
- Edit /etc/crypttab to append ",offset=1024" in the fourth (last) column of
the cryptswap1 line; ensure that there is *no space* between the
"cipher=aes-cbc-essiv:sha256" and the appended option. If there is a leading
"#" in the file, remove that too.
- If there is a leading "#" in /etc/fstab in the line starting with
/dev/mapper/cryptswap1 line, remove that.
- Run "sudo update-initramfs -u".
ORIGINAL REPORT
===
Clean install of 12.04 and with encrypted home for my user. Did all
updates and now the bootup hangs waiting for swap to become available
and it never seems to ever finish. The 200GB SSD below is my boot
drive and root filesystem.
alan@mesh:~$ sudo swapon -a
[sudo] password for alan:
swapon: /dev/mapper/cryptswap1: stat failed: No such file or directory
alan@mesh:~$ grep swap /etc/fstab
# swap was on /dev/sdg5 during installation
#UUID=22d3f7f0-f715-4582-81ba-dcbd4cdd1495 noneswapsw
0 0
/dev/mapper/cryptswap1 none swap sw 0 0
alan@mesh:~$ sudo fdisk -l
Disk /dev/sda: 115.0 GB, 115033153536 bytes
255 heads, 63 sectors/track, 13985 cylinders, total 224674128 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000ba2ed
Device Boot Start End Blocks Id System
/dev/sda1 *2048 206847 1024007 HPFS/NTFS/exFAT
/dev/sda2 206848 224671743 1122324487 HPFS/NTFS/exFAT
Disk /dev/sdb: 200.0 GB, 200049647616 bytes
255 heads, 63 sectors/track, 24321 cylinders, total 390721968 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xf0fa0806
Device Boot Start End Blocks Id System
/dev/sdb12048 349304831 1746513927 HPFS/NTFS/exFAT
/dev/sdb2 374722558 390721535 79994895 Extended
/dev/sdb3 * 349304832 37472051112707840 83 Linux
/dev/sdb5 374722560 390721535 7999488 82 Linux swap / Solaris
Partition table entries are not in disk order
ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: libecryptfs0 96-0ubuntu2
ProcVersionSignature: Ubuntu 3.2.0-18.29-generic 3.2.9
Uname: Linux 3.2.0-18-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 1.94.1-0ubuntu2
Architecture: amd64
Date: Tue Mar 13 09:56:56 2012
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64
(20120215)
ProcEnviron:
LANGUAGE=en_GB:en
TERM=xterm
LANG=en_GB.UTF-8
SHELL=/bin/bash
SourcePackage: ecryptfs-utils
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ecryptfs/+bug/953875/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
[Touch-packages] [Bug 953875]
(In reply to Lennart Poettering from comment #6)
> Hmm, please use parse_bytes() for parsing byte values.
Sorry, I meant parse_size() of course.
--
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/953875
Title:
Encrypted swap no longer mounted at bootup
Status in eCryptfs:
Fix Released
Status in systemd:
Fix Released
Status in ecryptfs-utils package in Ubuntu:
Fix Released
Status in systemd package in Ubuntu:
Fix Released
Status in ubiquity package in Ubuntu:
Fix Released
Status in ecryptfs-utils source package in Vivid:
Fix Released
Status in systemd source package in Vivid:
Fix Released
Status in ubiquity source package in Vivid:
Fix Released
Status in systemd package in Debian:
Fix Released
Bug description:
SUMMARY
===
During installation with "encrypt my home folder" mode, a broken
/etc/crypttab gets created which defines a non-existing swap device (usually
"cryptswap1") with a UUID. This will also be put into /etc/fstab. As after
installation the UUID does not exist, such systems don't have any actual swap.
UPGRADE FIX
===
An upgrade to Ubuntu 15.04 ("vivid") will detect and comment out these broken
swap devices from /etc/fstab and /etc/crypttab. If you actually want to use
those, do these steps:
- Find the swap device that was meant to be used in "sudo fdisk -l" (it
should say "Linux swap" in the last column), remember the device name
(something like "/dev/sda5")
- Find the UUID in /etc/crypttab (the long alphanumeric ID after UUID=)
- Run "sudo mkswap -U 1234... /dev/sda5", replacing "1234" with the above
UUID, and /dev/sda5 with the device name from step 1.
- Edit /etc/crypttab to append ",offset=1024" in the fourth (last) column of
the cryptswap1 line; ensure that there is *no space* between the
"cipher=aes-cbc-essiv:sha256" and the appended option. If there is a leading
"#" in the file, remove that too.
- If there is a leading "#" in /etc/fstab in the line starting with
/dev/mapper/cryptswap1 line, remove that.
- Run "sudo update-initramfs -u".
ORIGINAL REPORT
===
Clean install of 12.04 and with encrypted home for my user. Did all
updates and now the bootup hangs waiting for swap to become available
and it never seems to ever finish. The 200GB SSD below is my boot
drive and root filesystem.
alan@mesh:~$ sudo swapon -a
[sudo] password for alan:
swapon: /dev/mapper/cryptswap1: stat failed: No such file or directory
alan@mesh:~$ grep swap /etc/fstab
# swap was on /dev/sdg5 during installation
#UUID=22d3f7f0-f715-4582-81ba-dcbd4cdd1495 noneswapsw
0 0
/dev/mapper/cryptswap1 none swap sw 0 0
alan@mesh:~$ sudo fdisk -l
Disk /dev/sda: 115.0 GB, 115033153536 bytes
255 heads, 63 sectors/track, 13985 cylinders, total 224674128 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000ba2ed
Device Boot Start End Blocks Id System
/dev/sda1 *2048 206847 1024007 HPFS/NTFS/exFAT
/dev/sda2 206848 224671743 1122324487 HPFS/NTFS/exFAT
Disk /dev/sdb: 200.0 GB, 200049647616 bytes
255 heads, 63 sectors/track, 24321 cylinders, total 390721968 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xf0fa0806
Device Boot Start End Blocks Id System
/dev/sdb12048 349304831 1746513927 HPFS/NTFS/exFAT
/dev/sdb2 374722558 390721535 79994895 Extended
/dev/sdb3 * 349304832 37472051112707840 83 Linux
/dev/sdb5 374722560 390721535 7999488 82 Linux swap / Solaris
Partition table entries are not in disk order
ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: libecryptfs0 96-0ubuntu2
ProcVersionSignature: Ubuntu 3.2.0-18.29-generic 3.2.9
Uname: Linux 3.2.0-18-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 1.94.1-0ubuntu2
Architecture: amd64
Date: Tue Mar 13 09:56:56 2012
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64
(20120215)
ProcEnviron:
LANGUAGE=en_GB:en
TERM=xterm
LANG=en_GB.UTF-8
SHELL=/bin/bash
SourcePackage: ecryptfs-utils
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ecryptfs/+bug/953875/+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 953875]
Hmm, please use parse_bytes() for parsing byte values.
--
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/953875
Title:
Encrypted swap no longer mounted at bootup
Status in eCryptfs:
Fix Released
Status in systemd:
Fix Released
Status in ecryptfs-utils package in Ubuntu:
Fix Released
Status in systemd package in Ubuntu:
Fix Released
Status in ubiquity package in Ubuntu:
Fix Released
Status in ecryptfs-utils source package in Vivid:
Fix Released
Status in systemd source package in Vivid:
Fix Released
Status in ubiquity source package in Vivid:
Fix Released
Status in systemd package in Debian:
Fix Released
Bug description:
SUMMARY
===
During installation with "encrypt my home folder" mode, a broken
/etc/crypttab gets created which defines a non-existing swap device (usually
"cryptswap1") with a UUID. This will also be put into /etc/fstab. As after
installation the UUID does not exist, such systems don't have any actual swap.
UPGRADE FIX
===
An upgrade to Ubuntu 15.04 ("vivid") will detect and comment out these broken
swap devices from /etc/fstab and /etc/crypttab. If you actually want to use
those, do these steps:
- Find the swap device that was meant to be used in "sudo fdisk -l" (it
should say "Linux swap" in the last column), remember the device name
(something like "/dev/sda5")
- Find the UUID in /etc/crypttab (the long alphanumeric ID after UUID=)
- Run "sudo mkswap -U 1234... /dev/sda5", replacing "1234" with the above
UUID, and /dev/sda5 with the device name from step 1.
- Edit /etc/crypttab to append ",offset=1024" in the fourth (last) column of
the cryptswap1 line; ensure that there is *no space* between the
"cipher=aes-cbc-essiv:sha256" and the appended option. If there is a leading
"#" in the file, remove that too.
- If there is a leading "#" in /etc/fstab in the line starting with
/dev/mapper/cryptswap1 line, remove that.
- Run "sudo update-initramfs -u".
ORIGINAL REPORT
===
Clean install of 12.04 and with encrypted home for my user. Did all
updates and now the bootup hangs waiting for swap to become available
and it never seems to ever finish. The 200GB SSD below is my boot
drive and root filesystem.
alan@mesh:~$ sudo swapon -a
[sudo] password for alan:
swapon: /dev/mapper/cryptswap1: stat failed: No such file or directory
alan@mesh:~$ grep swap /etc/fstab
# swap was on /dev/sdg5 during installation
#UUID=22d3f7f0-f715-4582-81ba-dcbd4cdd1495 noneswapsw
0 0
/dev/mapper/cryptswap1 none swap sw 0 0
alan@mesh:~$ sudo fdisk -l
Disk /dev/sda: 115.0 GB, 115033153536 bytes
255 heads, 63 sectors/track, 13985 cylinders, total 224674128 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000ba2ed
Device Boot Start End Blocks Id System
/dev/sda1 *2048 206847 1024007 HPFS/NTFS/exFAT
/dev/sda2 206848 224671743 1122324487 HPFS/NTFS/exFAT
Disk /dev/sdb: 200.0 GB, 200049647616 bytes
255 heads, 63 sectors/track, 24321 cylinders, total 390721968 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xf0fa0806
Device Boot Start End Blocks Id System
/dev/sdb12048 349304831 1746513927 HPFS/NTFS/exFAT
/dev/sdb2 374722558 390721535 79994895 Extended
/dev/sdb3 * 349304832 37472051112707840 83 Linux
/dev/sdb5 374722560 390721535 7999488 82 Linux swap / Solaris
Partition table entries are not in disk order
ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: libecryptfs0 96-0ubuntu2
ProcVersionSignature: Ubuntu 3.2.0-18.29-generic 3.2.9
Uname: Linux 3.2.0-18-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 1.94.1-0ubuntu2
Architecture: amd64
Date: Tue Mar 13 09:56:56 2012
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64
(20120215)
ProcEnviron:
LANGUAGE=en_GB:en
TERM=xterm
LANG=en_GB.UTF-8
SHELL=/bin/bash
SourcePackage: ecryptfs-utils
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ecryptfs/+bug/953875/+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 1438612]
(In reply to Martin Pitt from comment #13) > (In reply to Lennart Poettering from comment #12) > > The best way is to fix the few services that really need dbus > > unconditionally to be around to add After=dbus.service. And all is good. > > If we go with that approach, then it would IMHO be cleaner to change the > implied "After=dbus.socket" for Type=dbus units to "After=dbus.service", for > the non-kdbus case at least. Nah, I am pretty sure this should be fixed in the few services that need this, rather than adding these otherwise unnecessary synchronization points to all services, including the ones that don't need it. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dbus in Ubuntu. https://bugs.launchpad.net/bugs/1438612 Title: remote file systems hang on shutdown, D-BUS stops too early Status in D-Bus: Confirmed Status in dbus package in Ubuntu: Fix Released Bug description: (part of bug 1431774). During shutdown, D-Bus stops too early. In particular, it stops before NetworkManager and remote-fs.target, so that any network unmount will cause errors and hang the boot. This can be seen with $ journalctl -b -1 | egrep 'Stop.*(D-Bus|Network M|Remote F)' Mär 30 19:05:19 donald systemd[1]: Stopping D-Bus System Message Bus... Mär 30 19:05:19 donald systemd[1]: Stopped D-Bus System Message Bus. Mär 30 19:05:19 donald systemd[1]: Stopped target Remote File Systems. Mär 30 19:05:19 donald systemd[1]: Stopping Remote File Systems. Mär 30 19:05:19 donald systemd[1]: Stopped target Remote File Systems (Pre). Mär 30 19:05:19 donald systemd[1]: Stopping Remote File Systems (Pre). Mär 30 19:05:19 donald systemd[1]: Stopping Network Manager... Mär 30 19:05:42 donald systemd[1]: Stopped Network Manager. Mär 30 19:05:42 donald systemd[1]: Stopping D-Bus System Message Bus Socket. A quick workaround is to add After=dbus.service to /lib/systemd/system/NetworkManager.service's [Unit] section, but this should be fixed in a more general fashion. To manage notifications about this bug go to: https://bugs.launchpad.net/dbus/+bug/1438612/+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 1438612]
Please do not apply that ExecStop= thing. You really shouldn't block that. Think about people who boot their system with "emergency" on the kernel cmdline, and thus get a PID 1 plus a shell and nothing else, they should be able to start dbus and stop it as they wish... If at all, use RefuseManualStop=yes on the unit, but I don't like that much either. It's mostly relevant for things like audit where the kernel might stop if the service is shut down. The best way is to fix the few services that really need dbus unconditionally to be around to add After=dbus.service. And all is good. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dbus in Ubuntu. https://bugs.launchpad.net/bugs/1438612 Title: remote file systems hang on shutdown, D-BUS stops too early Status in D-Bus: Confirmed Status in dbus package in Ubuntu: Fix Released Bug description: (part of bug 1431774). During shutdown, D-Bus stops too early. In particular, it stops before NetworkManager and remote-fs.target, so that any network unmount will cause errors and hang the boot. This can be seen with $ journalctl -b -1 | egrep 'Stop.*(D-Bus|Network M|Remote F)' Mär 30 19:05:19 donald systemd[1]: Stopping D-Bus System Message Bus... Mär 30 19:05:19 donald systemd[1]: Stopped D-Bus System Message Bus. Mär 30 19:05:19 donald systemd[1]: Stopped target Remote File Systems. Mär 30 19:05:19 donald systemd[1]: Stopping Remote File Systems. Mär 30 19:05:19 donald systemd[1]: Stopped target Remote File Systems (Pre). Mär 30 19:05:19 donald systemd[1]: Stopping Remote File Systems (Pre). Mär 30 19:05:19 donald systemd[1]: Stopping Network Manager... Mär 30 19:05:42 donald systemd[1]: Stopped Network Manager. Mär 30 19:05:42 donald systemd[1]: Stopping D-Bus System Message Bus Socket. A quick workaround is to add After=dbus.service to /lib/systemd/system/NetworkManager.service's [Unit] section, but this should be fixed in a more general fashion. To manage notifications about this bug go to: https://bugs.launchpad.net/dbus/+bug/1438612/+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 1347776]
I think the proper way to fix this is by waiting for this kernel patch
to be applied:
http://www.spinics.net/lists/linux-input/msg33007.html
With that in place we can then update logind to make use of it, and then
simply add the udev tag to all keyboards that are discovered, which
would then implicitly include any gpio kbd devices.
Without that kernel patch I am a bit concerned about listening to all of
the system's keypresses, as that might be a bit too much.
--
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/1347776
Title:
shutdown trigger on gpio_keys.X for armhf hardware
Status in systemd:
Confirmed
Status in “systemd” package in Ubuntu:
Fix Released
Status in “systemd” source package in Trusty:
Fix Released
Status in “systemd” source package in Utopic:
Fix Released
Bug description:
Some ARM board uses GPIO gpio_key.12 for power control (key=116). The
proposed patch adds entry to logind's 70-power-switch.rules to
initiate soft shutdown of the cartridge from ilo.
Here is the udevadm output for /dev/input/event0
sudo udevadm info --query=all --name=/dev/input/event0 --attribute-
walk
Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/soc.3/gpio_keys.12/input/input0/event0':
KERNEL=="event0"
SUBSYSTEM=="input"
DRIVER==""
looking at parent device '/devices/soc.3/gpio_keys.12/input/input0':
KERNELS=="input0"
SUBSYSTEMS=="input"
DRIVERS==""
ATTRS{name}=="gpio_keys.12"
ATTRS{phys}=="gpio-keys/input0"
ATTRS{uniq}==""
ATTRS{properties}=="0"
looking at parent device '/devices/soc.3/gpio_keys.12':
KERNELS=="gpio_keys.12"
SUBSYSTEMS=="platform"
DRIVERS=="gpio-keys"
ATTRS{keys}=="116"
ATTRS{switches}==""
ATTRS{disabled_keys}==""
ATTRS{disabled_switches}==""
looking at parent device '/devices/soc.3':
KERNELS=="soc.3"
SUBSYSTEMS=="platform"
DRIVERS==""
Regarding the possibility of gpio_key.12 being used by other systems
to map to some other trigger, I put in the check that the gpio_key.12
is associated with power control (keys=116). '116' is supposedly linux
generic power control in DTS. There is no uniq idSystem or idVendor
for device /dev/input/event0 as you can see from udevadm output,
therefore I tried to use the best available combination as a safety
check. This patch will enable power control for any system vendor
(Other than the one the patch in intended for) that describes in DTS,
the trigger gpio_key.12 as power control (116).
SRU Request
==
[Impact]
* User won't be able to initiate a soft shutdown from the chassis
manager.
[Test Case]
* To reproduce this bug, initiate a soft shutdown from the chassis manager,
for example from ilo you could do
set node power off shutdown
[Test Result]
== BEFORE PATCH ==
$ cat /lib/udev/rules.d/70-power-switch.rules
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
ACTION=="remove", GOTO="power_switch_end"
SUBSYSTEM=="input", KERNEL=="event*", SUBSYSTEMS=="acpi", TAG+="power-switch"
SUBSYSTEM=="input", KERNEL=="event*", KERNELS=="thinkpad_acpi",
TAG+="power-switch"
LABEL="power_switch_end"
$
hpiLO-> set node power off shutdown c3n2
c3: #Cartridge 3
c3n2: #Node 2 Shutting node down gracefully
hpiLO-> show node list
Slot ID Proc Manufacturer Architecture Memory Power Health
- -- -- - --
3 c3n1 ARM Architecture 8 GB On OK
3 c3n2 ARM Architecture 8 GB On OK
3 c3n3 ARM Architecture 8 GB On OK
3 c3n4 ARM Architecture 8 GB Off OK
hpiLO->
== AFTER PATCH ==
hpiLO-> set node power off shutdown c3n1
c3: #Cartridge 3
c3n1: #Node 1 Shutting node down gracefully
hpiLO-> show node list
Slot ID Proc Manufacturer Architecture Memory Power Health
- -- -- - --
3 c3n1 ARM Architecture 8 GB Off OK
3 c3n2 ARM Architecture 8 GB On OK
3 c3n3 ARM Architecture 8 GB On OK
3 c3n4 ARM Architecture 8 GB Off OK
hpiLO->
[Regression Potential]
None.
Note: Regarding the possibility of gpio_key.12 being used by other systems to
map to some other trigger, I put
[Touch-packages] [Bug 1354306]
I think the proper way to fix this is by waiting for this kernel patch to be applied: http://www.spinics.net/lists/linux-input/msg33007.html With that in place we can then update logind to make use of it, and then simply add the udev tag to all keyboards that are discovered, which would then implicitly include any gpio kbd devices. Without that kernel patch I am a bit concerned about listening to all of the system's keypresses, as that might be a bit too much. -- 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/1354306 Title: gpio shutdown trigger for ProLiant m400 cartridges Status in systemd: Confirmed Status in “systemd” package in Ubuntu: Triaged Status in “systemd” source package in Trusty: Triaged Status in “systemd” source package in Utopic: Triaged Bug description: Similar to the m800 case in LP: #1347776, udev/systemd also needs to know how to trigger a graceful shutdown on ProLiant m400 cartridges. [Impact] Without this change, the power down button will not initiate an OS shutdown on this platform. [Test Case] Push button. Watch poweroff occur. [Regression Potential] The new rule is pretty tightly bound to the m400 system - so the risk of this rule matching and impacting behavior on a different platform is minimal. This will presumably cause new code to run and read /proc/device-tree/model on other platforms - but this is already done for the m800 system in both utopic and trusty. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1354306/+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
