This bug was fixed in the package curtin - 21.1-0ubuntu1
---
curtin (21.1-0ubuntu1) hirsute; urgency=medium
* New upstream release.
- Release 21.1 [Michael Hudson-Doyle] (LP: #1911841)
- This adds arm64 compatibility for RH installations [Mark Klein]
- vmtest: add Hirsut
** Tags added: hwcert-server
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1893661
Title:
Support for Intel VROC (Virtual RAID On CPU)
To manage notifications about this bug go to:
https://bugs.lau
This bug is fixed with commit ac2c09ce to curtin on branch master.
To view that commit see the following URL:
https://git.launchpad.net/curtin/commit/?id=ac2c09ce
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.n
** Changed in: curtin (Ubuntu)
Assignee: (unassigned) => György Szombathelyi (gyurco)
** Changed in: curtin (Ubuntu)
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.n
The problem was that I didn't work on the master branch. Re-based and
re-submitted the merge request.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1893661
Title:
Support for Intel VROC (Virtual RAI
Hi György,
Is [1] the MP you submitted? I think something went wrong with it, as if
you committed the source tree with unresolved git conflicts. The MP
should look more or less like [2] if I don't go wrong.
Could you have a look and update/resubmit it?
Thanks!
[1] https://code.launchpad.net/~gy
At the end I was able to do a successful reinstall, using
mdadm_query_detail to investigate if it's a member array of a container,
and skip zeroing in this case.
I've sent a merge request. I didn't add size_kb yet, because I'm lazy
and we don't really need it. Can be added later of course.
--
Yo
Only one blocker remaining for a successful reinstall in shutdown_mdadm:
LOG.debug('Wiping mdadm member devices: %s' % md_devs)
for mddev in md_devs:
mdadm.zero_device(mddev, force=True)
As the devices in an array are held by the container, the zero_device
above fail (as it cannot
On 9/2/20 4:51 PM, Ryan Harper wrote:
>> I think your suggestion is a good YAML scheme. I think size_kb:
>> should be optional to fill the whole array with one volume if
>> it's omitted.
>
> Well, it's not that simple. What do we do if it's omitted and
> the config includes multiple volumes from
On 9/2/20 4:54 PM, Ryan Harper wrote:
>> This commit adds VROC container and array creation (on clean disks)
>> https://github.com/gyurco/curtin/commit/fd72c17665c071cde3eb5e047662b04ab993a0dd
>
> Nice!
>
> Now here's the not so fun part. We've not yet moved curtin to github, so code
> submissio
> This commit adds VROC container and array creation (on clean disks)
> https://github.com/gyurco/curtin/commit/fd72c17665c071cde3eb5e047662b04ab993a0dd
Nice!
Now here's the not so fun part. We've not yet moved curtin to github, so code
submissions are done here:
https://curtin.readthedocs.io/e
> I think your suggestion is a good YAML scheme. I think size_kb:
> should be optional to fill the whole array with one volume if
> it's omitted.
Well, it's not that simple. What do we do if it's omitted and
the config includes multiple volumes from the same container?
Curtin config is typically
This commit adds VROC container and array creation (on clean disks)
https://github.com/gyurco/curtin/commit/fd72c17665c071cde3eb5e047662b04ab993a0dd
Stopping and destroying existing one is to be done (+specifying a size to be
able to create more than one array in one container).
This config snipp
And the weird behavior of --examine of one disk: the current parser
errors out because of State is duplicated (quadruplicated actually)
mdadm --query --examine /dev/nvme0n1
/dev/nvme0n1:
Magic : Intel Raid ISM Cfg Sig.
Version : 1.3.00
Orig Family : 2b2b3bbf
Family
Hmm, just realized the one has to create dummy disk: entries for the devices
- type: disk
id: /dev/nvme0n1
path: /dev/nvme0n1
- type: disk
id: /dev/nvme1n1
path: /dev/nvme1n1
then they'll be usable for devices in type: raid
Another buglet: metadata is not passed to mdadm_create() in
raid_
I suggest to add a level: container to the top-level, as it would imply
to use the -e switch to mdadm, and also would be consistent to the query
output.
- type: raid
id: disk_raid_container0
level: container
metadata: imsm
name: /dev/md/imsm0
devices:
- /dev/nvme0n1p1
- /dev/nvme
I think your suggestion is a good YAML scheme. I think size_kb: should
be optional to fill the whole array with one volume if it's omitted. The
number of devices can be looked up by pairing 'container' with 'id'.
The EFI firmware can handle the EFI partition on this kind of RAID, and
for this reas
> 1-2) No, only the md-device, the container, raid level and number of
devices (it's possible to create different RAID volumes with different
levels in one container, however the number of devices must be the same
in all).
OK.
Looking at the
https://www.intel.com/content/dam/support/us/en/docume
Maybe it would be possible to abstract out the container, like:
- type: raid
metadata: imsm
container: /dev/md/imsm0
name: imsm0
devices:
- /dev/nvme0n1p1
- /dev/nvme1n1p1
- type: raid
devices:
- /dev/md/imsm0 # but need to get the number of real devices for -n
name: mirro
1-2) No, only the md-device, the container, raid level and number of devices
(it's possible to create different RAID volumes with different levels in one
container, however the number of devices must be the same in all).
3) AFAIK after stopping and removing all arrays from the container, mdamd
-
Cool!
The first step is to understand what additional metadata is needed to
construct an VROC device (this container).
The existing storage config yaml for raid looks like this:
https://curtin.readthedocs.io/en/latest/topics/storage.html#raid-command
It looks like we need to have a default name
It would be interesting, I'll try to "borrow" a VROC-enabled server for some
days. I think it will be not too hard to add this to curtin. I'll have
questions about the preferred method how to present this to the user, e.g.
maybe an external_metadata: , where could be imsm for now could
Thanks.
I won't mark this as a duplicate yet without further confirmation.
Would you be interested in working on the feature? I don't have access
to any Intel VROC devices which makes it difficult to implement.
I don't believe QEMU or other virt platforms emulate Intel VROC devices;
one needs t
The VROC is only for NVMes where the storage directly connected to the
CPU PCIe lanes. Its probable that they're using the same metadata
format, and according to the docs, it requires the same steps to create
the array (first the container, then the array itself), thus I think
both can be supported
Hello,
Thanks for filing the bug. Do you know if VROC is different feature
than RSTe? There's an existing feature request for that here:
https://bugs.launchpad.net/curtin/+bug/1790055
** Changed in: curtin (Ubuntu)
Status: New => Incomplete
--
You received this bug notification becau
25 matches
Mail list logo
