This bug was fixed in the package livecd-rootfs - 2.664.3
---
livecd-rootfs (2.664.3) focal; urgency=medium
[ Łukasz 'sil2100' Zemczak ]
* Enable overrides of UC20 grade dangerous channels - as this is possible.
(LP: #1879350)
[ Iain Lane ]
* Hack seeding of linux kernel
I have just fired up a livefs build of ubuntu-core on focal (UC20),
without the snappy PPA and with -proposed enabled, with CHANNEL
=dangerous-beta:
https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/focal/ubuntu-
core/+build/229423
The build succeeded and the model-assertion used is the danger
** Description changed:
+ [Impact]
+
+ We need the ability to build arbitrary-risk-level dangerous images for
+ UC20.
+
+ [Test Case]
+
+ Fire up a livefs build of ubuntu-core on focal using the -proposed
+ version of livecd-rootfs, with CHANNEL=dangerous-beta and observe if the
+ build succeed
Hello Ian, or anyone else affected,
Accepted livecd-rootfs into focal-proposed. The package will build now
and be available at https://launchpad.net/ubuntu/+source/livecd-
rootfs/2.664.3 in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See
https:/
This bug was fixed in the package livecd-rootfs - 2.668
---
livecd-rootfs (2.668) groovy; urgency=medium
[ Łukasz 'sil2100' Zemczak ]
* Enable overrides of UC20 grade dangerous channels - as this is possible.
(LP: #1879350)
[ Patrick Wu ]
* live-build/ubuntu/hooks/040-hyp
I geuss we still need to do livecd-rootfs SRU to ensure we don't loose
this code.
** Changed in: ubuntu-cdimage
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bu
** Changed in: livecd-rootfs (Ubuntu)
Status: In Progress => Fix Committed
** Changed in: ubuntu-cdimage
Status: New => Fix Committed
** Changed in: ubuntu-cdimage
Assignee: (unassigned) => Łukasz Zemczak (sil2100)
--
You received this bug notification because you are a membe
Ok, so actually this is much easier. After talking with mvo it seems
that grade dangerous models can have their channels freely overridden,
which means no new model assertions need to be created. What I did is I
prepared an upload for livecd-rootfs which adds the support for
dangerous- channel. Onc
** Changed in: livecd-rootfs (Ubuntu)
Assignee: (unassigned) => Łukasz Zemczak (sil2100)
** Changed in: livecd-rootfs (Ubuntu)
Status: New => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchp
So I was personally a bit going back and forth about this bug.
Originally, at the very beginning, I had the wrong assumption that the
dangerous builds were beta based anyway - but that was just my personal
imagination!
Looking at it now, seeing Ian's comment about current actual differences
betwe
> So testing images built with grade=dangerous is not a reliable proxy
for assuring the correctness of the grade=signed images.
This is partially correct, insofar as yes there are some non-trivial
behavior changes between the grade==dangerous and grade==signed images,
however much of the behavior
The whole point of grade=dangerous is that it changes the behavior of
snapd. So testing images built with grade=dangerous is not a reliable
proxy for assuring the correctness of the grade=signed images. How are
these going to be tested, since they can't be tested automatically, and
in what way is
Yes this is a stated snapd deficiency that will be solved by the 1.0
release, but there is a possibility that we do not have it solved in the
next week or so, so we have this request. If you would like to file a
snapd bug to track cloud-init support on grade > dangerous images, feel
free to do so.
You say that you need this, but didn't specify the why.
As far as I understand, due to snapd deficiencies cert team cannot
automatically test production grade:signed images. They can only test
grade:dangerous images at the moment due to snapd enforced constraints.
If and when, snapd improves, we
grade dangerous images allow override of channels... but they must be on
per-snap basis.
Thus alternative to this request is to somehow allow passing a channel
map from cdimage to livecdrootfs get stuff back and publish them in
unique directories. It has to be on per-snap basis, because the set of
15 matches
Mail list logo