Well, the yellow triangles signify either that the partition doesn't
have enough free space to do the install, or (I think) that it doesn't
have a compatible filesystem (presumably FAT16/FAT32). You may want to
blow away a partition, which I think should be allowed, albeit only
after clicking throu
/usr/X11R6 is an anachronism. (Heck, we're currently at R7, even.) I'm
fine with sweeping it away, but if that causes things to break, the
presumption is that those will be fixed straightaway.
Why is this bug still open? This bug has as trivial a fix as it gets.
--
Wrong path to X server in gdm.
Cody, you uploaded the last (and first, and only) release of this
package. Could you take a few minutes to push out this fix?
--
Wrong path to X server in gdm.conf
https://bugs.launchpad.net/bugs/445256
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribe
*** This bug is a duplicate of bug 443330 ***
https://bugs.launchpad.net/bugs/443330
I understand the distinction between unmount, eject and safe-remove, but
the issue isn't that a drive "still" appears in usb-creator after being
removed. (Note that I'm only talking about the safe-remove actio
Oh, okay, so "drive name" and "label" are really synonyms. ("Label"
would be the better term... by "drive name," I thought you might have
been referring to the lsusb device name. Besides, this is what would
appear in /dev/disk/by-label/, or be used in e.g. root=LABEL=home)
I agree that encouraging
*** This bug is a duplicate of bug 443330 ***
https://bugs.launchpad.net/bugs/443330
I don't think the Gnome/udev behavior in and of itself is a problem;
there are times when a "Redetect all connected filesystems" function
would be useful, and in the absence of that, I've often started up and
Using mkdosfs(8) should be fine. It's not like there would be, or should
be one [low-level] tool to both wipe/recreate the partition table *and*
create the FAT32 filesystem; those are very different operations and
joining them in anything other than a user-friendly frontend would
violate the Unix p
Public bug reported:
Binary package hint: usb-creator
This report is a spinoff of Bug #445810, and addresses usb-creator as
shipped with Karmic.
usb-creator has a strange quirk in that when it starts up, it (re)mounts
all unmounted partitions on all connected USB drives---even those drives
on wh
*** This bug is a duplicate of bug 443330 ***
https://bugs.launchpad.net/bugs/443330
Okay, I've just filed Bug #507309, which addresses that issue
specifically.
--
usb-creator operates on mounted filesystems, does not display confirmation
dialogs, issue warnings about data loss
https://bugs
Hello Geir,
I'm attaching a tarball produced as instructed in the wiki page you
linked to.
Note that this was produced over an hour after the initial freeze, as it
occurred while I was away. That aside, the failure mode appears
practically the same as the one I reported previously (only some of t
I can see where you're coming from, but I think it would be less
confusing to the user if local certificates were handled just the same
as system-bundled ones. I wouldn't see it as a good thing if the
procedure for enabling/disabling a certificate differed depending on
whether it were locally-insta
Just as a postscript, an arguable "workaround" to this issue in Karmic,
and likely helpful tweak to anyone who can't do much with a system if
sshd isn't running: set FSCKFIX=yes in /etc/default/rcS.
>From the rcS(5) man page:
"""FSCKFIX - When the root and all other file systems are checked, fsck
Okay, my bad: certificates in $LOCALCERTSDIR *are* added to
/etc/ssl/certs/, even though they don't appear in the multiselect list.
I don't have a need to disable locally-installed certificates via the
multiselect, but do believe the behavior should be for local
certificates to appear in the list.
Public bug reported:
Binary package hint: unattended-upgrades
This concerns unattended-upgrades 0.52ubuntu1 in Karmic.
If u-u is in the midst of upgrading the system, and the user shuts down
or reboots, the unattended-upgrade-shutdown script pauses the process
until the upgrade finishes. In the
I agree with this bug report, and with the need for an "advanced mode"
in which one of multiple partitions can be selected as a target. The use
case I want to support is a combination data + boot USB drive, where you
have a large FAT32 partition first (i.e. the only one Windows notices
when you plu
I'm not sure about requesting a new drive name / label---what exactly do
you mean by "drive name," anyway?---but at least a dialog that can't be
clicked through unthinkingly/accidentally would be good. Maybe something
like an EULA dialog, where you have the dialog text, an appropriately-
labeled ch
*** This bug is a duplicate of bug 443330 ***
https://bugs.launchpad.net/bugs/443330
komputes, thank you for delineating all these various related issues
affecting usb-creator! It seemed like all the bugs were blurring
together :-)
I pretty much agree with everything you've said, including bu
(Sorry for not following up sooner; I am currently travelling and my
Internet access has been sporadic.)
Geir, my concern is that the Intel hardware on which these freezes have
been occurring is quite common, and that reflects very poorly on the
development side of things. It's one thing if this w
> Are you currently able to make a disk with two FAT32 partitions (say
sdb1 and sdb2) and install ubuntu onto sdb2 using usb-creator?
Yes, that's exactly how I'm doing it now. With the caveats that...
1. The two partitions have to be created by hand (using e.g. fdisk(8));
2. usb-creator won't pl
Public bug reported:
Binary package hint: usb-creator
I am using usb-creator 0.2.12 from the Karmic LiveCD to install to a USB
thumbdrive.
I create a new FAT32 filesystem, check it with dosfsck(8), install the
live system on it, re-run dosfsck(8), and see errors. See below for the
step-by-step s
Public bug reported:
Binary package hint: usb-creator
Wishlist item, filed against version 0.2.12 in Karmic.
If the live environment [created by usb-creator] is running off a USB
drive, and is not using persistent storage, then mount /cdrom as read-
only instead of read-write. This will better a
I should add that I've had instances where the filesystem on the USB
drive does get corrupted, although I've yet to determine exactly what
causes this---attempting to (un)suspend the live system on hardware that
doesn't support it very well appears suspect. This is a major problem if
you're traveli
Public bug reported:
Binary package hint: mountall
This concerns mountall 1.0 in karmic.
I have a network filesystem that is not one of the typical ones, but a
fuse-python thing that connects to an LDAP server. When it starts up, it
immediately connects to the LDAP server; if it cannot do this,
Public bug reported:
Binary package hint: debian-installer
Installing Karmic using the alternate (netboot via PXE) installer, one
dialog appears somewhat wonky. See the attached image. Note the first
two entries in the locale list.
** Affects: debian-installer (Ubuntu)
Importance: Undecided
** Attachment added: "Screenshot of the dialog (taken via VNC on Xen)"
http://launchpadlibrarian.net/34701696/locale-dialog.png
--
"Choose language" dialog to select additional locales has two "#" locales
https://bugs.launchpad.net/bugs/465120
You received this bug notification because you ar
Public bug reported:
Binary package hint: debian-installer
Encountered this using the Karmic alternate installer (specifically,
netboot via PXE). Same failure mode on both i386 and amd64.
After confirming whether to install GRUB on the MBR, the installer
indicates "Executing 'grub-install (hd0)'
** Attachment added: "Fatal error dialog"
http://launchpadlibrarian.net/34707168/di-error.png
--
Karmic: legacy grub-install fails, possibly due to missing /target/etc/mtab
https://bugs.launchpad.net/bugs/465231
You received this bug notification because you are a member of Ubuntu
Bugs, which
** Attachment added: "Log on tty4"
http://launchpadlibrarian.net/34707209/di-log.png
--
Karmic: legacy grub-install fails, possibly due to missing /target/etc/mtab
https://bugs.launchpad.net/bugs/465231
You received this bug notification because you are a member of Ubuntu
Bugs, which is subsc
A workaround for this bug:
1. Start up a shell on tty2 or tty3
2. "cp /etc/mtab /target/etc/"
3. Edit the newly-created /target/etc/mtab file: Delete all lines except
the one specifying the device for /target (note: *not* the "tmpfs
/target/dev" line), and then change "/target" to "/".
4. At th
Public bug reported:
Binary package hint: mdadm
Seen while installing mdadm on Karmic:
Setting up mdadm (2.6.7.1-1ubuntu13) ...
Generating array device nodes... /var/lib/dpkg/info/mdadm.postinst: 170:
/dev/MAKEDEV: not found
failed.
Generating mdadm.conf... done.
Removing any system startup li
This bug was fixed in Debian, and Karmic now ships with the fixed
version.
** Changed in: module-assistant (Ubuntu)
Status: Confirmed => Fix Released
--
Typo causes invocation of "apt-get-y" instead of "apt-get -y"
https://bugs.launchpad.net/bugs/284548
You received this bug notification
A note for those needing a workaround: Both mine and Jim's make some
assumptions about how the disk has been partitioned. I assume that /boot
is *not* on its own partition, and Jim assumes that it is (and that it
is formatted as ext2, on /dev/sda5---adjust accordingly).
I'd be a bit careful with y
Public bug reported:
[I tried submitting this via reportbug(1), but it appears to have been
bitbucketed.]
Xmbdfed on amd64 segfaults when one attempts to bring up the "Other
Options" dialog. GDB gives some interesting telemetry:
Program received signal SIGSEGV, Segmentation fault.
0x000
Thank you @ddstreet, I'm happy to see this as well. I'd like to get rid
of the workaround I've been using for this issue:
# dpkg-divert --divert /etc/dhcp/dhclient-enter-
hooks.d/resolved.DISABLED --rename /etc/dhcp/dhclient-enter-
hooks.d/resolved
--
You received this bug notification because y
Yes, it is still an issue in focal. Was there an update since last year
that should have addressed this?
** Changed in: systemd (Ubuntu)
Status: Invalid => New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launch
FWIW, the fix in focal-proposed looks good on my end as well.
I can confirm that the /etc/dhcp/dhclient-enter-hooks.d/resolved script
now has the is-enabled check, and while I won't be able to test out
resolvconf, I regard the updated conditional as equivalent to my
previous known-good workaround
Philip Susi: Confirmed with the Bionic live CD:
root@xubuntu:~# cat /proc/cmdline
BOOT_IMAGE=(loop)/casper/vmlinuz boot=casper
iso-scan/filename=/linux/xubuntu-18.04-desktop-amd64.iso toram
root@xubuntu:~# umount /isodevice
umount: /isodevice: target is busy.
root@xubuntu:~# losetup -d /dev/l
Scott, thank you for providing the script, and the analysis that led to
it. I've run into this issue numerous times but have not been able to
suss out exactly what leads to it such that it can be reproduced.
I've linked a relevant Debian bug, which appears to address the same
issue, and was filed
Thanks for looking into this Markus. I'm surprised that the kernel
pieces needed to make this work as expected have yet to be fully
integrated.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1784499
Ti
Public bug reported:
This concerns sgt-launcher version 0.2.5-0ubuntu1 in Ubuntu focal.
I see the following when installing the package:
Setting up sgt-launcher (0.2.5-0ubuntu1) ...
/usr/lib/python3.8/subprocess.py:838: RuntimeWarning: line buffering
(buffering=1) isn't supported in binary mode
Public bug reported:
This concern chromium 80.0.3987.162 (snap package) in Ubuntu focal.
After installing the package, update-alternatives(1) cannot set x-www-
browser to point to /usr/bin/chromium-browser:
# update-alternatives --set x-www-browser /usr/bin/chromium-browser
update-altern
I am seeing this same error in Bionic. Some further telemetry:
# /usr/sbin/rsyslogd -n
rsyslog internal message (3,-2066): could not load module
'/usr/lib/x86_64-linux-gnu/rsyslog/lmnet.so', dlopen:
/usr/lib/x86_64-linux-gnu/rsyslog/lmnet.so: failed to map segment from shared
object
[v8.32.0 t
Hi Brian,
This is actually the same issue.
I am seeing the same error message quoted by the original reporter, but
that message is filtered through systemd---it is not direct output from
rsyslogd. What I provided was the direct output, that actually shows
what's going on.
I think this needs to b
This bug appears to have been fixed in 8.32.0-1ubuntu4. Looks like this
was an issue with the Apparmor profile.
rsyslog (8.32.0-1ubuntu4) bionic; urgency=medium
[ Jamie Strandboge ]
* debian/usr.sbin.rsyslogd: updates for bionic (LP: #1766600)
- allow rsyslog modules in multiarch director
I agree on this key needing to be available in the/an official Ubuntu
keyring package.
For now, because the original key file is not even accessible via HTTPS,
I am attaching a copy of it here. The file is dated 2016-07-04 16:10,
and has the following SHA{256,512} hashes:
4a54623d5ec01d098441a424
Public bug reported:
This concerns krb5-auth-dialog 3.12.0-2 in Ubuntu Xenial.
When the program is invoked with the --auto option, it briefly maps the
systray icon, and then segfaults.
Here is a GDB session running on a debug build of the original package
source:
$ gdb --args
/tmp/krb5-auth-di
I'm afraid I see the same failure mode with 3.20. The GDB session is
below.
(You're not able to reproduce this? This is a system with all the
Kerberos infrastructure, but a local-only user---no KRB* envvars set)
$ gdb --args /tmp/krb5-auth-dialog-3.20.0/_build/src/krb5-auth-dialog --auto
GNU gdb
Thank you Dimitry, that is a helpful link.
I've removed the key-file attachment from comment #5, but am unable to
otherwise edit/remove the text.
** Attachment removed: "dbgsym-release-key.asc"
https://bugs.launchpad.net/ubuntu/+source/ubuntu-keyring/+bug/643623/+attachment/4903350/+files/dbg
Hunh. How odd... I can't imagine that there would be something
particular to this system that is causing the crash. As you requested:
skunk@darkstar:/tmp/krb5-auth-dialog-3.20.0/_build/src$ G_MESSAGES_DEBUG=all
./krb5-auth-dialog -a
(krb5-auth-dialog:16500): KrbAuthDialog-DEBUG: ka_applet_set_pro
Attached is a Valgrind log file produced from a debug build of k-a-d
version 3.20.0.
All the errors appear to be accesses within freed memory...
** Attachment added: "kad-valgrind-log.txt"
https://bugs.launchpad.net/ubuntu/+source/krb5-auth-dialog/+bug/1700468/+attachment/4906188/+files/kad-v
Hi Guido, I think you mean "klist -V" (uppercase) :-)
On the system in question, that returns
$ klist -V
Kerberos 5 version 1.13.2
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1700468
Title
Steve, Bionic still has the default (commented-out)
#DNSStubListener=udp
in /etc/systemd/resolved.conf .
I've noticed that this breaks Kerberos KDC lookup at a large site,
because the reply is quite large:
# host -t SRV _kerberos._udp.xxx.example.com
;; Connection to 127.0.0.53#53(1
Thanks Dimitri, greatly appreciated. I haven't found many problems in my
testing of Bionic, but this is the juiciest one so far.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1731522
Title:
systemd-
Could this be SRU'ed into Bionic?
18.04LTS currently has version 1.1, so the "Reading database ..." lines
will otherwise afflict it for quite some time to come.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.ne
KillUserProcesses=yes is a sledgehammer of a solution. I would advise
just removing the geoclue package.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1871728
Title:
geoclue agent process persists a
Public bug reported:
This concerns tumbler 0.2.8-1 in Ubuntu focal.
Symptom: When I log into the Xubuntu desktop environment, the desktop
begins to appear on the screen, but then the X server dies and I am
unceremoniously returned to the LightDM login screen.
If I uninstall tumbler, then I can l
Public bug reported:
This concerns colord 1.4.4-2 in Ubuntu focal. (xiccd 0.3.0-1 may also be
relevant.)
I log into the Xfce desktop environment, and immediately see an
"Authenticate" window pop up:
Authentication is required to create a color managed device
Password for root:
Public bug reported:
This concerns systemd 245.2-1ubuntu2 in Ubuntu focal.
I am using the Xfce desktop. After the user logs out from a desktop
session, numerous desktop-related processes are left over. Here is a
listing, taken over twenty minutes after logout:
skunk853 0.0 0.2 18912 1
Public bug reported:
This concerns geoclue-2.0 2.5.6-0ubuntu1 in Ubuntu focal.
I am using the Xfce desktop. When a user logs in, a
/usr/libexec/geoclue-2.0/demos/agent process is started.
However, when the user logs out, and the associated "systemd --user"
instance is killed, the geoclue process
Note: My use case involves logging into the desktop remotely, via XRDP.
This issue appears to affect other remote-login implementations as well.
Related:
https://github.com/TurboVNC/turbovnc/issues/47
https://bugzilla.redhat.com/show_bug.cgi?id=1149893
https://gitlab.gnome.org/GNOME/gnome-setti
This occurs whether the user logs in (through lightdm) on the console,
or remotely via xrdp.
Running that command, as root, after the user (skunk) has logged in via
lightdm:
# loginctl list-sessions
SESSION UID USER SEAT TTY
20 root
c2 1000 skunk seat0
Public bug reported:
This concerns gnome-session-bin 3.36.0-2ubuntu1 in Ubuntu focal.
When I log into a Xubuntu desktop via xrdp, an error occurs, and the
session terminates before the desktop is even drawn on the screen.
I looked in syslog, and saw this:
Apr 9 12:12:23 test-ubuntu64 syste
Public bug reported:
This concerns update-inetd 4.50 in Ubuntu focal.
Observed during package installation:
[...]
Setting up finger (0.17-17) ...
Setting up update-inetd (4.50) ...
Setting up fingerd (0.17-17) ...
Use of uninitialized value $_ in pattern match (m//) at
/usr/
*** This bug is a duplicate of bug 1871955 ***
https://bugs.launchpad.net/bugs/1871955
Looks like a misplaced double-semicolon:
--- /var/lib/dpkg/info/grub-efi-amd64-signed.postinst 2020-04-09
07:00:04.0 -0400
+++ /tmp/grub-efi-amd64-signed.postinst 2020-04-09 22:16:11.243539503 -0
Autologin is not in use. The only unusual aspect of this login is that
it is via xrdp, and because no argument is passed to the initial
/etc/X11/Xsession invocation, it uses the default x-session-manager ->
gnome-session . If the user logs in via the console, xfce4-session is
used instead, masking
Could you try this using lightdm? It's possible that this may be a
display-manager issue.
I did notice that in a different (customized) configuration of Xubuntu,
the user processes still remained after logout, but then killing the
"systemd --user" process resulted in the login session ending.
Any
I've confirmed that this issue is still present in Ubuntu focal.
** Changed in: grub2 (Ubuntu)
Status: Incomplete => New
** Tags added: focal
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/5438
This issue is still present in Ubuntu focal.
Here is what I see that needs to happen:
systemd: The /etc/dhcp/dhclient-enter-hooks.d/resolved script should be
renamed to something like 00resolved or aaa_resolved, so that other
packages that install scripts into that directory will have their
scrip
To elaborate on the situation in Ubuntu focal, as there have been some
improvements:
* grub-reboot(8) now works even when GRUB_DEFAULT != "saved", so that is
out of the picture. I've edited the title of this bug accordingly.
* Both the man page and --help text for grub-set-default(8) indicate
tha
I'm not sure that this new title is accurate, as the error condition is
brought about specifically by an unusual (albeit legal) way of starting
the X session. My scenario involved xrdp, but I could see this happening
with an older display manager (xdm?) that does not recognize XDG
xsession files.
Public bug reported:
This concerns grub-pc 2.04-1ubuntu26 in Ubuntu focal.
I have the following packages installed. Note that grub-pc has been
removed but not yet purged:
root@xubuntu:/# dpkg -l | grep grub
ii grub-common 2.04-1ubuntu26
amd
Public bug reported:
This concerns grub-efi-amd64 2.04-1ubuntu26 in Ubuntu focal.
Currently, when grub-efi-amd64 (or grub-efi-amd64-signed) is installed
or reconfigured, the following steps occur:
1. Package postinst script runs
2. postinst checks if /boot/grub/x86_64-efi/core.efi is presen
I've confirmed that, as of focal, the /boot/efi/EFI/ubuntu/ directory no
longer needs to be present in order for the grub-efi-amd64 package to
install the bootloader files. Even /boot/efi/EFI/ does not need to be
there; it will be created. This issue still appears to exist on the
Debian side, howev
Public bug reported:
This concerns apparmor-profiles 2.13.3-7ubuntu5 in Ubuntu focal.
I use the usr.sbin.nscd profile in enforce mode, and am seeing the
following messages in /var/log/syslog . I don't know if the SIGABRT is
related:
May 27 04:39:56 test-ubuntu64 kernel: [ 199.392521] audit: typ
Public bug reported:
This concerns apparmor 2.13.3-7ubuntu5 in Ubuntu focal.
Saw this during a Firefox test run:
May 29 17:25:32 test-ubuntu64 kernel: [ 818.399967] audit: type=1400
audit(1590787532.023:69): apparmor="DENIED" operation="open"
profile="firefox" name="/run/user/1000/ICEauthority"
Public bug reported:
This concerns system-config-printer 1.5.12-0ubuntu1 in Ubuntu focal.
I log into the Xfce desktop, and then logout. The screen returns to the
LightDM login screen.
A few minutes later, "loginctl list-sessions" shows the following:
SESSION UID USERSEAT TTY
Related: LP: #1877528
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1871726
Title:
"systemd --user" and child processes fail to exit when user logs out
To manage notifications about this bug go to:
Public bug reported:
This concerns at-spi2-core 2.36.0-2 in Ubuntu focal.
I log into the Xfce desktop as "skunk" via xrdp, and then logout.
A few minutes later, "loginctl list-sessions" shows the following:
SESSION UID USER SEAT TTY
9 0 root
c10 1000 skunk
Also related: LP: #1877532
It's possible that all the lingering processes are due to a couple of
misbehaving applications.
This isn't a great state of affairs (the cleanup process should not be
so fragile that non-cooperative processes can stop it completely), but
it might explain what's going on
This bug has LP: 1871726 as a quasi-parent.
That one system-config-printer process shown in session-status is
deceptive; ps(1) shows a much larger number of processes still remaining
from the login session. When the s-c-p process goes away, however, all
the others follow. The impact of this issue,
This bug has LP: 1871726 as a quasi-parent.
Those two processes shown in session-status are deceptive; ps(1) shows a
much larger number of processes still remaining from the login session.
When the two processes go away, however, all the others follow. The
impact of this issue, then, is not limite
Public bug reported:
This concerns command-not-found 20.04.2 in Ubuntu focal.
The apt-get invocation largely tells the story:
# apt-get --purge --autoremove remove command-not-found
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following pack
Public bug reported:
This concerns onboard 1.4.1-2ubuntu7 in Ubuntu focal.
Seen during package installation:
[...]
Setting up onboard (1.4.1-2ubuntu7) ...
/usr/lib/python3/dist-packages/Onboard/LayoutLoaderSVG.py:447: SyntaxWarning:
'str' object is not callable; perhaps you missed a comma?
ra
Public bug reported:
This concerns lightdm-gtk-greeter-settings 1.2.2-3 in Ubuntu focal.
Seen during package installation:
[...]
Setting up lightdm-gtk-greeter-settings (1.2.2-3) ...
/usr/lib/python3/dist-packages/lightdm_gtk_greeter_settings/helpers.py:281:
SyntaxWarning: "is" with a literal.
This issue persists in lightdm 1.30.0-0ubuntu3.1 in Ubuntu focal.
I see the warnings not only for pam_kwallet.so, but also its successor
pam_kwallet5.so, as well as pam_gnome_keyring.so (which I do not have
installed). All three of these are referenced in /etc/pam.d/lightdm and
/etc/pam.d/lightdm-
I wouldn't expect dpkg to know about the database files, but they should
at least be deleted by a package script (prerm?) when the package is
removed/purged.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bu
This bug was reported three years ago in Debian:
https://bugs.debian.org/863227
** Bug watch added: Debian Bug tracker #863227
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863227
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ub
Public bug reported:
This concerns apparmor 2.13.3-7ubuntu5 in Ubuntu focal.
I have AppArmor actively enforcing policy on my system. In
/var/log/syslog, I see a number of the following two sorts of messages:
May 12 04:44:21 image-ubuntu64 kernel: [ 26.667094] audit: type=1400
audit(1589273061.
Thanks for being on top of this, Sergio. I'm surprised that a LP search
for "boot_id" in this project did not turn up this existing bug report.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1872564
Ti
Public bug reported:
This concerns apparmor 2.13.3-7ubuntu5 in Ubuntu focal.
If I delete a profile from /etc/apparmor.d/, reboot the system, and then
look in /var/cache/apparmor/.0/, I still see a file for the
compiled form of the profile.
The same occurs if the profile is "deleted" by o
Hello John,
I did not take any specific action to unload a profile from the kernel.
Instead, I rebooted the system, under the assumption that this would
wipe the slate clean, with everything reloading cleanly from
/etc/apparmor.d/.
The new profile I developed was under a new filename, because I d
Aaaand the upstream has decided they can't/won't fix this issue.
One thing that bothers me about this whole situation is that, in order
for background services like this one to be cleaned up after logout,
they need to behave "correctly." From my point of view, this is
backwards.
When the system i
Thanks. I am in complete agreement.
I don't need (or even want) AppArmor to automagically update the kernel
state right after changing something under /etc/apparmor.d/, because
having to do a SIGHUP/restart/etc. is already normal practice. But I do
expect that a reboot/reload will take care of tha
A related issue: "/etc/init.d/apparmor stop" should invoke aa-
teardown(8). Depending on the semantics of the apparmor "service," this
could also be "/etc/init.d/apparmor unload" or the like. I was surprised
to find that "apparmor stop" was not actually unloading the profiles, as
I had assumed.
>F
That's why I hedged on having something like "apparmor unload". What
you're saying explains why "restart" and "reload" are distinct actions
(I'd never been clear on this), so having a new action that is "like
'stop' but actually does stop apparmor, even though that is not usually
what you want" mak
Oliver and Łukasz, thank you for following this up.
So that I understand, in focal, is the fix part of the transitional
package, not in the snap?
The former is described as "This is a transitional dummy package. It can
safely be removed," but would removing it then remove Chromium as an x
-www-br
Hi Carolyn,
This bug concerns usb-creator specifically, not the general USB 3.0
mounting behavior of Linux. Please do not mark this bug as a duplicate
of #792085.
** This bug is no longer a duplicate of bug 792085
Automatic remount of safely removed USB 3.0 drive
--
You received this bug not
My understanding is that grub-pc conflicts with grub-efi-amd64 (and
other top-level GRUB packages), so having both installed shouldn't even
be possible. (I've filed a bug report on the Debian side to address
this, as this situation is not ideal: https://bugs.debian.org/904062)
And that if you want
I think there's a good case to get rid of those Conflicts:, at least for
the package combinations that make sense. BIOS+EFI definitely makes
sense, IMO.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/17
Philip, wouldn't such a debconf question be closely related to the
existing question on whether to install to the EFI removable media path?
Because if you're not putting things into EFI/ubuntu/ (or EFI/debian/),
then you'd be putting them into EFI/BOOT/ ...
--
You received this bug notification
301 - 400 of 836 matches
Mail list logo
