** Description changed:
[Impact]
The new Amazon AWS C5 instance type is not a recognised VM type in
Landscape and thus won't allow use of a Virtual Guest asset to register
with.
The C5 instance type is a new type that uses a KVM-family hypervisor
instead of Xen (displaying
I should point out DigitalOcean instances started to inhibit the same
behaviour and will also need to be identified in a similar fashion.
--
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1742531
** Tags added: sts
--
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1742531
Title:
New Amazon AWS C5 instances are not recognised as a VM
Status in Landscape Client:
Fix Committed
Status
This issue has been identified as Field Critical. The medium importance
assigned to this defect seems counter intuitive to the SLA level
assigned.
@Eric
can you provide some insight into a time frame for a fix. Typically under
Critical SLA we expect a dedicated engineer and a fix in a week.
--
Seyeong,
I prepared a package with the debdiff for uploading, but it is failing
to build during the autopkgtests; can you check that and update the
debdiff please?
configure: creating ./config.status
config.status: creating Makefile
config.status: creating Doxyfile
config.status: creating
You have been subscribed to a public bug by Eric Desrochers (slashd):
[Impact]
The new Amazon AWS C5 instance type is not a recognised VM type in
Landscape and thus won't allow use of a Virtual Guest asset to register
with.
The C5 instance type is a new type that uses a KVM-family hypervisor
** Description changed:
[Impact]
If PID is larger than 6 digits apparmor denies process which only affect
64-bit systems[1] where the PID_MAX_LIMIT can be generated up to 7
digits at the maximum.
This fix is committed, but not released. so all supporting version are
affected.
** Changed in: apparmor (Debian)
Status: Unknown => Confirmed
--
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1717714
Title:
@{pid} variable broken on systems with pid_max more than 6
Another verification that IMHO can be done more easily and faster than
the touch approach explain above is to directly change the pid_max and
ns_last_pid via sysctl in the 7 digit range (<4millions), and then try
to reproducer.
For instance:
sysctl -w kernel.pid_max=300
sysctl -w
** Changed in: apparmor (Ubuntu Bionic)
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1717714
Title:
@{pid} variable broken on systems with pid_max
I have contacted a coredev to hopefully sponsor the development bit
(Bionic) today, so I can proceed with the stable release update myself
next week.
- Eric
--
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
Attaching "lp1717714_bionic_V2.debdiff":
- Nitpicking stuff related to d/changelog and DEP3 patch header.
** Patch added: "lp1717714_bionic_V2.debdiff"
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1717714/+attachment/5035841/+files/lp1717714_bionic_V2.debdiff
--
You received
** Description changed:
[Impact]
- If PID is larger than 6 digits.
+ If PID is larger than 6 digits apparmor denies process which only affect
+ 64-bit systems[1] where the PID_MAX_LIMIT can be generated up to 7
+ digits at the maximum.
- apparmor denies process.
+ This fix is committed,
13 matches
Mail list logo
