I've tested this, and under the noted conditions resolvconf no longer
has an issue updating /etc/resolv.conf. Thank you for your time and
attention to detail!
Unless someone else weighs in noting a problem, from my perspective it
seems like this bug can be closed now, as you've corrected the issue
Hey there. Thanks for your time on this. I'll try to supply positive
confirmation over the weekend.
--
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/1853164
Title:
systemd:
Note: In Bionic - I haven't checked exhaustively - libpango1.0-0 is a
transitional package, and
libpango-1.0-0 is the actual package. Perhaps Focal Fossa should continue to
ship the transitional
package to keep Minecraft folk from encountering this. Not sure what policy
applies.
--
You receive
And RikMills notes:
https://launchpad.net/ubuntu/+source/pango1.0/1.44.7-2ubuntu1
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pango1.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1869716
Title:
Removing libpango1.0-0
Interesting. But the code is still incorrect, with my patch correcting it,
so I guess we'll see how it goes. I can either fix it locally or go elsewhere,
but I'm hoping it's simply fixed in the distribution.
Thanks for the pointer.
--
You received this bug notification because you are a member
sdezial notes this being terser. I do the long form out of superstitious awe
at the notion of a return code of zero being "true", even though it always
is, but this would be terser and also correct:
if systemctl is-active systemd-resolved > /dev/null 2>&1; then
--
You received this bug notif
--
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/1853164
Title:
systemd: /etc/dhcp/dhclient-enter-hooks.d/resolved error
Status in systemd package in Ubuntu:
New
Bug desc
Public bug reported:
The functionality exists to allow users to revert to the traditional ifupdown
package for network configuration. Alongside this, systemd's often-buggy
resolver can be disabled. However, there's a logic error in the systemd-
supplied /etc/dhcp/dhclient-enter-hooks.d/resolved
I'm curious about these two status changes:
Changed in systemd (Ubuntu):
status: Confirmed → Fix Released
Changed in initramfs-tools (Ubuntu):
status: Confirmed → Fix Committed
Would it be possible to have pointers to the commit(s) that fixed this?
Thanks!
--
You received this
I'm going to open a seperate ticket for the typo/cosmetic issues noted,
so that this ticket can focus on the core. I'll note the ticket number
here once I've created it, which I'll do on the other side of my
commute.
--
You received this bug notification because you are a member of Ubuntu
Touch s
In addition to the typo, there may be an issue where the new setting I
poked in is used, but the hardcoded default is still displayed on-
screen. I've not been able to capture this on camera as yet, and I have
yet to set things up such that all the generated messages are stored for
later perusal, i
I just confirmed that I see this on a laptop as well. Conveniently, the
laptop install is not using MD-RAID or ZFS - it's using LVM on LUKS on a
single disk, so it's a simpler case.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed
Assuming this isn't fixed any time soon, I'm running with this:
mason@ogre /home/mason$ cat /etc/systemd/system.conf.d/expletive.conf
# required singleton - high ceremony
[Manager]
#DefaultTimeoutStartSec=15s
DefaultTimeoutStopSec=15s
Note that while "Manager" is evidently the only possible sect
I just managed to time it right such that I caught the error on my
screen, and in doing to noticed a glaring typo that's likely indicative
of the overall code quality of the related software.
I'd be grateful for debugging tips. I hope Canonical's not going to ship
software that punishes LUKS users
That seems like a reasonable approach.
--
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/1554803
Title:
apparmor: missing stub hardware directories
Status in apparmor packa
Public bug reported:
● apparmor.service - LSB: AppArmor initialization
Loaded: loaded (/etc/init.d/apparmor; bad; vendor preset: enabled)
Active: failed (Result: exit-code) since Tue 2016-03-08 14:34:04 EST; 4h
23min ago
Docs: man:systemd-sysv-generator(8)
Process: 2909 ExecStart=/et
** Also affects: initramfs-tools (Ubuntu)
Importance: Undecided
Status: New
--
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/1554795
Title:
timeout on rest
Public bug reported:
Using the server install ISO, it's possible to specify root on LUKS and
variations thereof - for instance, root on LUKS on MD-RAID, root on LVM
on LUKS on MD-RAID, and so forth. The installer does the right thing and
initramfs-tools does everything necessary to support booting
18 matches
Mail list logo
