[Touch-packages] [Bug 1902748] Re: ubuntu-seed / ubuntu-boot partition detection could be improved
** Changed in: snapd Assignee: Ian Johnson (anonymouse67) => (unassigned) -- 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/1902748 Title: ubuntu-seed / ubuntu-boot partition detection could be improved Status in snapd: Confirmed Status in linux package in Ubuntu: Incomplete Status in systemd package in Ubuntu: Invalid Bug description: ubuntu-seed / ubuntu-boot partition detection could be improved Currently in the initrd, snapd-bootstrap searches for ubuntu-boot / ubuntu-seed partition by label or by UEFI variable that was set by sd- boot. sdboot uses devicepath UEFI protocol to establish MEDIA_DEVICE_PATH, HARDDRIVE_DEVICEPATH, GUID, Signature aka partuuid that was used to boot. https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/DevicePath.h This is nice, but not unique enough. It would be nice if we were able to modify sd-boot stub to export something more specific that ideally maps to a sysfs path. For example PCI_DEVICE_PATH, SCSI_DEVICE_PATH, SATA_DEVICE_PATH, USB_DEVICE_PATH, NVME_NAMESPACE_DEVICE_PATH, SD_DEVICE_PATH, UFS_DEVICE_PATH, EMMC_DEVICE_PATH or some such. That way initrd would be able to resolve better which block device to key off. Given that EFI device handle is passed to the kernel, doesn't kernel also know where it came from? or not? To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1902748/+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 1961418] Re: snap failed to run with '/usr/bin/snap wait system seed.loaded'
So indeed your system is still using upstart, in order to use snapd you
will need to switch your system over to use systemd instead. Likely one
of the upgrade scripts from 10.04 to 16.04 did not transition from
upstart to systemd the way a fresh install of 16.04 would default to.
** Changed in: snapd (Ubuntu)
Status: Incomplete => Won't Fix
--
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/1961418
Title:
snap failed to run with '/usr/bin/snap wait system seed.loaded'
Status in snapd package in Ubuntu:
Won't Fix
Status in systemd package in Ubuntu:
New
Bug description:
I tried to enable livepatch without any success. ([Bug 1960689] )
support suggested me report a bug for snapd.
root@plis231v:~# sudo ua enable livepatch
One moment, checking your subscription first
Unexpected error(s) occurred.
For more details, see the log: /var/log/ubuntu-advantage.log
To file a bug run: ubuntu-bug ubuntu-advantage-tools
>> logs
22-02-11 22:27:00,410 - util.py:(429) [DEBUG]: Reading file:
/var/lib/ubuntu-advantage/notices.json
2022-02-11 22:27:00,410 - util.py:(700) [DEBUG]: Writing file:
/var/lib/ubuntu-advantage/notices.json
2022-02-11 22:27:00,411 - cli.py:(1499) [ERROR]: Unhandled exception,
please file a bug
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/uaclient/cli.py", line 1458, in
wrapper
return func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/uaclient/cli.py", line 1544, in main
return args.action(args, cfg=cfg)
File "/usr/lib/python3/dist-packages/uaclient/cli.py", line 166, in new_f
return f(*args, **kwargs)
File "/usr/lib/python3/dist-packages/uaclient/cli.py", line 189, in new_f
return f(args, cfg=cfg, **kwargs)
File "/usr/lib/python3/dist-packages/uaclient/cli.py", line 147, in new_f
retval = f(*args, cfg=cfg, **kwargs)
File "/usr/lib/python3/dist-packages/uaclient/cli.py", line 888, in
action_enable
ent_ret, reason = entitlement.enable()
File "/usr/lib/python3/dist-packages/uaclient/entitlements/base.py", line
197, in enable
ret = self._perform_enable(silent=silent)
File "/usr/lib/python3/dist-packages/uaclient/entitlements/livepatch.py",
line 160, in _perform_ena
[snap.SNAP_CMD, "wait", "system", "seed.loaded"], capture=True
File "/usr/lib/python3/dist-packages/uaclient/util.py", line 662, in subp
out, err = _subp(args, rcs, capture, timeout, env=env)
File "/usr/lib/python3/dist-packages/uaclient/util.py", line 619, in _subp
stderr=err.decode("utf-8"),
uaclient.util.ProcessExecutionError: Failed running command '/usr/bin/snap
wait system seed.loaded' [sage: error: cannot communicate with server: Get
http://localhost/v2/snaps/system/conf?keys=seed.load /run/snapd.socket:
connect: no such file or directory
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: ubuntu-advantage-tools 27.4.1~16.04.1
ProcVersionSignature: Ubuntu 4.15.0-167.175~16.04.1-generic 4.15.18
Uname: Linux 4.15.0-167-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.30+esm3
Architecture: amd64
Date: Fri Feb 11 23:01:08 2022
InstallationDate: Installed on 2010-12-02 (4089 days ago)
InstallationMedia: Ubuntu-Server 10.04.1 LTS "Lucid Lynx" - Release amd64
(20100816.2)
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: ubuntu-advantage-tools
UpgradeStatus: Upgraded to xenial on 2017-01-21 (1847 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1961418/+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 1961418] Re: snap failed to run with '/usr/bin/snap wait system seed.loaded'
What is the output of these commands:
ps -o cmd fp 1
sudo ls -lah /proc/1/exe
cat /proc/cmdline
--
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/1961418
Title:
snap failed to run with '/usr/bin/snap wait system seed.loaded'
Status in snapd package in Ubuntu:
Incomplete
Status in systemd package in Ubuntu:
New
Bug description:
I tried to enable livepatch without any success. ([Bug 1960689] )
support suggested me report a bug for snapd.
root@plis231v:~# sudo ua enable livepatch
One moment, checking your subscription first
Unexpected error(s) occurred.
For more details, see the log: /var/log/ubuntu-advantage.log
To file a bug run: ubuntu-bug ubuntu-advantage-tools
>> logs
22-02-11 22:27:00,410 - util.py:(429) [DEBUG]: Reading file:
/var/lib/ubuntu-advantage/notices.json
2022-02-11 22:27:00,410 - util.py:(700) [DEBUG]: Writing file:
/var/lib/ubuntu-advantage/notices.json
2022-02-11 22:27:00,411 - cli.py:(1499) [ERROR]: Unhandled exception,
please file a bug
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/uaclient/cli.py", line 1458, in
wrapper
return func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/uaclient/cli.py", line 1544, in main
return args.action(args, cfg=cfg)
File "/usr/lib/python3/dist-packages/uaclient/cli.py", line 166, in new_f
return f(*args, **kwargs)
File "/usr/lib/python3/dist-packages/uaclient/cli.py", line 189, in new_f
return f(args, cfg=cfg, **kwargs)
File "/usr/lib/python3/dist-packages/uaclient/cli.py", line 147, in new_f
retval = f(*args, cfg=cfg, **kwargs)
File "/usr/lib/python3/dist-packages/uaclient/cli.py", line 888, in
action_enable
ent_ret, reason = entitlement.enable()
File "/usr/lib/python3/dist-packages/uaclient/entitlements/base.py", line
197, in enable
ret = self._perform_enable(silent=silent)
File "/usr/lib/python3/dist-packages/uaclient/entitlements/livepatch.py",
line 160, in _perform_ena
[snap.SNAP_CMD, "wait", "system", "seed.loaded"], capture=True
File "/usr/lib/python3/dist-packages/uaclient/util.py", line 662, in subp
out, err = _subp(args, rcs, capture, timeout, env=env)
File "/usr/lib/python3/dist-packages/uaclient/util.py", line 619, in _subp
stderr=err.decode("utf-8"),
uaclient.util.ProcessExecutionError: Failed running command '/usr/bin/snap
wait system seed.loaded' [sage: error: cannot communicate with server: Get
http://localhost/v2/snaps/system/conf?keys=seed.load /run/snapd.socket:
connect: no such file or directory
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: ubuntu-advantage-tools 27.4.1~16.04.1
ProcVersionSignature: Ubuntu 4.15.0-167.175~16.04.1-generic 4.15.18
Uname: Linux 4.15.0-167-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.30+esm3
Architecture: amd64
Date: Fri Feb 11 23:01:08 2022
InstallationDate: Installed on 2010-12-02 (4089 days ago)
InstallationMedia: Ubuntu-Server 10.04.1 LTS "Lucid Lynx" - Release amd64
(20100816.2)
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: ubuntu-advantage-tools
UpgradeStatus: Upgraded to xenial on 2017-01-21 (1847 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1961418/+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 1953171] [NEW] package linux-image-5.13.0-1011-raspi 5.13.0-1011.13 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
Public bug reported: While upgrading my Raspberry Pi 3 running 21.04 to 21.10, the upgrade failed ProblemType: Package DistroRelease: Ubuntu 21.10 Package: linux-image-5.13.0-1011-raspi 5.13.0-1011.13 ProcVersionSignature: Ubuntu 5.11.0-1023.25-raspi 5.11.22 Uname: Linux 5.11.0-1023-raspi aarch64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl icp ApportVersion: 2.20.11-0ubuntu71 Architecture: arm64 CasperMD5CheckResult: unknown Date: Fri Dec 3 03:19:32 2021 ErrorMessage: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 Python3Details: /usr/bin/python3.9, Python 3.9.7, python3-minimal, 3.9.4-1build1 PythonDetails: N/A RebootRequiredPkgs: Error: path contained symlinks. RelatedPackageVersions: dpkg 1.20.9ubuntu2 apt 2.3.9 SourcePackage: initramfs-tools Title: package linux-image-5.13.0-1011-raspi 5.13.0-1011.13 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 UpgradeStatus: Upgraded to impish on 2021-12-03 (0 days ago) ** Affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Tags: apport-package arm64 impish need-duplicate-check uec-images -- 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/1953171 Title: package linux-image-5.13.0-1011-raspi 5.13.0-1011.13 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 Status in initramfs-tools package in Ubuntu: New Bug description: While upgrading my Raspberry Pi 3 running 21.04 to 21.10, the upgrade failed ProblemType: Package DistroRelease: Ubuntu 21.10 Package: linux-image-5.13.0-1011-raspi 5.13.0-1011.13 ProcVersionSignature: Ubuntu 5.11.0-1023.25-raspi 5.11.22 Uname: Linux 5.11.0-1023-raspi aarch64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl icp ApportVersion: 2.20.11-0ubuntu71 Architecture: arm64 CasperMD5CheckResult: unknown Date: Fri Dec 3 03:19:32 2021 ErrorMessage: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 Python3Details: /usr/bin/python3.9, Python 3.9.7, python3-minimal, 3.9.4-1build1 PythonDetails: N/A RebootRequiredPkgs: Error: path contained symlinks. RelatedPackageVersions: dpkg 1.20.9ubuntu2 apt 2.3.9 SourcePackage: initramfs-tools Title: package linux-image-5.13.0-1011-raspi 5.13.0-1011.13 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 UpgradeStatus: Upgraded to impish on 2021-12-03 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1953171/+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 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18
@slyon could you make available the core18 snap you built with this systemd ? -- 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/1949089 Title: systemd randomly fails to activate mount units in Ubuntu Core 18 Status in systemd package in Ubuntu: New Bug description: Since a month or so, we've been seeing random failures in our snapd spread tests where systemd could not start the mount unit associated with a snap because of a failed dependency. The issue is described in the comments to PR https://github.com/snapcore/snapd/pull/10935, but I'll summarize it here. When starting a snap, snapd creates a mount unit to mount the snap's squashfs (the template is https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205). The snapd asks systemd to reload the configuration, and starts the mount unit. The failure we've observed is that sometimes systemd decides to stop our mount unit (search for "Unmounting Mount unit for test-snapd-svc- flip-flop" in the attached log), and then tries to reactivate it again, and at that point it fails. When I asked for help, Lukas pointed out that the latest update contains a patch that is related to reload handling and mount units: http://launchpadlibrarian.net/555420796/systemd_237-3ubuntu10.51_237-3ubuntu10.52.diff.gz (the patch itself is better visible at https://github.com/systemd/systemd/commit/f0831ed2a03fcef582660be1c3b1a9f3e267e656). When looking at the systemd git log, though, I noticed another patch that was applied shortly after this one, which also seems related but was not backported: https://github.com/systemd/systemd/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0 Since the stopping of our mount unit happens immediately after a systemd reload, it actually seems very likely that the inclusion of f0831ed2a03fcef582660be1c3b1a9f3e267e656 in the systemd update is what causes our woes (though, indeed, the issue is not reliably reproducible, so we cannot be sure). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+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 1943077] Re: snapd fails to autopkgtest on mksquashfs, which is looking for libgcc_s
Dan, note that although we set the SNAP_REEXEC environment variable in that integration test, that environment variable is actually not obeyed when it comes to the mksquashfs command which is called here: https://github.com/snapcore/snapd/blob/dfba7de59a41bc22786d87f53b20deea14240713/snap/squashfs/squashfs.go#L524 and the function snapdtool.CommandFromSystemSnap does not observe the SNAP_REEXEC environment variable at all, instead just checking if the snapd or core snaps exist at all, and using the mksquashfs from those snaps instead of what's on the host on $PATH (though we do fallback and if there is no mksquashfs found in the core or snapd snaps (somehow???), then we use $PATH). As I mentioned on IRC, we could potentially someday add a workaround where if mksquashfs from the system snap specifically segfaults then we will fall back to using the host's mksquashfs, but we have chosen for now not to work on that patch. Hope this helps explain things. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1943077 Title: snapd fails to autopkgtest on mksquashfs, which is looking for libgcc_s Status in snapd: Fix Committed Status in openssh package in Ubuntu: New Status in squashfs-tools package in Ubuntu: New Bug description: During current snapd autopkgtest, a failure can be observed: https://autopkgtest.ubuntu.com/results/autopkgtest- impish/impish/amd64/s/snapd/20210907_175258_5451b@/log.gz error: cannot pack "/home/gopath/src/github.com/snapcore/snapd/tests/smoke/sandbox/test-snapd-sandbox": mksquashfs call failed: - libgcc_s.so.1 must be installed for pthread_cancel to work Parallel mksquashfs: Using 1 processor Creating 4.0 filesystem on /home/gopath/src/github.com/snapcore/snapd/tests/smoke/sandbox/test-snapd-sandbox/test-snapd-sandbox_1.0_all.snap, block size 131072. - error: cannot read snap file: "/var/lib/snapd/snaps/.local-install-136125945" is not a snap or snapdir I traced the underlying call to the following: "/snap/snapd/current/lib/x86_64-linux-gnu/ld-2.23.so" "--library-path" "/snap/snapd/current/usr/local/lib:/snap/snapd/current/lib/x86_64-linux-gnu:/snap/snapd/current/usr/lib/x86_64-linux-gnu" "/snap/snapd/current/usr/bin/mksquashfs" asdf asdf.squashfs (the real call has more arguments, this is a simplified version that produces the failure) To observe this, one can create a VM based a cloud image from https://cloud-images.ubuntu.com/impish/current, then run the above command in the resulting environment. Doing so will test against snapd v2.51.4 (12883). Retesting with edge 2.52+git635.gada2d87 (13323) produces an equivalent result. Running a more bland `/snap/snapd/current/usr/bin/mksquashfs asdf asdf.squashfs` without messing with library paths has mksquashfs behaving as expected. Also, getting a v2.51.3 snapd seems to behave itself. Updating from 2.51.3 -> 2.51.4 also works. One can see a passing mksquashfs by taking libgcc_s.so.1 from hirsute and placing it in the library path for the above call. In the working scenario, it appears that libgcc_s is being obtained from outside of /snap (and also libz). In the failing scenario, this external copy of libgcc_s is not being loaded (per gdb info sharedlibrary), but libz still is. To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1943077/+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 1794064] Re: Clicking a hyperlink in a PDF fails to open it if the default browser is a snap
Also I'm not sure I agree with jdstrand's apparmor profile which includes: /run/snapd.socket rw, which I don't think we want to grant to any PDF file opened with evince? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1794064 Title: Clicking a hyperlink in a PDF fails to open it if the default browser is a snap Status in apparmor package in Ubuntu: Confirmed Status in evince package in Ubuntu: Triaged Bug description: This is related to bug #1792648. After fixing that one (see discussion at https://salsa.debian.org/gnome-team/evince/merge_requests/1), clicking a hyperlink in a PDF opens it correctly if the default browser is a well-known application (such as /usr/bin/firefox), but it fails to do so if the default browser is a snap (e.g. the chromium snap). This is not a recent regression, it's not working on bionic either. ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: evince 3.30.0-2 ProcVersionSignature: Ubuntu 4.18.0-7.8-generic 4.18.5 Uname: Linux 4.18.0-7-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.10-0ubuntu11 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Sep 24 12:28:06 2018 EcryptfsInUse: Yes InstallationDate: Installed on 2016-07-02 (813 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) SourcePackage: evince UpgradeStatus: Upgraded to cosmic on 2018-09-14 (9 days ago) modified.conffile..etc.apparmor.d.abstractions.evince: [modified] mtime.conffile..etc.apparmor.d.abstractions.evince: 2018-09-24T11:35:41.904158 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1794064/+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 1943077] Re: snapd fails to autopkgtest on mksquashfs, which is looking for libgcc_s
As seb128 found, the issue is also affecting the debian package of snapd since when we call mksquashfs, we actually have code which specifically calls mksquashfs from the "system" snap which is either the snapd snap or the core snap, this is presumably to ensure that a consistent mksquashfs is used always and to avoid snaps from being packed with too old or new mksquashfs's. So the net effect is that the fix for this that was landed into the snapd snap will also probably need to be added to the core snap for completeness, and also means that the only way to avoid snap pack from failing is to have a snapd snap with the fix which is only available on the edge channel currently. So long story short, if you are affected by this today, a short-term workaround is to use the edge channel of the snapd snap by running snap refresh snapd --edge We have already included the fix into the snapd snap that is built on edge and it will be included in the release branch for 2.52, meaning that the next bugfix release on 2.52 will have the fix, we do plan on doing a 2.52.1 release in short order after 2.52 is complete, but it may be a few weeks from now before that is on stable. ** Changed in: snapd Milestone: None => 2.52 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1943077 Title: snapd fails to autopkgtest on mksquashfs, which is looking for libgcc_s Status in snapd: Fix Committed Status in openssh package in Ubuntu: New Status in squashfs-tools package in Ubuntu: New Bug description: During current snapd autopkgtest, a failure can be observed: https://autopkgtest.ubuntu.com/results/autopkgtest- impish/impish/amd64/s/snapd/20210907_175258_5451b@/log.gz error: cannot pack "/home/gopath/src/github.com/snapcore/snapd/tests/smoke/sandbox/test-snapd-sandbox": mksquashfs call failed: - libgcc_s.so.1 must be installed for pthread_cancel to work Parallel mksquashfs: Using 1 processor Creating 4.0 filesystem on /home/gopath/src/github.com/snapcore/snapd/tests/smoke/sandbox/test-snapd-sandbox/test-snapd-sandbox_1.0_all.snap, block size 131072. - error: cannot read snap file: "/var/lib/snapd/snaps/.local-install-136125945" is not a snap or snapdir I traced the underlying call to the following: "/snap/snapd/current/lib/x86_64-linux-gnu/ld-2.23.so" "--library-path" "/snap/snapd/current/usr/local/lib:/snap/snapd/current/lib/x86_64-linux-gnu:/snap/snapd/current/usr/lib/x86_64-linux-gnu" "/snap/snapd/current/usr/bin/mksquashfs" asdf asdf.squashfs (the real call has more arguments, this is a simplified version that produces the failure) To observe this, one can create a VM based a cloud image from https://cloud-images.ubuntu.com/impish/current, then run the above command in the resulting environment. Doing so will test against snapd v2.51.4 (12883). Retesting with edge 2.52+git635.gada2d87 (13323) produces an equivalent result. Running a more bland `/snap/snapd/current/usr/bin/mksquashfs asdf asdf.squashfs` without messing with library paths has mksquashfs behaving as expected. Also, getting a v2.51.3 snapd seems to behave itself. Updating from 2.51.3 -> 2.51.4 also works. One can see a passing mksquashfs by taking libgcc_s.so.1 from hirsute and placing it in the library path for the above call. In the working scenario, it appears that libgcc_s is being obtained from outside of /snap (and also libz). In the failing scenario, this external copy of libgcc_s is not being loaded (per gdb info sharedlibrary), but libz still is. To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1943077/+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 1932579] Re: snap pt_BR locale shows warning every time
Ah Miguel, thanks for realizing my error, I should have probably just said something like sudo snap install snapd --edge; sudo snap refresh snapd --edge which will ensure that it's always installed and gets refreshed. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to language-pack-pt-base in Ubuntu. https://bugs.launchpad.net/bugs/1932579 Title: snap pt_BR locale shows warning every time Status in snapd: Fix Committed Status in language-pack-pt-base package in Ubuntu: Confirmed Status in snapd package in Ubuntu: Fix Committed Bug description: The following warning appears every time I type a snap command, and thus breaks auto-completion. 2021/06/18 13:15:24.372374 main.go:176: description of prepare-image's "" is lowercase in locale "pt_BR": "o directório de destino" The problem seems locale dependent, since "LANG=C snap" doesn't show this warning. I'm currently using Ubuntu 21.04, and this bug happens since I upgraded from 20.10. (I don't know if this is off-topic or where I can help, but "directório" is more pt_PT than pt_BR, which could be "pasta/diretório") echo $LANG output: pt_BR.UTF-8 lsb_release -rb output: Description: Ubuntu 21.04 Release: 21.04 apt-cache policy snapd output: snapd: Instalado: 2.49.2+21.04ubuntu1 Candidato: 2.49.2+21.04ubuntu1 Tabela de versão: *** 2.49.2+21.04ubuntu1 500 500 http://br.archive.ubuntu.com/ubuntu hirsute/main amd64 Packages 100 /var/lib/dpkg/status snap list output: ...[other packages]... snap-store 3.38.0-64-g23c4c77 547latest/stable canonical✓ - snapd 2.5112159 latest/stable canonical✓ snapd To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1932579/+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 1932579] Re: snap pt_BR locale shows warning every time
@iogui, hmm it could be that our fix isn't working, can you show the output of these commands: snap version snap list -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to language-pack-pt-base in Ubuntu. https://bugs.launchpad.net/bugs/1932579 Title: snap pt_BR locale shows warning every time Status in snapd: Fix Committed Status in language-pack-pt-base package in Ubuntu: Confirmed Status in snapd package in Ubuntu: Fix Committed Bug description: The following warning appears every time I type a snap command, and thus breaks auto-completion. 2021/06/18 13:15:24.372374 main.go:176: description of prepare-image's "" is lowercase in locale "pt_BR": "o directório de destino" The problem seems locale dependent, since "LANG=C snap" doesn't show this warning. I'm currently using Ubuntu 21.04, and this bug happens since I upgraded from 20.10. (I don't know if this is off-topic or where I can help, but "directório" is more pt_PT than pt_BR, which could be "pasta/diretório") echo $LANG output: pt_BR.UTF-8 lsb_release -rb output: Description: Ubuntu 21.04 Release: 21.04 apt-cache policy snapd output: snapd: Instalado: 2.49.2+21.04ubuntu1 Candidato: 2.49.2+21.04ubuntu1 Tabela de versão: *** 2.49.2+21.04ubuntu1 500 500 http://br.archive.ubuntu.com/ubuntu hirsute/main amd64 Packages 100 /var/lib/dpkg/status snap list output: ...[other packages]... snap-store 3.38.0-64-g23c4c77 547latest/stable canonical✓ - snapd 2.5112159 latest/stable canonical✓ snapd To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1932579/+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 1932579] Re: snap pt_BR locale shows warning every time
@iogui could you try again? snapd on the edge channel may not have finished building by the time you tried, but I see that there was an update pushed out this morning. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to language-pack-pt-base in Ubuntu. https://bugs.launchpad.net/bugs/1932579 Title: snap pt_BR locale shows warning every time Status in snapd: Fix Committed Status in language-pack-pt-base package in Ubuntu: Confirmed Status in snapd package in Ubuntu: Fix Committed Bug description: The following warning appears every time I type a snap command, and thus breaks auto-completion. 2021/06/18 13:15:24.372374 main.go:176: description of prepare-image's "" is lowercase in locale "pt_BR": "o directório de destino" The problem seems locale dependent, since "LANG=C snap" doesn't show this warning. I'm currently using Ubuntu 21.04, and this bug happens since I upgraded from 20.10. (I don't know if this is off-topic or where I can help, but "directório" is more pt_PT than pt_BR, which could be "pasta/diretório") echo $LANG output: pt_BR.UTF-8 lsb_release -rb output: Description: Ubuntu 21.04 Release: 21.04 apt-cache policy snapd output: snapd: Instalado: 2.49.2+21.04ubuntu1 Candidato: 2.49.2+21.04ubuntu1 Tabela de versão: *** 2.49.2+21.04ubuntu1 500 500 http://br.archive.ubuntu.com/ubuntu hirsute/main amd64 Packages 100 /var/lib/dpkg/status snap list output: ...[other packages]... snap-store 3.38.0-64-g23c4c77 547latest/stable canonical✓ - snapd 2.5112159 latest/stable canonical✓ snapd To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1932579/+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 1932579] Re: snap pt_BR locale shows warning every time
The message should no longer be shown anymore in snapd as the PR referenced by Maciej has been merged and should be available on the edge channel of snapd in the few hours. Please give it a try if you like with: ``` snap install snapd --edge || snap refresh snapd --edge # test the snap command to make sure the message no longer appears snap refresh snapd --stable # to go back to tracking stable, as edge sometimes can have unstable changes on it ``` Thanks, Ian ** Changed in: snapd (Ubuntu) Status: Confirmed => Fix Committed ** Changed in: snapd (Ubuntu) Importance: Undecided => Medium ** Also affects: snapd Importance: Undecided Status: New ** Changed in: snapd Milestone: None => 2.53 ** Changed in: snapd Status: New => Fix Committed ** Changed in: snapd Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to language-pack-pt-base in Ubuntu. https://bugs.launchpad.net/bugs/1932579 Title: snap pt_BR locale shows warning every time Status in snapd: Fix Committed Status in language-pack-pt-base package in Ubuntu: Confirmed Status in snapd package in Ubuntu: Fix Committed Bug description: The following warning appears every time I type a snap command, and thus breaks auto-completion. 2021/06/18 13:15:24.372374 main.go:176: description of prepare-image's "" is lowercase in locale "pt_BR": "o directório de destino" The problem seems locale dependent, since "LANG=C snap" doesn't show this warning. I'm currently using Ubuntu 21.04, and this bug happens since I upgraded from 20.10. (I don't know if this is off-topic or where I can help, but "directório" is more pt_PT than pt_BR, which could be "pasta/diretório") echo $LANG output: pt_BR.UTF-8 lsb_release -rb output: Description: Ubuntu 21.04 Release: 21.04 apt-cache policy snapd output: snapd: Instalado: 2.49.2+21.04ubuntu1 Candidato: 2.49.2+21.04ubuntu1 Tabela de versão: *** 2.49.2+21.04ubuntu1 500 500 http://br.archive.ubuntu.com/ubuntu hirsute/main amd64 Packages 100 /var/lib/dpkg/status snap list output: ...[other packages]... snap-store 3.38.0-64-g23c4c77 547latest/stable canonical✓ - snapd 2.5112159 latest/stable canonical✓ snapd To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1932579/+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 1934147] Re: systemd leaks abandoned session scopes
This systemd bug can be problematic for snapd as well, leading to the
sort of situation in https://bugs.launchpad.net/snapd/+bug/1928806,
where running snap commands frequently leads to many many many leftover
scopes like this
** Also affects: snapd
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/1934147
Title:
systemd leaks abandoned session scopes
Status in snapd:
New
Status in systemd:
New
Status in systemd package in Ubuntu:
In Progress
Status in systemd source package in Bionic:
Confirmed
Status in systemd source package in Focal:
In Progress
Status in systemd source package in Groovy:
In Progress
Status in systemd source package in Hirsute:
In Progress
Status in systemd source package in Impish:
In Progress
Bug description:
[impact]
systemd may leak sessions, leaving empty cgroups around as well as
abandoned session scopes.
[test case]
on a system where the user has a ssh key that allows noninteractive
login to localhost, and also has noninteractive sudo, run:
$ for i in {1..100}; do sudo -b -i -u ubuntu ssh localhost -- sleep 1;
done; for i in {1..20}; do echo 'Reloading...'; sudo systemctl daemon-
reload; done
check the sessions to see there have been leaked sessions:
$ loginctl list-sessions
SESSION UID USER SEAT TTY
1 1000 ubuntu ttyS0
350 1000 ubuntu
351 1000 ubuntu
360 1000 ubuntu
...
to verify the sessions were leaked, clear them out with:
$ echo '' | sudo tee
/sys/fs/cgroup/unified/user.slice/user-1000.slice/session-*.scope/cgroup.events
that should result in all the leaked sessions being cleaned up.
[regression potential]
issues during systemd pid1 reexec/reload, or issues while cleaning up
sessions, including leaking sessions/cgroups
[scope]
this is needed for all releases
upstream bug linked above, and upstream PR:
https://github.com/systemd/systemd/pull/20199
[original description]
On a system that is monitored via telegraf I found many abandoned
systemd session which I believe are created by a potential race where
systemd is reloading unit files and at the same time a user is
connecting to the system via ssh or is executing the su command.
The simple reproducer
$ for i in {1..100}; do sleep 0.2; ssh localhost sudo systemctl
daemon-reload & ssh localhost sleep 1 & done
Wait > 1 second
$ jobs -p | xargs --verbose --no-run-if-empty kill -KILL
To clean out STOPPED jobs and
$ systemctl status --all 2> /dev/null | grep --before-context 3
abandoned
will produce something similar to
│ ├─ 175 su - ubuntu
│ ├─ 178 -su
│ ├─62375 systemctl status --all
│ └─62376 grep --color=auto --before-context 3 abandoned
--
● session-273.scope - Session 273 of user ubuntu
Loaded: loaded (/run/systemd/transient/session-273.scope; transient)
Transient: yes
Active: active (abandoned) since Wed 2021-06-30 13:32:03 UTC; 4min 7s ago
--
● session-274.scope - Session 274 of user ubuntu
Loaded: loaded (/run/systemd/transient/session-274.scope; transient)
Transient: yes
Active: active (abandoned) since Wed 2021-06-30 13:32:03 UTC; 4min 7s ago
--
● session-30.scope - Session 30 of user ubuntu
Loaded: loaded (/run/systemd/transient/session-30.scope; transient)
Transient: yes
Active: active (abandoned) since Wed 2021-06-30 10:05:56 UTC; 3h 30min ago
--
● session-302.scope - Session 302 of user ubuntu
Loaded: loaded (/run/systemd/transient/session-302.scope; transient)
Transient: yes
Active: active (abandoned) since Wed 2021-06-30 13:32:04 UTC; 4min 6s ago
--
│ ├─ 175 su - ubuntu
│ ├─ 178 -su
│ ├─62375 systemctl status --all
│ └─62376 grep --color=auto --before-context 3 abandoned
The system in question is running Bionic, systemd-237-3ubuntu10.48
To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1934147/+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 1905493] Re: cloud-init status --wait hangs indefinitely in a nested lxd container
FWIW I know what the snapd issue is, the issue is that snapd does not and will not work in a nested LXD container, we need to add code to make snapd.seeded.service die/exit gracefully in this situation. ** Also affects: snapd Importance: Undecided Status: New ** Changed in: snapd Status: New => Confirmed ** Changed in: snapd Importance: Undecided => Low -- 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/1905493 Title: cloud-init status --wait hangs indefinitely in a nested lxd container Status in cloud-init: Invalid Status in snapd: Confirmed Status in dbus package in Ubuntu: New Status in systemd package in Ubuntu: Invalid Bug description: When booting a nested lxd container inside another lxd container (just a normal container, not a VM) (i.e. just L2), using cloud-init -status --wait, the "." is just printed off infinitely and never returns. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1905493/+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 1878969] Re: time-epoch never changes in SRUs
Is there any timeline on when this will be considered for SRU'ing back
to focal so it is usable in i.e. UC20?
--
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/1878969
Title:
time-epoch never changes in SRUs
Status in ubuntu-core-initramfs:
New
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Xenial:
New
Status in systemd source package in Bionic:
New
Status in systemd source package in Focal:
New
Bug description:
[Impact]
* Systems without hwclock come up with a fixed time epoch which is not
updated in SRUs
* Ideally booting with a newer built of systemd should move time epoch to be
at least when systemd was last built. For example to the value of
SOURCE_DATE_EPOCH.
[Test Case]
* Boot without network NTP or hwclock
* Observe that the epoch is the same as the time when NEWS entry in the
systemd source code was last touched.
* Boot newer update of systemd, observe that the time epoch is at least 2020
[Regression Potential]
* Bad epoch, may result in unable to perform TLS connections,
validated GPG signatures, and snapd assertions. Changing epoch to be
more recent is desired. Some machines may rely on the fact that
"bionic" without hwclock always comes up in year 2018. But in practice
that is incorrect thing to do.
[Other Info]
* By default
option('time-epoch', type : 'integer', value : '-1',
description : 'time epoch for time clients')
in systemd is set to the modification time of the NEW entry
time_epoch = run_command(stat, '-c', '%Y', NEWS).stdout().to_int()
If available, it should be set to SOURCE_DATE_EPOCH=1585051767 value
to be compliant with the https://reproducible-
builds.org/docs/timestamps/ specification.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-core-initramfs/+bug/1878969/+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 1850667] Re: cgroup v2 is not fully supported yet, proceeding with partial confinement
** Also affects: snapd Importance: Undecided Status: New ** Changed in: snapd Status: New => Confirmed ** Changed in: snapd Importance: Undecided => High ** Changed in: snapd Assignee: (unassigned) => Maciej Borzecki (maciek-borzecki) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1850667 Title: cgroup v2 is not fully supported yet, proceeding with partial confinement Status in snapd: Confirmed Status in docker.io package in Ubuntu: Confirmed Status in lxc package in Ubuntu: Fix Released Status in lxcfs package in Ubuntu: Fix Released Status in lxd package in Ubuntu: Fix Released Status in snapd package in Ubuntu: In Progress Bug description: Systemd upstream switched the default cgroup hierarchy to unified with v243. This change is reverted by the Ubuntu systemd packages, but as unified is the way to go per upstream support should be added to all relevant Ubuntu packges (and snaps): https://github.com/systemd/systemd/blob/v243/NEWS#L56 * systemd now defaults to the "unified" cgroup hierarchy setup during build-time, i.e. -Ddefault-hierarchy=unified is now the build-time default. Previously, -Ddefault-hierarchy=hybrid was the default. This change reflects the fact that cgroupsv2 support has matured substantially in both systemd and in the kernel, and is clearly the way forward. Downstream production distributions might want to continue to use -Ddefault-hierarchy=hybrid (or even =legacy) for their builds as unfortunately the popular container managers have not caught up with the kernel API changes. Systemd is rebuilt using the new default and is available from the following PPA for testing: https://launchpad.net/~rbalint/+archive/ubuntu/systemd-unified-cgh The autopkgtest results against other packges are available here: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified-cgh/?format=plain https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-focal-rbalint-systemd-unified-cgh/?format=plain lxc autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/d/docker.io/20191030_155944_2331e@/log.gz snapd autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/s/snapd/20191030_161354_94b26@/log.gz docker.io autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/d/docker.io/20191030_155944_2331e@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1850667/+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 1902748] Re: ubuntu-seed / ubuntu-boot partition detection could be improved
** Tags added: uc20 -- 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/1902748 Title: ubuntu-seed / ubuntu-boot partition detection could be improved Status in snapd: Confirmed Status in linux package in Ubuntu: Incomplete Status in systemd package in Ubuntu: New Bug description: ubuntu-seed / ubuntu-boot partition detection could be improved Currently in the initrd, snapd-bootstrap searches for ubuntu-boot / ubuntu-seed partition by label or by UEFI variable that was set by sd- boot. sdboot uses devicepath UEFI protocol to establish MEDIA_DEVICE_PATH, HARDDRIVE_DEVICEPATH, GUID, Signature aka partuuid that was used to boot. https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/DevicePath.h This is nice, but not unique enough. It would be nice if we were able to modify sd-boot stub to export something more specific that ideally maps to a sysfs path. For example PCI_DEVICE_PATH, SCSI_DEVICE_PATH, SATA_DEVICE_PATH, USB_DEVICE_PATH, NVME_NAMESPACE_DEVICE_PATH, SD_DEVICE_PATH, UFS_DEVICE_PATH, EMMC_DEVICE_PATH or some such. That way initrd would be able to resolve better which block device to key off. Given that EFI device handle is passed to the kernel, doesn't kernel also know where it came from? or not? To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1902748/+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 1902748] Re: ubuntu-seed / ubuntu-boot partition detection could be improved
** Changed in: snapd Status: New => Confirmed ** Changed in: snapd Importance: Undecided => Medium ** Changed in: snapd Assignee: (unassigned) => Ian Johnson (anonymouse67) -- 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/1902748 Title: ubuntu-seed / ubuntu-boot partition detection could be improved Status in snapd: Confirmed Status in linux package in Ubuntu: Incomplete Status in systemd package in Ubuntu: New Bug description: ubuntu-seed / ubuntu-boot partition detection could be improved Currently in the initrd, snapd-bootstrap searches for ubuntu-boot / ubuntu-seed partition by label or by UEFI variable that was set by sd- boot. sdboot uses devicepath UEFI protocol to establish MEDIA_DEVICE_PATH, HARDDRIVE_DEVICEPATH, GUID, Signature aka partuuid that was used to boot. https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/DevicePath.h This is nice, but not unique enough. It would be nice if we were able to modify sd-boot stub to export something more specific that ideally maps to a sysfs path. For example PCI_DEVICE_PATH, SCSI_DEVICE_PATH, SATA_DEVICE_PATH, USB_DEVICE_PATH, NVME_NAMESPACE_DEVICE_PATH, SD_DEVICE_PATH, UFS_DEVICE_PATH, EMMC_DEVICE_PATH or some such. That way initrd would be able to resolve better which block device to key off. Given that EFI device handle is passed to the kernel, doesn't kernel also know where it came from? or not? To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1902748/+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 1895144] Re: ubuntu-server CET gap analysis
** Changed in: snapd (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to klibc in Ubuntu. https://bugs.launchpad.net/bugs/1895144 Title: ubuntu-server CET gap analysis Status in golang-defaults package in Ubuntu: New Status in klibc package in Ubuntu: New Status in libunwind package in Ubuntu: New Status in linux package in Ubuntu: Incomplete Status in snapd package in Ubuntu: Confirmed Status in ubuntu-meta package in Ubuntu: New Bug description: * linux lacks CET, not upstream yet * snapd lacks CET, as golang has no support for CET yet * libunwind lacks CET, as no upstream support yet * klibc lacks CET, no upstream support yet To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/golang-defaults/+bug/1895144/+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 1896115] [NEW] uc20 initramfs busybox missing less applet
Public bug reported: the version of busybox in the initramfs of uc20, which derives from ubuntu 20.04, does not have the less module/applet built into it, so there is no less command available in the initramfs on uc20. This is unfortunate as sometimes when debugging problems in the initramfs it is useful to read large files, etc. using something like less. ** Affects: busybox (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to busybox in Ubuntu. https://bugs.launchpad.net/bugs/1896115 Title: uc20 initramfs busybox missing less applet Status in busybox package in Ubuntu: New Bug description: the version of busybox in the initramfs of uc20, which derives from ubuntu 20.04, does not have the less module/applet built into it, so there is no less command available in the initramfs on uc20. This is unfortunate as sometimes when debugging problems in the initramfs it is useful to read large files, etc. using something like less. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/1896115/+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 1861177] Re: seccomp_rule_add is very slow
I can't seem to assign this bug to Dimitri, but as per https://github.com/snapcore/core20/issues/48, Dimitri should be preparing a libseccomp 2.4.2 SRU. ** Bug watch added: github.com/snapcore/core20/issues #48 https://github.com/snapcore/core20/issues/48 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1861177 Title: seccomp_rule_add is very slow Status in snapd: Triaged Status in libseccomp package in Ubuntu: Triaged Bug description: There is a known and patched issue with version 2.4 of libseccomp where certain operations have a large performance regression. This is causing some packages that use libseccomp such as container orchestration systems to occasionally time out or otherwise fail under certain workloads. Please consider porting the patch into the various Ubuntu versions that have version 2.4 of libseccomp and into the backports. The performance patch from version 2.5 (yet to be released) applies cleanly on top of the 2.4 branch of libseccomp. For more information, and for a copy of the patch (which can also be cherry picked from the upstream libseccomp repos) see the similar Debian issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943913 To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1861177/+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 1861177] Re: seccomp_rule_add is very slow
I'll take a look at measuring this with snapd $SOON ** Changed in: snapd Assignee: (unassigned) => Ian Johnson (anonymouse67) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1861177 Title: seccomp_rule_add is very slow Status in snapd: Triaged Status in libseccomp package in Ubuntu: Triaged Bug description: There is a known and patched issue with version 2.4 of libseccomp where certain operations have a large performance regression. This is causing some packages that use libseccomp such as container orchestration systems to occasionally time out or otherwise fail under certain workloads. Please consider porting the patch into the various Ubuntu versions that have version 2.4 of libseccomp and into the backports. The performance patch from version 2.5 (yet to be released) applies cleanly on top of the 2.4 branch of libseccomp. For more information, and for a copy of the patch (which can also be cherry picked from the upstream libseccomp repos) see the similar Debian issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943913 To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1861177/+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 1413410] Re: Unable to match embedded NULLs in unix bind rule for abstract sockets
Jamie, is this still an issue? I'm inclined to close this since the
apparmor bug seems to have been released a long time ago.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1413410
Title:
Unable to match embedded NULLs in unix bind rule for abstract sockets
Status in AppArmor:
Fix Released
Status in AppArmor 2.9 series:
In Progress
Status in Snappy:
Incomplete
Status in apparmor package in Ubuntu:
Fix Released
Bug description:
On Ubuntu 14.10, I had this in my logs:
Jan 21 16:32:30 localhost kernel: [24900.927939] audit: type=1400
audit(1421879550.441:534): apparmor="DENIED" operation="bind"
profile="/usr/lib/firefox/firefox{,*[^s][^h]}" pid=12356 comm="plugin-containe"
family="unix" sock_type="dgram" protocol=0 requested_mask="bind"
denied_mask="bind"
addr="@676F6F676C652D6E61636C2D6F316431323335362D33393100"
$ aa-decode
676F6F676C652D6E61636C2D6F316431323335362D33393100
Decoded: google-nacl-o1d12356-391
$ aa-decode 676F6F676C652D6E61636C2D6
Decoded: google-nacl-`
So I tried the following:
unix bind type=dgram addr=@google-nacl*,
unix bind type=dgram addr="@google-nacl*",
unix bind type=dgram addr=@676F6F676C652D6E61636C2D6*,
unix bind type=dgram addr="@676F6F676C652D6E61636C2D6*",
unix bind type=dgram addr=@google-nacl*\\000*,
unix bind type=dgram
addr=@google-nacl*[0-9a-zA-Z]\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000{,\\000,\\000\\000},
but none of them match. The best I could do was:
unix bind type=dgram,
This is likely going to be important for snappy since snappy will have the
concept of different coordinating snaps interacting via abstract sockets. What
is interesting is that this seems to work ok for some things, eg:
./lightdm: unix (bind, listen) type=stream
addr="@/com/ubuntu/upstart-session/**",
./lightdm: unix (bind, listen) type=stream addr="@/tmp/dbus-*",
./lightdm: unix (bind, listen) type=stream addr="@/tmp/.ICE-unix/[0-9]*",
./lightdm: unix (bind, listen) type=stream addr="@/dbus-vfs-daemon/*",
./lightdm: unix (bind, listen) type=stream addr="@guest*",
Is this something in how firefox is setting up the socket?
To reproduce, enable the firefox profile, start firefox and try to
attend a google hangout.
To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1413410/+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 1571531] Re: cupsd cause apparmor denials for /etc/ld.so.preload
I don't think we have such a capability right now in snapd. If you locally modify the snap-confine profile, it will be rewritten on at least core refreshes (and reboots as well if I'm not mistaken), so it sounds like we need some mechanism to specify additional rules to be included in the snap-confine profile. ** Changed in: snapd (Ubuntu) Status: New => Triaged ** Changed in: snapd (Ubuntu) Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1571531 Title: cupsd cause apparmor denials for /etc/ld.so.preload Status in apparmor package in Ubuntu: New Status in snapd package in Ubuntu: Triaged Bug description: There is a constant flood of messages in dmesg: [ 4431.638163] audit: type=1400 audit(1460962510.272:60): apparmor="DENIED" operation="open" profile="/usr/sbin/cupsd" name="/etc/ld.so.preload" pid=10559 comm="cupsd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [ 4431.661208] audit: type=1400 audit(1460962510.296:61): apparmor="DENIED" operation="open" profile="/usr/sbin/cupsd" name="/etc/ld.so.preload" pid=10564 comm="cups-exec" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [ 4431.661390] audit: type=1400 audit(1460962510.296:62): apparmor="DENIED" operation="open" profile="/usr/sbin/cupsd" name="/etc/ld.so.preload" pid=10565 comm="cups-exec" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [ 4431.661759] audit: type=1400 audit(1460962510.296:63): apparmor="DENIED" operation="open" profile="/usr/sbin/cupsd" name="/etc/ld.so.preload" pid=10564 comm="dbus" requested_mask="r" denied_mask="r" fsuid=7 ouid=0 [ 4431.661936] audit: type=1400 audit(1460962510.296:64): apparmor="DENIED" operation="open" profile="/usr/sbin/cupsd" name="/etc/ld.so.preload" pid=10566 comm="cups-exec" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [ 4431.661937] audit: type=1400 audit(1460962510.296:65): apparmor="DENIED" operation="open" profile="/usr/sbin/cupsd" name="/etc/ld.so.preload" pid=10565 comm="dbus" requested_mask="r" denied_mask="r" fsuid=7 ouid=0 [ 4431.662534] audit: type=1400 audit(1460962510.296:66): apparmor="DENIED" operation="open" profile="/usr/sbin/cupsd" name="/etc/ld.so.preload" pid=10566 comm="dbus" requested_mask="r" denied_mask="r" fsuid=7 ouid=0 [ 5081.410342] audit: type=1400 audit(1460963160.033:67): apparmor="DENIED" operation="open" profile="/usr/sbin/cupsd" name="/etc/ld.so.preload" pid=10810 comm="cupsd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [ 5081.446507] audit: type=1400 audit(1460963160.069:68): apparmor="DENIED" operation="open" profile="/usr/sbin/cupsd" name="/etc/ld.so.preload" pid=10815 comm="cups-exec" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: cups-daemon 2.1.3-4 ProcVersionSignature: Ubuntu 4.4.0-18.34-generic 4.4.6 Uname: Linux 4.4.0-18-generic x86_64 ApportVersion: 2.20.1-0ubuntu2 Architecture: amd64 CupsErrorLog: CurrentDesktop: X-Cinnamon Date: Mon Apr 18 10:56:37 2016 EcryptfsInUse: Yes InstallationDate: Installed on 2013-07-19 (1003 days ago) InstallationMedia: Xubuntu 13.04 "Raring Ringtail" - Release i386 (20130423.1) Lpstat: device for Generic-PCL-5e: socket://192.168.1.100:9100 MachineType: LENOVO 4298R86 Papersize: a4 PpdFiles: Error: command ['fgrep', '-H', '*NickName', '/etc/cups/ppd/Generic-PCL-5e.ppd'] failed with exit code 2: grep: /etc/cups/ppd/Generic-PCL-5e.ppd: Permission denied ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-18-generic root=UUID=3d4ce850-6e8a-4cf5-9b82-fb135c22fe1e ro SourcePackage: cups UpgradeStatus: Upgraded to xenial on 2015-10-29 (171 days ago) dmi.bios.date: 12/01/2011 dmi.bios.vendor: LENOVO dmi.bios.version: 8DET56WW (1.26 ) dmi.board.asset.tag: Not Available dmi.board.name: 4298R86 dmi.board.vendor: LENOVO dmi.board.version: Not Available dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:bvr8DET56WW(1.26):bd12/01/2011:svnLENOVO:pn4298R86:pvrThinkPadX220Tablet:rvnLENOVO:rn4298R86:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.name: 4298R86 dmi.product.version: ThinkPad X220 Tablet dmi.sys.vendor: LENOVO modified.conffile..etc.default.cups: # Cups configure options # LOAD_LP_MODULE: enable/disable to load "lp" parallel printer driver module # LOAD_LP_MODULE has migrated to /etc/modules-load.d/cups-filters.conf # LOAD_LP_MODULE=yes mtime.conffile..etc.default.cups: 2014-03-12T15:11:15.740184 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1571531/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : http
[Touch-packages] [Bug 1375405] Re: Impossible download speed
I've seen this inside an Ubuntu 18.04 lxd container with a poor internet connection as well. apt is version 1.6.11. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1375405 Title: Impossible download speed Status in apt package in Ubuntu: Confirmed Bug description: Here's my problem: Sometimes the download speed is something impossible like 3000 PB/s (3 thousand petabytes a second). And it kind of annoys me because I don't how long the download's actually going to take. I'm in Ubuntu 14.04.1 LTS I'm using apt version 1.0.1ubuntu2.4.1 I'm sorry if the details aren't detailed enough. Just let me know To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1375405/+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 1835585] Re: Xorg doesn't remember monitor settings/layout
On the same system on a different disk I have Ubuntu 18.04 Desktop installed which does not have this issue. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1835585 Title: Xorg doesn't remember monitor settings/layout Status in xorg package in Ubuntu: New Bug description: I'm not sure if this is an Xorg issue or something else, but basically I have enabled fractional scaling in my Disco Dingo install and upon rebooting the scaling and the layout of the monitors is forgotten. I have 2 identical Samsung monitors + 1 LG monitor where the LG and 1 of the Samsung monitors are connected via DisplayPort and the 2nd Samsung monitor is connected over HDMI. My GPU is an NVIDIA Titan X (Maxwell architecture) and I am using the recommended nvidia-driver-418 package. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: xorg 1:7.7+19ubuntu12 ProcVersionSignature: Ubuntu 5.0.0-20.21-generic 5.0.8 Uname: Linux 5.0.0-20-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia .proc.driver.nvidia.gpus..43.00.0: Error: [Errno 21] Is a directory: '/proc/driver/nvidia/gpus/:43:00.0' .proc.driver.nvidia.registry: Binary: "" .proc.driver.nvidia.version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 418.56 Fri Mar 15 12:59:26 CDT 2019 GCC version: gcc version 8.3.0 (Ubuntu 8.3.0-6ubuntu1) ApportVersion: 2.20.10-0ubuntu27 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Fri Jul 5 17:59:17 2019 DistUpgraded: Fresh install DistroCodename: disco DistroVariant: ubuntu DkmsStatus: nvidia, 418.56, 5.0.0-13-generic, x86_64: installed nvidia, 418.56, 5.0.0-20-generic, x86_64: installed ExtraDebuggingInterest: Yes GraphicsCard: NVIDIA Corporation GM200 [GeForce GTX TITAN X] [10de:17c2] (rev a1) (prog-if 00 [VGA controller]) Subsystem: NVIDIA Corporation GM200 [GeForce GTX TITAN X] [10de:1132] InstallationDate: Installed on 2019-07-05 (0 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) MachineType: To Be Filled By O.E.M. To Be Filled By O.E.M. ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-20-generic root=UUID=7dcb76c1-97b7-4439-8265-5ab83b155f51 ro quiet splash vt.handoff=1 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/24/2018 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: P3.50 dmi.board.name: X399 Taichi dmi.board.vendor: ASRock dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrP3.50:bd12/24/2018:svnToBeFilledByO.E.M.:pnToBeFilledByO.E.M.:pvrToBeFilledByO.E.M.:rvnASRock:rnX399Taichi:rvr:cvnDefaultstring:ct3:cvrDefaultstring: dmi.product.family: To Be Filled By O.E.M. dmi.product.name: To Be Filled By O.E.M. dmi.product.sku: To Be Filled By O.E.M. dmi.product.version: To Be Filled By O.E.M. dmi.sys.vendor: To Be Filled By O.E.M. version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.97-1ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.2-1ubuntu1.1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.nvidia-graphics-drivers: nvidia-graphics-drivers-* N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.4-1ubuntu3 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.0.1-0ubuntu1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20180925-2 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1835585/+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 1835585] [NEW] Xorg doesn't remember monitor settings/layout
Public bug reported: I'm not sure if this is an Xorg issue or something else, but basically I have enabled fractional scaling in my Disco Dingo install and upon rebooting the scaling and the layout of the monitors is forgotten. I have 2 identical Samsung monitors + 1 LG monitor where the LG and 1 of the Samsung monitors are connected via DisplayPort and the 2nd Samsung monitor is connected over HDMI. My GPU is an NVIDIA Titan X (Maxwell architecture) and I am using the recommended nvidia-driver-418 package. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: xorg 1:7.7+19ubuntu12 ProcVersionSignature: Ubuntu 5.0.0-20.21-generic 5.0.8 Uname: Linux 5.0.0-20-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia .proc.driver.nvidia.gpus..43.00.0: Error: [Errno 21] Is a directory: '/proc/driver/nvidia/gpus/:43:00.0' .proc.driver.nvidia.registry: Binary: "" .proc.driver.nvidia.version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 418.56 Fri Mar 15 12:59:26 CDT 2019 GCC version: gcc version 8.3.0 (Ubuntu 8.3.0-6ubuntu1) ApportVersion: 2.20.10-0ubuntu27 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Fri Jul 5 17:59:17 2019 DistUpgraded: Fresh install DistroCodename: disco DistroVariant: ubuntu DkmsStatus: nvidia, 418.56, 5.0.0-13-generic, x86_64: installed nvidia, 418.56, 5.0.0-20-generic, x86_64: installed ExtraDebuggingInterest: Yes GraphicsCard: NVIDIA Corporation GM200 [GeForce GTX TITAN X] [10de:17c2] (rev a1) (prog-if 00 [VGA controller]) Subsystem: NVIDIA Corporation GM200 [GeForce GTX TITAN X] [10de:1132] InstallationDate: Installed on 2019-07-05 (0 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) MachineType: To Be Filled By O.E.M. To Be Filled By O.E.M. ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-20-generic root=UUID=7dcb76c1-97b7-4439-8265-5ab83b155f51 ro quiet splash vt.handoff=1 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/24/2018 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: P3.50 dmi.board.name: X399 Taichi dmi.board.vendor: ASRock dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrP3.50:bd12/24/2018:svnToBeFilledByO.E.M.:pnToBeFilledByO.E.M.:pvrToBeFilledByO.E.M.:rvnASRock:rnX399Taichi:rvr:cvnDefaultstring:ct3:cvrDefaultstring: dmi.product.family: To Be Filled By O.E.M. dmi.product.name: To Be Filled By O.E.M. dmi.product.sku: To Be Filled By O.E.M. dmi.product.version: To Be Filled By O.E.M. dmi.sys.vendor: To Be Filled By O.E.M. version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.97-1ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.2-1ubuntu1.1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.nvidia-graphics-drivers: nvidia-graphics-drivers-* N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.4-1ubuntu3 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.0.1-0ubuntu1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20180925-2 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 ** Affects: xorg (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug disco resolution ubuntu -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1835585 Title: Xorg doesn't remember monitor settings/layout Status in xorg package in Ubuntu: New Bug description: I'm not sure if this is an Xorg issue or something else, but basically I have enabled fractional scaling in my Disco Dingo install and upon rebooting the scaling and the layout of the monitors is forgotten. I have 2 identical Samsung monitors + 1 LG monitor where the LG and 1 of the Samsung monitors are connected via DisplayPort and the 2nd Samsung monitor is connected over HDMI. My GPU is an NVIDIA Titan X (Maxwell architecture) and I am using the recommended nvidia-driver-418 package. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: xorg 1:7.7+19ubuntu12 ProcVersionSignature: Ubuntu 5.0.0-20.21-generic 5.0.8 Uname: Linux 5.0.0-20-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia .proc.driver.nvidia.gpus..43.00.0: Error: [Errno 21] Is a directory: '/proc/driver/nvidia/gpus/:43:00.0' .proc.driver.nvidia.registry: Binary: "" .proc.driver.nvidia.version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 418.56 Fri Mar 15 12:59:26 CDT 2019 GCC version: gcc version 8.3.0 (Ubuntu 8.3.0-6ubuntu1) ApportVersion: 2.20.10-0ubuntu27 A
[Touch-packages] [Bug 1830502] Re: apparmor uses excessive memory leading to oom kill
** Summary changed: - apparmor fails to start with no parser errors + apparmor uses excessive memory leading to oom kill ** Description changed: + When attempting to load the profile from comment #7, apparmor uses + excessive amounts of memory leading to being killed by the OOM killer + and thus the apparmor.service failing. + + Original bug description: + On Ubuntu 18.04.2 LTS Desktop, after running out of space on my disk, my system was unable to finish booting and I had to go into recovery mode and remove a number of files before the system would boot. After doing so I discovered that now the apparmor.service systemd unit always fails to start. I see this in dmesg: [ 1066.975360] Out of memory: Kill process 6799 (apparmor_parser) score 796 or sacrifice child [ 1066.975364] Killed process 6799 (apparmor_parser) total-vm:15057348kB, anon-rss:15046148kB, file-rss:0kB, shmem-rss:0kB [ 1067.406595] oom_reaper: reaped process 6799 (apparmor_parser), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB Whenever apparmor.service is attempted to be started by systemd, i.e. either on boot, or later with `systemctl start apparmor`. The log from journalctl doesn't show any actual issues with any profiles just this: -- Reboot -- May 25 17:00:58 systemd[1]: Starting AppArmor initialization... May 25 17:00:58 apparmor[1521]: * Starting AppArmor profiles May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd May 25 17:01:40 apparmor[1521]:...fail! May 25 17:01:40 systemd[1]: apparmor.service: Main process exited, code=exited, status=123/n/a May 25 17:01:40 systemd[1]: apparmor.service: Failed with result 'exit-code'. May 25 17:01:40 systemd[1]: Failed to start AppArmor initialization. May 25 17:04:53 systemd[1]: Starting AppArmor initialization... May 25 17:04:53 apparmor[4747]: * Starting AppArmor profiles May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd May 25 17:05:25 apparmor[4747]:...fail! May 25 17:05:25 systemd[1]: apparmor.service: Main process exited, code=exited, status=123/n/a May 25 17:05:25 systemd[1]: apparmor.service: Failed with result 'exit-code'. May 25 17:05:25 systemd[1]: Failed to start AppArmor initialization. I can see that apparmor profiles are active after doing this (using aa- status), but it's still troubling that apparmor runs into an issue without actually saying what the error is. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1830502 Title: apparmor uses excessive memory leading to oom kill Status in apparmor package in Ubuntu: New Bug description: When attempting to load the profile from comment #7, apparmor uses excessive amounts of memory leading to being killed by the OOM killer and thus the apparmor.service failing. Original bug description: On Ubuntu 18.04.2 LTS Desktop, after running out of space on my disk, my system was unable to finish booting and I had to go into recovery mode and remove a number of files before the system would boot. After doing so I discovered that now the apparmor.service systemd unit always fails to start. I see this in dmesg: [ 1066.975360] Out of memory: Kill process 6799 (apparmor_parser) score 796 or sacrifice child [ 1066.975364] Killed process 6799 (apparmor_parser) total-vm:15057348kB, anon-rss:15046148kB, file-rss:0kB, shmem-rss:0kB [ 1067.406595] oom_reaper: reaped process 6799 (apparmor_parser), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB Whenever apparmor.service is attempted to be started by systemd, i.e. either on boot, or later with `systemctl start apparmor`. The log from journalctl doesn't show any actual issues with any profiles just this: -- Reboot -- May 25 17:00:58 systemd[1]: Starting AppArmor initialization... May 25 17:00:58 apparmor[1521]: * Starting AppArmor profiles May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd May 25 17:01:40 apparmor[1521]:...fail! May 25 17:01:40 systemd[1]: apparmor.service: Main process exited, code=exited, status=123/n/a May 25 17:01:40 systemd[1]: apparmor.service: Failed with result 'exit-code'. May 25 17:01:40 systemd[1]: Failed to start AppArmor initialization. May 25 17:04:53 systemd[1]: Starting AppArmor initialization... May 25 17:04:53 apparmor[4747]: * Starting AppArmor profiles May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox May 25 17:04:53 apparm
[Touch-packages] [Bug 1830502] Re: apparmor fails to start with no parser errors
@Jamie yes this was generated by snapd, the original snapcraft.yaml is attached. And also yes I fully understand this was an atypical usage of layouts, I was experimenting with using layouts to make it seem to a snap application that an additional package was installed in the base snap. I generated the yaml section using a bit of code that I seem to have lost now, but the gist of it was to find all files in a given deb package (python2.7 in this case) and create a layout symlink for every file to point to the real files underneath $SNAP. I actually remember abandoning this originally specifically because apparmor crashed when attempting to install the snap and forgot to file a bug here, so here's the bug finally... ** Attachment added: "snapcraft.yaml" https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1830502/+attachment/5267473/+files/snapcraft.yaml -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1830502 Title: apparmor fails to start with no parser errors Status in apparmor package in Ubuntu: New Bug description: On Ubuntu 18.04.2 LTS Desktop, after running out of space on my disk, my system was unable to finish booting and I had to go into recovery mode and remove a number of files before the system would boot. After doing so I discovered that now the apparmor.service systemd unit always fails to start. I see this in dmesg: [ 1066.975360] Out of memory: Kill process 6799 (apparmor_parser) score 796 or sacrifice child [ 1066.975364] Killed process 6799 (apparmor_parser) total-vm:15057348kB, anon-rss:15046148kB, file-rss:0kB, shmem-rss:0kB [ 1067.406595] oom_reaper: reaped process 6799 (apparmor_parser), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB Whenever apparmor.service is attempted to be started by systemd, i.e. either on boot, or later with `systemctl start apparmor`. The log from journalctl doesn't show any actual issues with any profiles just this: -- Reboot -- May 25 17:00:58 systemd[1]: Starting AppArmor initialization... May 25 17:00:58 apparmor[1521]: * Starting AppArmor profiles May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd May 25 17:01:40 apparmor[1521]:...fail! May 25 17:01:40 systemd[1]: apparmor.service: Main process exited, code=exited, status=123/n/a May 25 17:01:40 systemd[1]: apparmor.service: Failed with result 'exit-code'. May 25 17:01:40 systemd[1]: Failed to start AppArmor initialization. May 25 17:04:53 systemd[1]: Starting AppArmor initialization... May 25 17:04:53 apparmor[4747]: * Starting AppArmor profiles May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd May 25 17:05:25 apparmor[4747]:...fail! May 25 17:05:25 systemd[1]: apparmor.service: Main process exited, code=exited, status=123/n/a May 25 17:05:25 systemd[1]: apparmor.service: Failed with result 'exit-code'. May 25 17:05:25 systemd[1]: Failed to start AppArmor initialization. I can see that apparmor profiles are active after doing this (using aa-status), but it's still troubling that apparmor runs into an issue without actually saying what the error is. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1830502/+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 1830502] Re: apparmor fails to start with no parser errors
Yes, certainly use the profile for whatever you can use it for. Would you like me to edit the description on this bug to reflect the actual underlying cause here or should I just close this and file a new bug for the memory usage of this profile? I'm no expert here but I think 15.4 GB memory usage seems a tad high and thus seems buggy :-) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1830502 Title: apparmor fails to start with no parser errors Status in apparmor package in Ubuntu: New Bug description: On Ubuntu 18.04.2 LTS Desktop, after running out of space on my disk, my system was unable to finish booting and I had to go into recovery mode and remove a number of files before the system would boot. After doing so I discovered that now the apparmor.service systemd unit always fails to start. I see this in dmesg: [ 1066.975360] Out of memory: Kill process 6799 (apparmor_parser) score 796 or sacrifice child [ 1066.975364] Killed process 6799 (apparmor_parser) total-vm:15057348kB, anon-rss:15046148kB, file-rss:0kB, shmem-rss:0kB [ 1067.406595] oom_reaper: reaped process 6799 (apparmor_parser), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB Whenever apparmor.service is attempted to be started by systemd, i.e. either on boot, or later with `systemctl start apparmor`. The log from journalctl doesn't show any actual issues with any profiles just this: -- Reboot -- May 25 17:00:58 systemd[1]: Starting AppArmor initialization... May 25 17:00:58 apparmor[1521]: * Starting AppArmor profiles May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd May 25 17:01:40 apparmor[1521]:...fail! May 25 17:01:40 systemd[1]: apparmor.service: Main process exited, code=exited, status=123/n/a May 25 17:01:40 systemd[1]: apparmor.service: Failed with result 'exit-code'. May 25 17:01:40 systemd[1]: Failed to start AppArmor initialization. May 25 17:04:53 systemd[1]: Starting AppArmor initialization... May 25 17:04:53 apparmor[4747]: * Starting AppArmor profiles May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd May 25 17:05:25 apparmor[4747]:...fail! May 25 17:05:25 systemd[1]: apparmor.service: Main process exited, code=exited, status=123/n/a May 25 17:05:25 systemd[1]: apparmor.service: Failed with result 'exit-code'. May 25 17:05:25 systemd[1]: Failed to start AppArmor initialization. I can see that apparmor profiles are active after doing this (using aa-status), but it's still troubling that apparmor runs into an issue without actually saying what the error is. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1830502/+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 1830502] Re: apparmor fails to start with no parser errors
Ah actually, if I move that profile out of the way, then `systemctl start apparmor` starts immediately. So the issue must be with that profile being too large (and indeed it is 4-5 MB). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1830502 Title: apparmor fails to start with no parser errors Status in apparmor package in Ubuntu: New Bug description: On Ubuntu 18.04.2 LTS Desktop, after running out of space on my disk, my system was unable to finish booting and I had to go into recovery mode and remove a number of files before the system would boot. After doing so I discovered that now the apparmor.service systemd unit always fails to start. I see this in dmesg: [ 1066.975360] Out of memory: Kill process 6799 (apparmor_parser) score 796 or sacrifice child [ 1066.975364] Killed process 6799 (apparmor_parser) total-vm:15057348kB, anon-rss:15046148kB, file-rss:0kB, shmem-rss:0kB [ 1067.406595] oom_reaper: reaped process 6799 (apparmor_parser), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB Whenever apparmor.service is attempted to be started by systemd, i.e. either on boot, or later with `systemctl start apparmor`. The log from journalctl doesn't show any actual issues with any profiles just this: -- Reboot -- May 25 17:00:58 systemd[1]: Starting AppArmor initialization... May 25 17:00:58 apparmor[1521]: * Starting AppArmor profiles May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd May 25 17:01:40 apparmor[1521]:...fail! May 25 17:01:40 systemd[1]: apparmor.service: Main process exited, code=exited, status=123/n/a May 25 17:01:40 systemd[1]: apparmor.service: Failed with result 'exit-code'. May 25 17:01:40 systemd[1]: Failed to start AppArmor initialization. May 25 17:04:53 systemd[1]: Starting AppArmor initialization... May 25 17:04:53 apparmor[4747]: * Starting AppArmor profiles May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd May 25 17:05:25 apparmor[4747]:...fail! May 25 17:05:25 systemd[1]: apparmor.service: Main process exited, code=exited, status=123/n/a May 25 17:05:25 systemd[1]: apparmor.service: Failed with result 'exit-code'. May 25 17:05:25 systemd[1]: Failed to start AppArmor initialization. I can see that apparmor profiles are active after doing this (using aa-status), but it's still troubling that apparmor runs into an issue without actually saying what the error is. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1830502/+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 1830502] Re: apparmor fails to start with no parser errors
So I ran your snippet to determine which profiles weren't loaded and the
only one which wasn't loaded was:
```
$ sudo cat /sys/kernel/security/apparmor/profiles | awk '{ print $1 }' >
/tmp/foo ; sudo apparmor_parser -N /etc/apparmor.d/
/var/lib/snapd/apparmor/profiles/ >> /tmp/foo ; sort /tmp/foo | uniq -c | grep
-e ' 1 '
Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox
Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd
1 snap-update-ns.layouts-test
```
which is a local snap I was developing quite some time ago. I will
attach the associated apparmor profile that was generated, but
curiously, when I try to load that profile manually with apparmor_parser
it succeeds:
```
$ sudo apparmor_parser -r
/var/lib/snapd/apparmor/profiles/snap-update-ns.layouts-test
$ echo $?
0
```
with the following output in the system journal indicating that the load
was successful:
```
May 29 11:23:22 audit[21275]: AVC apparmor="STATUS" operation="profile_load"
profile="unconfined" name="snap-update-ns.layouts-test" pid=21275
comm="apparmor_parser"
May 29 11:23:22 kernel: audit: type=1400 audit(1559147002.259:420):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="snap-update-ns.layouts-test" pid=21275 comm="apparmor_parser"
May 29 11:23:22 sudo[21273]: pam_unix(sudo:session): session closed for user
root
```
and no kernel messages regarding apparmor_parser being killed from the
OOM killer.
After doing this, then there is not a diff between the expected loaded
profiles and the actual loaded profiles using your snippet, but if I try
again to start apparmor.service it still gets killed by the OOM killer
with similar output as above.
** Attachment added: "layouts-test-1"
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1830502/+attachment/5267420/+files/layouts-test-1
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1830502
Title:
apparmor fails to start with no parser errors
Status in apparmor package in Ubuntu:
New
Bug description:
On Ubuntu 18.04.2 LTS Desktop, after running out of space on my disk,
my system was unable to finish booting and I had to go into recovery
mode and remove a number of files before the system would boot. After
doing so I discovered that now the apparmor.service systemd unit
always fails to start. I see this in dmesg:
[ 1066.975360] Out of memory: Kill process 6799 (apparmor_parser) score 796
or sacrifice child
[ 1066.975364] Killed process 6799 (apparmor_parser) total-vm:15057348kB,
anon-rss:15046148kB, file-rss:0kB, shmem-rss:0kB
[ 1067.406595] oom_reaper: reaped process 6799 (apparmor_parser), now
anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
Whenever apparmor.service is attempted to be started by systemd, i.e.
either on boot, or later with `systemctl start apparmor`.
The log from journalctl doesn't show any actual issues with any
profiles just this:
-- Reboot --
May 25 17:00:58 systemd[1]: Starting AppArmor initialization...
May 25 17:00:58 apparmor[1521]: * Starting AppArmor profiles
May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable:
usr.bin.firefox
May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable:
usr.sbin.rsyslogd
May 25 17:01:40 apparmor[1521]:...fail!
May 25 17:01:40 systemd[1]: apparmor.service: Main process exited,
code=exited, status=123/n/a
May 25 17:01:40 systemd[1]: apparmor.service: Failed with result 'exit-code'.
May 25 17:01:40 systemd[1]: Failed to start AppArmor initialization.
May 25 17:04:53 systemd[1]: Starting AppArmor initialization...
May 25 17:04:53 apparmor[4747]: * Starting AppArmor profiles
May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable:
usr.bin.firefox
May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable:
usr.sbin.rsyslogd
May 25 17:05:25 apparmor[4747]:...fail!
May 25 17:05:25 systemd[1]: apparmor.service: Main process exited,
code=exited, status=123/n/a
May 25 17:05:25 systemd[1]: apparmor.service: Failed with result 'exit-code'.
May 25 17:05:25 systemd[1]: Failed to start AppArmor initialization.
I can see that apparmor profiles are active after doing this (using
aa-status), but it's still troubling that apparmor runs into an issue
without actually saying what the error is.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1830502/+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 1830502] Re: apparmor fails to start with no parser errors
How would you recommend I go about checking which profiles are actually loaded and which profiles are reported as loaded? I have this from aa- status: https://pastebin.ubuntu.com/p/c2FbrndDzs/ -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1830502 Title: apparmor fails to start with no parser errors Status in apparmor package in Ubuntu: New Bug description: On Ubuntu 18.04.2 LTS Desktop, after running out of space on my disk, my system was unable to finish booting and I had to go into recovery mode and remove a number of files before the system would boot. After doing so I discovered that now the apparmor.service systemd unit always fails to start. I see this in dmesg: [ 1066.975360] Out of memory: Kill process 6799 (apparmor_parser) score 796 or sacrifice child [ 1066.975364] Killed process 6799 (apparmor_parser) total-vm:15057348kB, anon-rss:15046148kB, file-rss:0kB, shmem-rss:0kB [ 1067.406595] oom_reaper: reaped process 6799 (apparmor_parser), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB Whenever apparmor.service is attempted to be started by systemd, i.e. either on boot, or later with `systemctl start apparmor`. The log from journalctl doesn't show any actual issues with any profiles just this: -- Reboot -- May 25 17:00:58 systemd[1]: Starting AppArmor initialization... May 25 17:00:58 apparmor[1521]: * Starting AppArmor profiles May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd May 25 17:01:40 apparmor[1521]:...fail! May 25 17:01:40 systemd[1]: apparmor.service: Main process exited, code=exited, status=123/n/a May 25 17:01:40 systemd[1]: apparmor.service: Failed with result 'exit-code'. May 25 17:01:40 systemd[1]: Failed to start AppArmor initialization. May 25 17:04:53 systemd[1]: Starting AppArmor initialization... May 25 17:04:53 apparmor[4747]: * Starting AppArmor profiles May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd May 25 17:05:25 apparmor[4747]:...fail! May 25 17:05:25 systemd[1]: apparmor.service: Main process exited, code=exited, status=123/n/a May 25 17:05:25 systemd[1]: apparmor.service: Failed with result 'exit-code'. May 25 17:05:25 systemd[1]: Failed to start AppArmor initialization. I can see that apparmor profiles are active after doing this (using aa-status), but it's still troubling that apparmor runs into an issue without actually saying what the error is. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1830502/+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 1830502] Re: apparmor fails to start with no parser errors
Well I tried restarting AppArmor using `systemctl start apparmor` while running `dmesg -w -k` and got the following log: https://pastebin.ubuntu.com/p/98zXMsr6Sy/ I don't see a stack trace for apparmor itself, just for chrome and pulseaudio. Is there anyway to have apparmor.service show what profiles it's trying to load to see what profile it might be trying to load when it is killed? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1830502 Title: apparmor fails to start with no parser errors Status in apparmor package in Ubuntu: New Bug description: On Ubuntu 18.04.2 LTS Desktop, after running out of space on my disk, my system was unable to finish booting and I had to go into recovery mode and remove a number of files before the system would boot. After doing so I discovered that now the apparmor.service systemd unit always fails to start. I see this in dmesg: [ 1066.975360] Out of memory: Kill process 6799 (apparmor_parser) score 796 or sacrifice child [ 1066.975364] Killed process 6799 (apparmor_parser) total-vm:15057348kB, anon-rss:15046148kB, file-rss:0kB, shmem-rss:0kB [ 1067.406595] oom_reaper: reaped process 6799 (apparmor_parser), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB Whenever apparmor.service is attempted to be started by systemd, i.e. either on boot, or later with `systemctl start apparmor`. The log from journalctl doesn't show any actual issues with any profiles just this: -- Reboot -- May 25 17:00:58 systemd[1]: Starting AppArmor initialization... May 25 17:00:58 apparmor[1521]: * Starting AppArmor profiles May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd May 25 17:01:40 apparmor[1521]:...fail! May 25 17:01:40 systemd[1]: apparmor.service: Main process exited, code=exited, status=123/n/a May 25 17:01:40 systemd[1]: apparmor.service: Failed with result 'exit-code'. May 25 17:01:40 systemd[1]: Failed to start AppArmor initialization. May 25 17:04:53 systemd[1]: Starting AppArmor initialization... May 25 17:04:53 apparmor[4747]: * Starting AppArmor profiles May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd May 25 17:05:25 apparmor[4747]:...fail! May 25 17:05:25 systemd[1]: apparmor.service: Main process exited, code=exited, status=123/n/a May 25 17:05:25 systemd[1]: apparmor.service: Failed with result 'exit-code'. May 25 17:05:25 systemd[1]: Failed to start AppArmor initialization. I can see that apparmor profiles are active after doing this (using aa-status), but it's still troubling that apparmor runs into an issue without actually saying what the error is. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1830502/+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 1830502] Re: apparmor fails to start with no parser errors
FWIW this could be a snapd bug, because while my system was unable to boot, I disabled all the snaps I had installed except the core snap, and then after being able to reboot I now re-enable all the snaps and see some warnings: May 25 17:32:16 systemd[1]: Starting AppArmor initialization... May 25 17:32:16 apparmor[21005]: * Starting AppArmor profiles May 25 17:32:16 apparmor[21005]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox May 25 17:32:16 apparmor[21005]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd May 25 17:32:16 apparmor[21005]: Warning from /var/lib/snapd/apparmor/profiles/snap.lxd.benchmark (/var/lib/snapd/apparmor/profiles/snap.lxd.benchmark line 485): Unconfined exec qualifier (ux) allows some dangerous environment variables to be passed to the unconfined process; 'man 5 apparmor.d' for details. May 25 17:32:16 apparmor[21005]: Warning from /var/lib/snapd/apparmor/profiles/snap.lxd.activate (/var/lib/snapd/apparmor/profiles/snap.lxd.activate line 485): Unconfined exec qualifier (ux) allows some dangerous environment variables to be passed to the unconfined process; 'man 5 apparmor.d' for details. May 25 17:32:16 apparmor[21005]: Warning from /var/lib/snapd/apparmor/profiles/snap.lxd.buginfo (/var/lib/snapd/apparmor/profiles/snap.lxd.buginfo line 485): Unconfined exec qualifier (ux) allows some dangerous environment variables to be passed to the unconfined process; 'man 5 apparmor.d' for details. May 25 17:32:16 apparmor[21005]: Warning from /var/lib/snapd/apparmor/profiles/snap.lxd.daemon (/var/lib/snapd/apparmor/profiles/snap.lxd.daemon line 533): Unconfined exec qualifier (ux) allows some dangerous environment variables to be passed to the unconfined process; 'man 5 apparmor.d' for details. May 25 17:32:16 apparmor[21005]: Warning from /var/lib/snapd/apparmor/profiles/snap.lxd.check-kernel (/var/lib/snapd/apparmor/profiles/snap.lxd.check-kernel line 485): Unconfined exec qualifier (ux) allows some dangerous environment variables to be passed to the unconfined process; 'man 5 apparmor.d' for details. May 25 17:32:16 apparmor[21005]: Warning from /var/lib/snapd/apparmor/profiles/snap.lxd.lxc (/var/lib/snapd/apparmor/profiles/snap.lxd.lxc line 485): Unconfined exec qualifier (ux) allows some dangerous environment variables to be passed to the unconfined process; 'man 5 apparmor.d' for details. May 25 17:32:16 apparmor[21005]: Warning from /var/lib/snapd/apparmor/profiles/snap.lxd.migrate (/var/lib/snapd/apparmor/profiles/snap.lxd.migrate line 485): Unconfined exec qualifier (ux) allows some dangerous environment variables to be passed to the unconfined process; 'man 5 apparmor.d' for details. May 25 17:32:16 apparmor[21005]: Warning from /var/lib/snapd/apparmor/profiles/snap.lxd.lxd (/var/lib/snapd/apparmor/profiles/snap.lxd.lxd line 485): Unconfined exec qualifier (ux) allows some dangerous environment variables to be passed to the unconfined process; 'man 5 apparmor.d' for details. May 25 17:32:34 apparmor[21005]: Warning from /var/lib/snapd/apparmor/profiles/snap.lxd.activate (/var/lib/snapd/apparmor/profiles/snap.lxd.activate line 485): Unconfined exec qualifier (ux) allows some dangerous environment variables to be passed to the unconfined process; 'man 5 apparmor.d' for details. May 25 17:32:34 apparmor[21005]: Warning from /var/lib/snapd/apparmor/profiles/snap.lxd.buginfo (/var/lib/snapd/apparmor/profiles/snap.lxd.buginfo line 485): Unconfined exec qualifier (ux) allows some dangerous environment variables to be passed to the unconfined process; 'man 5 apparmor.d' for details. May 25 17:32:34 apparmor[21005]: Warning from /var/lib/snapd/apparmor/profiles/snap.lxd.benchmark (/var/lib/snapd/apparmor/profiles/snap.lxd.benchmark line 485): Unconfined exec qualifier (ux) allows some dangerous environment variables to be passed to the unconfined process; 'man 5 apparmor.d' for details. May 25 17:32:34 apparmor[21005]: Warning from /var/lib/snapd/apparmor/profiles/snap.lxd.check-kernel (/var/lib/snapd/apparmor/profiles/snap.lxd.check-kernel line 485): Unconfined exec qualifier (ux) allows some dangerous environment variables to be passed to the unconfined process; 'man 5 apparmor.d' for details. May 25 17:32:34 apparmor[21005]: Warning from /var/lib/snapd/apparmor/profiles/snap.lxd.lxc (/var/lib/snapd/apparmor/profiles/snap.lxd.lxc line 485): Unconfined exec qualifier (ux) allows some dangerous environment variables to be passed to the unconfined process; 'man 5 apparmor.d' for details. May 25 17:32:34 apparmor[21005]: Warning from /var/lib/snapd/apparmor/profiles/snap.lxd.lxd (/var/lib/snapd/apparmor/profiles/snap.lxd.lxd line 485): Unconfined exec qualifier (ux) allows some dangerous environment variables to be passed to the unconfined process; 'man 5 apparmor.d' for details. May 25 17:32:34 apparmor[21005]: Warning from /var/lib/snapd/apparmor/profiles/snap.lxd.migrate (/var/lib/snapd/apparmor/prof
[Touch-packages] [Bug 1830502] [NEW] apparmor fails to start with no parser errors
Public bug reported: On Ubuntu 18.04.2 LTS Desktop, after running out of space on my disk, my system was unable to finish booting and I had to go into recovery mode and remove a number of files before the system would boot. After doing so I discovered that now the apparmor.service systemd unit always fails to start. I see this in dmesg: [ 1066.975360] Out of memory: Kill process 6799 (apparmor_parser) score 796 or sacrifice child [ 1066.975364] Killed process 6799 (apparmor_parser) total-vm:15057348kB, anon-rss:15046148kB, file-rss:0kB, shmem-rss:0kB [ 1067.406595] oom_reaper: reaped process 6799 (apparmor_parser), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB Whenever apparmor.service is attempted to be started by systemd, i.e. either on boot, or later with `systemctl start apparmor`. The log from journalctl doesn't show any actual issues with any profiles just this: -- Reboot -- May 25 17:00:58 systemd[1]: Starting AppArmor initialization... May 25 17:00:58 apparmor[1521]: * Starting AppArmor profiles May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd May 25 17:01:40 apparmor[1521]:...fail! May 25 17:01:40 systemd[1]: apparmor.service: Main process exited, code=exited, status=123/n/a May 25 17:01:40 systemd[1]: apparmor.service: Failed with result 'exit-code'. May 25 17:01:40 systemd[1]: Failed to start AppArmor initialization. May 25 17:04:53 systemd[1]: Starting AppArmor initialization... May 25 17:04:53 apparmor[4747]: * Starting AppArmor profiles May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd May 25 17:05:25 apparmor[4747]:...fail! May 25 17:05:25 systemd[1]: apparmor.service: Main process exited, code=exited, status=123/n/a May 25 17:05:25 systemd[1]: apparmor.service: Failed with result 'exit-code'. May 25 17:05:25 systemd[1]: Failed to start AppArmor initialization. I can see that apparmor profiles are active after doing this (using aa- status), but it's still troubling that apparmor runs into an issue without actually saying what the error is. ** Affects: apparmor (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1830502 Title: apparmor fails to start with no parser errors Status in apparmor package in Ubuntu: New Bug description: On Ubuntu 18.04.2 LTS Desktop, after running out of space on my disk, my system was unable to finish booting and I had to go into recovery mode and remove a number of files before the system would boot. After doing so I discovered that now the apparmor.service systemd unit always fails to start. I see this in dmesg: [ 1066.975360] Out of memory: Kill process 6799 (apparmor_parser) score 796 or sacrifice child [ 1066.975364] Killed process 6799 (apparmor_parser) total-vm:15057348kB, anon-rss:15046148kB, file-rss:0kB, shmem-rss:0kB [ 1067.406595] oom_reaper: reaped process 6799 (apparmor_parser), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB Whenever apparmor.service is attempted to be started by systemd, i.e. either on boot, or later with `systemctl start apparmor`. The log from journalctl doesn't show any actual issues with any profiles just this: -- Reboot -- May 25 17:00:58 systemd[1]: Starting AppArmor initialization... May 25 17:00:58 apparmor[1521]: * Starting AppArmor profiles May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd May 25 17:01:40 apparmor[1521]:...fail! May 25 17:01:40 systemd[1]: apparmor.service: Main process exited, code=exited, status=123/n/a May 25 17:01:40 systemd[1]: apparmor.service: Failed with result 'exit-code'. May 25 17:01:40 systemd[1]: Failed to start AppArmor initialization. May 25 17:04:53 systemd[1]: Starting AppArmor initialization... May 25 17:04:53 apparmor[4747]: * Starting AppArmor profiles May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd May 25 17:05:25 apparmor[4747]:...fail! May 25 17:05:25 systemd[1]: apparmor.service: Main process exited, code=exited, status=123/n/a May 25 17:05:25 systemd[1]: apparmor.service: Failed with result 'exit-code'. May 25 17:05:25 systemd[1]: Failed to start AppArmor initialization. I can see that apparmor profiles are active after doing this (using aa-status), but it's still troubling that apparmor runs into an issue without actually saying what the error i
