For some reason that we have not yet determined, the overlay that we use
for the drivers code sometimes fails to unmount with EBUSY.
When it happens, the _list_drivers task would fail, making subsequent
GET calls to /drivers?wait=true fail as well and produce an error
report.
We now mark failures in the overlay unmount operation as non fatal.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
The apt.overlay construct unmounts the overlay at the end of the with
body. To do so, it leans on subprocess.run(["umount", ...], check=True).
If we want to catch the unmount error, we need to do:
try:
with apt.overlay():
# do stuff
except subprocess.CalledProcessError:
# handle the unmount exception
However, we do not want the subprocess exceptions that happen in
the with body to be caught in the same except block.
If the umount call fails, we now wrap the exception in a
OverlayCleanupError ; therefore we can make the distinction between an
unmount error and a subprocess error that would happen in the body.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
The behavior of asyncio.get_event_loop() will change in a future Python
version. It is deprecated starting Python 3.10.
The functions that we can use instead are:
* asyncio.new_event_loop() - which creates a new event loop
* asyncio.get_running_loop() - which returns the event loop only if it
is already running
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Creating a aiohttp connector when no event loop is running is not
considered safe. Under the hood, aiohttp invokes
asyncio.get_event_loop() which:
1. currently creates a new event loop if one does not already exist
2. will stop creating a new event loop in a future Python release
3. is deprecated starting Python 3.10
We want to make sure Subiquity creates the event loop itself, so we now
create the aiohttp connector in a coroutine.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
When size: -1 is specified on a given partition, we attempt to determine
the its right size by looping through the partitions and computing a
list of available gaps.
That said, when looping through the partitions, we also include the one
which has an incomplete (i.e. = -1) size. This makes the computation
rely on a negative value and this often leads to incorrect result.
Fixed by excluding the current partition when determining its
appropriate size.
https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1991929
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
When storage version 2 is used, partitions require an offset. When
loading partitions via an autoinstall file, we now make sure to assign
offsets automatically if the user did not specify offsets.
https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1991413
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
The available_for_partitions function wrongly assumed that the
underlying disk had a GPT partition table. Updated the implementation to
use the alignment data as expected.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
In the new tests recently added to test_filesystem.py, the initial disk
object was marked having a msdos partition table.
This is fine for computing offsets manually. However, what really needs
to be done is to mark the partition table as msdos in the YAML itself.
Otherwise, the disk is reformatted as GPT.
This makes gap functions use the right alignment data when computing the
list of gaps available.
Sadly it breaks the tests because of other issues, so I added FIXME tags
in the broken tests.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
To avoid having nested contexts for one step. It's a bit unsatisfying
because conceptually the code in CurtinPartitioningStep.run should be
considered part of the same context but I don't see a good way to do
that and it's not of practical significance.
When defining a partition with size: -1, the partition should expand to
the size of the largest gap. To determine which gap to use, we call the
function largest_gap(partition.disk).
That being said, the gap returned is sometimes bigger than expected when
using a msdos partition table. This happens because we return the
largest gap without checking if it is inside or outside the extended
partition.
Fixed by making sure that:
* for a logical partition, we pick the largest gap within the extended
partition
* for a primary partition, we pick the largest gap outside the extended
partition (if any).
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Our documentation of autoinstall mentions that one can specify the size
of a partition as -1 to use the remaining space on the disk.
Because it only makes sense in practice to support this option for the
right-most partition of a given disk, specifying size: -1 is only
accepted when defining the last partition of the disk.
Having said that, when making an autoinstall configuration that includes
an extended partition, the user must define the logical partitions after
the extended partition.
For the following configuration:
| disk |
+--------------+--------------+--------------+-------------------------|
| p1 (primary) | p2 (primary) | p3 (primary) | p4 (extended) |
| | | | p5 (logic) | p6 (logic) |
, the representation in Subiquity will be analogous to:
[
Partition(p1, "primary"),
Partition(p2, "primary"),
Partition(p3, "primary"),
Partition(p4, "extended"),
Partition(p5, "logical"),
Partition(p6, "logical"),
]
This means that specifying size: -1 on p4 gets rejected because it is
not the last partition defined.p6 is the last partition defined.
This is however a valid use-case because p5 and p6 are contained within
p4. So p4 should be able to use the remaining space and there is no
reason to reject this configuration
Fixed by ignoring logical partitions when checking if a size of -1 is
allowed on an extended partition.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
The second `trap ... EXIT` registration meant that the first one, the
one repsonsible for providing a clear PASS / FAIL at the end, was not
being shown.
The SingleInstanceTask does not allow us to control cancellation the way
we want. We now use a standard asyncio.Task to execute the coroutine
that fetches the list of snaps.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
The list snaps task used to return successfully even in case of error.
To make the distinction between and error and a successful fetch, we
used to rely on the task to set an attribute at the loader level:
* failed = True; or
* failed = False
The task was responsible for setting this attribute and there were
scenarios where it would not set the attribute properly. Usually, this
was when an exception was raised in the task.
We now raise an exception when an error occurs in the task ; instead of
returning. This is better because we can know if the task:
* got cancelled - by calling "task.cancelled()"
* finished successfully - by calling "task.done() and not
task.exception()"
* failed - by calling "task.done() and task.exception()"
* has not finished - by calling "not task.done()"
This also allows us to detect errors and retry
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Dan Bungert