date:20181113

[Touch-packages] [Bug 1732411] Re: On upgrade, daemon-reexec should only be issued if safe

2018-11-13 Thread Pierre Schweitzer

A fix [1] in LXC was pushed recently and actually allows systemd daemon-
reexec without the cap sys_admin in a container.

We tested that it totally solved the issue for us.
Would it possible to move this bug report to the LXC project? And to ask for a 
backport of such fix to Xenial LXC?

Thanks!

[1]
https://github.com/lxc/lxc/commit/af949cc1938ff3a4e06148867a64d7715ce89a50

-- 
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/1732411

Title:
  On upgrade, daemon-reexec should only be issued if safe

Status in lxc package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  New

Bug description:
  Dear all,

  Following up the bug #1713674, when executing systemd in a hardened
  LXC context, it might not be suitable to reexec systemd daemon, that
  would not be able to perform.

  For instance, in our LXC, we drop several capabilities, including
  sys_admin and we set /sys to read-only (in which, systemd will find
  its cgroups). This means, systemd cannot be reexecuted, it will fail
  to restart and will freeze (properly) at restart making the LXC
  container in frozen state (still working, but no new services
  startable, no interaction with systemd possible anymore).

  When upgrading systemd the debian package, as postinst, will always
  attempt to reexecute systemd, possibly breaking every other upgrade
  where a daemon restart is made in postinst, and leaving the system in
  a degraded state.

  It would likely be appropriate the check whether the reexecute can
  work will before performing it: checking capabilities, sys mount point
  perms, etc. If not applicable, not performing a reexucte and possibly
  print a message to the user.

  Occurs with Ubuntu Xenial 16.04.3 LTS and systemd 229-4ubuntu21.

  Cheers

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1732411/+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 1802469] Re: after upgrade to 18.04 the system sometimes just boots into emergency mode

2018-11-13 Thread latimerio

Today it happened again and I have attached a screenshot here.
As said, after a ctrl-alt-delete the system booted ok and I can see no sign of
the failed disk in the logs.

** Attachment added: "IMG_20181114_081408_739.jpg"

https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1802469/+attachment/5212555/+files/IMG_20181114_081408_739.jpg

--
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/1802469

Title:
after upgrade to 18.04 the system sometimes just boots into emergency
mode

Status in systemd package in Ubuntu:
New

Bug description:
After I updated my server (no GUI) from 16.04 to 18.04 my system sometimes
gets stuck in emergency mode.
Normally my system needs about 20 seconds to get through the dmesg part, and
then another 2-5 seconds until the login prompt.

The dmesg part is still fine but, after that, about once a week, I see
very slow boot messages dripping down the screen at a rate of 1
line/second.

If this happens, somewhere along the way, the system issues a warning
about a device which has timed out like below:

dev-disk-by\x2duuid-db5f4fae\x2d18a0\x2d4df3\x2d8ba3\x2d709f00eac21c.device:
Job
dev-disk-by\x2duuid-db5f4fae\x2d18a0\x2d4df3\x2d8ba3\x2d709f00eac21c.device/start
timed out.`

and, some time later, there is a message about starting an emergency shell.
But then, the system seems to hang, and I get no prompt nor any console
feedback upon typing.

I can issue a Ctrl+Alt+Del though which does a reboot.
After I had done that the system up to now always came up properly in about
20 seconds as stated above and I do not see the device which was complained
about before.

I have no clue how I can troubleshoot the issue.
Is this a known problem due to some conflicting conditions in the "glorious"
systemd boot mechanisms?
Is there a command like "systemd-analyze blame" which can analyze a failed
previous boot?

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: systemd 237-3ubuntu10.4
ProcVersionSignature: Ubuntu 4.15.0-38.41-generic 4.15.18
Uname: Linux 4.15.0-38-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.4
Architecture: amd64
Date: Fri Nov 9 08:52:32 2018
MachineType: ASUSTeK COMPUTER INC. P9D-X Series
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-38-generic
root=UUID=0fa1f208-3a7b-44ca-9f85-e7349a3b1844 ro nosplash
SourcePackage: systemd
UpgradeStatus: Upgraded to bionic on 2018-10-11 (28 days ago)
dmi.bios.date: 10/13/2014
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 0901
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: P9D-X Series
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: Rev 1.xx
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 17
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias:
dmi:bvnAmericanMegatrendsInc.:bvr0901:bd10/13/2014:svnASUSTeKCOMPUTERINC.:pnP9D-XSeries:pvrRev1.xx:rvnASUSTeKCOMPUTERINC.:rnP9D-XSeries:rvrRev1.xx:cvnToBeFilledByO.E.M.:ct17:cvrToBeFilledByO.E.M.:
dmi.product.family: To be filled by O.E.M.
dmi.product.name: P9D-X Series
dmi.product.version: Rev 1.xx
dmi.sys.vendor: ASUSTeK COMPUTER INC.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1802469/+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 1772094] Re: Surface Pro 4: Keyboard not functional during LUKS password prompt

2018-11-13 Thread William

The module gets excluded in the initramfs core package.

attached is a patch which resolves the issue by not excluding the hid-
multitouch.ko module.

** Patch added: "multitouch.patch"

https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1772094/+attachment/5212554/+files/multitouch.patch

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

Title:
Surface Pro 4: Keyboard not functional during LUKS password prompt

Status in initramfs-tools package in Ubuntu:
Confirmed

Bug description:
I installed Ubuntu 18.04 desktop edition on a Microsoft Surface Pro 4,
using LVM and full disk encryption. When LUKS prompts for the
password, however, the type cover keyboard does not work. I had to
plug in a USB keyboard to type in the password and boot.

However, the solution is simple. Edit the /etc/initramfs-
tools/modules file, add "hid_multitouch" to a line on its own, then
run "update-initramfs -u". Now the typecover keyboard can be used to
enter the LUKS password on boot.

The Ubuntu 18.04 desktop installer should be modified to detect if it
is running on Surface Pro hardware, and add the module, above, as
needed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1772094/+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

90 matches

Mail list logo