* dann frazier <1918...@bugs.launchpad.net> [2021-03-19 12:16]:
> On Fri, Mar 19, 2021 at 10:01 AM Ryan Harper <1918...@bugs.launchpad.net>
> wrote:
> >
> > * dann frazier <1918...@bugs.launchpad.net> [2021-03-18 16:30]:
> > > On Th
* dann frazier <1918...@bugs.launchpad.net> [2021-03-18 16:30]:
> On Thu, Mar 18, 2021 at 12:25 PM Ryan Harper <1918...@bugs.launchpad.net>
> wrote:
> >
> > * dann frazier <1918...@bugs.launchpad.net> [2021-03-18 12:11]:
> > > On Th
* dann frazier <1918...@bugs.launchpad.net> [2021-03-18 12:11]:
> On Thu, Mar 18, 2021 at 10:25 AM Ryan Harper <1918...@bugs.launchpad.net>
> wrote:
> >
> > * dann frazier <1918...@bugs.launchpad.net> [2021-03-17 20:30]:
> > > On Tu
* dann frazier <1918...@bugs.launchpad.net> [2021-03-17 20:30]:
> On Tue, Mar 16, 2021 at 10:05 AM Ryan Harper <1918...@bugs.launchpad.net>
> wrote:
> >
> > Hi Dan,
> >
> > Could you summarize the problem with flash-kernel and this system?
>
&
* dann frazier <1918...@bugs.launchpad.net> [2021-03-17 20:40]:
> On Wed, Mar 17, 2021 at 4:56 PM Ryan Harper <1918...@bugs.launchpad.net>
> wrote:
> >
> > I still don't understand:
> >
> > 1) why does which not find flash-kernel if it's present in the
I still don't understand:
1) why does which not find flash-kernel if it's present in the ephemeral image
(meaning it will also be present in the target filesystem
2) What is the problem with flash-kernel such that you need to dpkg-divert it?
Generally, we do not want to include paths to
Hi,
Thank you for filing a bug and helping make Ubuntu better. I believe
the regex restriction is happening in the Ubuntu Server Live Installer
(subiquity). I've added that package to this bug.
Here's the source code in question you're hitting.
** Also affects: curtin
Importance: Undecided
Status: New
** Also affects: subiquity (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Hi Dan,
Could you summarize the problem with flash-kernel and this system?
* dann frazier <1918...@bugs.launchpad.net> [2021-03-15 18:25]:
> Attached is a patch for curtin that works for me, though it could use
> some cleanup. It installs flash-kernel in the same place GRUB gets
> installed for
Huh,
Never seen partitions smaller than 1MB...
Curtin could truncate the requested size to the greater of 1MB or size of
partition.
On Tue, Feb 2, 2021 at 4:05 PM dann frazier <1868...@bugs.launchpad.net>
wrote:
> I worked around the MAAS deployment issue by manually removing all
> partitions
Thanks for doing most of the digging here @Oddbloke; I suspect as with
bond and bridges for ovs, we'll need a special case to check if a vlan
entry is also OVS, much like we did for bonds/bridges:
https://github.com/canonical/cloud-init/pull/608/files
So our is_vlan change will need to see if
You might just mark this bug duplicate of the other so we can close both
if this fixes things; and if so, I can update our vmtest which exercises
this path. Note this is broken all the way back through Xenial.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
@Eric
Yeah, I *think* that will work; I believe at the time I manually
performed that step and it worked.
I'm not sure w.r.t Secure Boot and shim-signed; Maybe @vorlon can
confirm if the xfs grub2 module is signed/included in shim-signed?
> As follow:
>
* eoli3n <1907...@bugs.launchpad.net> [2020-12-08 13:30]:
> If i run autoinstall with that user-data file, autoinstall doesn't run
> and subiquity prompt for language setting.
>
> #cloud-config
> runcmd:
> - systemctl daemon-reload
> - systemctl restart gdm3
> autoinstall:
> version: 1
>
* eoli3n <1907...@bugs.launchpad.net> [2020-12-08 11:50]:
> > I can say that the Ubuntu Server installer isn't typically used to install
> > Ubuntu Desktop.
> I use it because i can't find any netboot installer which supports
> autoinstall and EFI installation. I used legacy netboot (60MB) for
Can you run and attach the output tarball on the target system where you
see this fail:
cloud-init collect-logs
With respect to your use-case; cloud-init does not directly control what
packages do at install time. Some package may require post-install
configuration, or are not typically
Please move this back to New after you've attached the cloud-init
collect-logs output tarball.
** Changed in: cloud-init (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I'm marking the cloud-init task invalid for now.
As mentioned in the other bug[1]; cloud-init is not running too late;
rather scripts not provided to cloud-init are not waiting for cloud-init
to complete its execution. If your scripts are using cloud-init status
--wait before executing or
* Christian Dohm <1906...@bugs.launchpad.net> [2020-11-29 15:50]:
> Public bug reported:
>
Thank you for filing a bug.
> I've created a 'network-config' file with Terraform's yamldecode() function
> that contains (btw. I've tried with the version being a Number w/o quotes and
> as well as a
@nb This issue is *slightly* different than the other bug related to
missing BootCurrent value.
The previous bug which is fixed in curtin happens when the BootCurrent
value is not present in the efibootmgr output.
This bug has a BootCurrent value, like 0003, however, the Entries
provided by
@Dann
For this firmware bug where we have missing entries; Have you ever
booted this up and had efibootmgr show all of the entries?
Looking at this output here:
BootCurrent: 0003
Timeout: 10 seconds
@Dann
OK. That sounds reasonable. For this issue, curtin can (and I think it
makes sense) ignore a BootCurrent value if there is no corresponding
entry; warn in the logs that it's missing, check your firmware, etc...
and proceed if it can.
** Changed in: curtin (Ubuntu)
Importance:
On Thu, Oct 15, 2020 at 10:45 AM Frode Nordahl <1899...@bugs.launchpad.net>
wrote:
> Ryan, thanks for those pointers, will check. I also see in #15 that
> Bionic uses Fallback while Focal uses an actual ds, don't know why
> though.
>
Bah, I *keep* forgetting, that Bionic does *NOT* read
Looking back at your patch:
Index: curtin-20.1-29-g81144052/curtin/util.py
===
--- curtin-20.1-29-g81144052.orig/curtin/util.py
+++ curtin-20.1-29-g81144052/curtin/util.py
@@ -886,6 +886,7 @@ def get_efibootmgr(target=None):
"""
> I guess it's time for me to ask a question: is it cloud-init that
> renders /etc/netplan/50-cloud-init.yaml? If so where does netplan
> fit in when the difference is how that file is rendered and not
> how it is interpreted. As you can see in #10 the mtu statement is
> not in the file on bionic,
Thanks for the logs Dann,
The error comes from efibootmgr itself; so I don't think this is the
same issue. You can open a new bug; but it still looks like a
firmware/platform issue.
efibootmgr claims there are 5 entries; and at least after a grub
install, there is only one. What happened to
> On the flip side the presence of the MTU key in the OpenStack
> metadata cannot be used as an indicator for intent from either the
> system or the user that the DHCP server should not be providing the
> MTU either.
>
> Looking at the commit that changed the behaviour in OpenStack the
> intent of
> So I would suggest that whenever OpenStack eludes to dynamic configuration
> being in play cloud-init should not write the MTU value into the on-disk
> configuration but let it be configured by dynamic network configuration
> protocol.
>
> What do you think?
I would argue the opposite. The
" # curl http://169.254.169.254/openstack/2018-08-27/network_data.json
{"links": [{"id": "tapa035fb68-01", "vif_id":
"a035fb68-010c-42e3-8da7-ea3c36a0d607", "type": "ovs", "mtu": 8942,
"ethernet_mac_address": "fa:16:3e:31:26:f7"}], "networks": [{"id": "network0",
"type": "ipv4_dhcp", "link":
@Dann Thanks.
Can you provide the log without your changes? Or at least the
efibootmgr dump before curtin starts processing things?
> Notice we have no entry for current/0003. I have not inspected the code to
> determine whether or not this is an issue parsing efibootmgr output or the
>
@Jeff I cannot read the canonical pastebin output, can you use
paste.ubuntu ?
re: -updates; MAAS needs to initiate an SRU for archive users of MAAS.
@nb
I don't know for sure. I was told that MAAS snaps would pull curtin
from git master (or the respective release branches).
--
You received
Hi Patricia,
You'll need to upgrade MAAS itself. The curtin_userdata is what's sent
to the nodes deploying.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1895922
Title:
maas could not deploy a
I believe this is a duplicate of:
https://bugs.launchpad.net/curtin/+bug/1876258
This has already been fixed in curtin, you can test with curtin's daily PPA, or
curtin in groovy.
W.r.t uvtool; like MAAS, uvtool should generate serial disk attributes
for all virtio disks by default.
**
@Seth
Thanks for verifying!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1894217
Title:
2.8.2 deploy and commission fails corrupted bootorder variable
detected
To manage notifications about
@ltrager
Any idea why the maas verification for the 20.1 SRU didn't catch this?
curtin's vmtest runs with pristine NVRAM, so we always run with
update_nvram=true otherwise we can't boot into whatever is installed.
--
You received this bug notification because you are a member of Ubuntu
Bugs,
mwhudson already saw this and fixed in master, though without filing a
bug and no review AFAICT. =(
https://git.launchpad.net/curtin/commit/?id=83944d61e95ea7eb17289625330f0863bec39488
So daily curtin groovy is fixed. This is released in 20.1 so we'll need
to SRU to Xenial, Bionic, Focal.
**
Hi Jeff,
That's great. I'm just pushing this into a ppa for testing:
https://launchpad.net/~raharper/+archive/ubuntu/lp1894217
Groovy should publish any minute now, and I'll copy into
focal/bionic/xenial pockets shortly after.
Please let me know if this fixes things.
--
You received this
@Dan
Just ran into this issue in curtin's vmtest for network_vlan on groovy.
I can confirm that if the netplan config includes the driver match on
the physical interfaces, then the vlans come up just fine.
I was thinking that netplan could inject the driver of the underlying
device into the
Turns out it's unrelated to bcache; it is trivially reproducible:
lxc launch ubuntu-daily:groovy g1 --vm
lxc exec g1 bash
fallocate -l 1024M /swap.img
mkswap /swap.img
swapon --verbose /swap.img
cat /proc/swaps
On the 5.4 kernel that groovy had a few weeks back this works, on daily
(5.8) this
** Summary changed:
- fallocate swapfile has holes on 5.8 ext4 over bcache
+ fallocate swapfile has holes on 5.8 ext4
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1894910
Title:
fallocate
Public bug reported:
1) Groovy
2)
root@ubuntu:/home/ubuntu# apt-cache policy linux-image-generic
linux-image-generic:
Installed: 5.8.0.18.22
Candidate: 5.8.0.18.22
Version table:
*** 5.8.0.18.22 500
500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
100
Thanks for the logs.
They certainly seem to be duplicate entries, so AFAICT, the removal seems
reasonable.
However, removing BootCurrent shouldn't happen as we plan to boot back into
that entry anyhow.
I've got a branch that I'll build and put into a PPA so you can test
here shortly. It does
Thanks for the logs.
** Changed in: curtin (Ubuntu)
Status: Incomplete => In Progress
** Changed in: curtin (Ubuntu)
Assignee: (unassigned) => Ryan Harper (raharper)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Hi David,
would you be able to attach:
1) efibootmgr -v output (with all of the network entries present? it appears
that there
may be some duplicate entries in the menu; I'd like to confirm that by
examining verbose
output. Specifically Boot -> Boot0003.
Boot* EFI Network 1
Thanks for filing this bug and linking to the other EFI related one. They
aren't the same.
This looks like a bug in curtin's remove duplicate code:
Removing duplicate EFI entry (0006, {'name': 'EFI Network 1', 'path':
> 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:
> 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
> 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
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
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
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
Curtin is collecting by-id links to disk to populate grub2 's debconf
value:
grub-pc grub-pc/install_devices
It's not clear to me (yet) if providing non persistent values (like
/dev/sda) will work with
/usr/lib/grub/grub-multi-install
Even if it accepts non-by-id values; it's possible that on
low installed centos images to reboot (LP: #1881011)
-- Ryan Harper Thu, 20 Aug 2020 09:10:33 -0500
** Changed in: curtin (Ubuntu Groovy)
Status: New => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Tomorrow's Curtin daily:ppa should have this (and as you can see, other
fixes)
https://launchpad.net/~curtin-dev/+archive/ubuntu/daily
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1891608
Title:
** Also affects: curtin (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: curtin (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: curtin (Ubuntu Groovy)
Importance: Undecided
Status: New
** Also affects: curtin (Ubuntu Focal)
** Also affects: curtin (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1891608
Title:
openvswitch-switch isn't installed if netplan schema
Tomorrows Curtin daily:ppa should have this (and as you can see, other
fixes)
https://launchpad.net/~curtin-dev/+archive/ubuntu/daily
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1892242
Title:
Updated image is available:
% image-status maas3 | grep groovy
groovy amd64/ga-20.10/generic 20200819.1 squashfs
groovy amd64/ga-20.10/lowlatency20200819.1 squashfs
GroovyTestBasic on amd64 passes.
Thu, 20 Aug 2020 09:40:51 -0500: vmtest start: nosetests3 -vv
Once a new maas image is published with the updated initramfs, I can
verify; As of today, I still only see 20200814 for groovy
% date
Wed 19 Aug 2020 11:03:04 AM CDT
% image-status maas3 | grep groovy
groovy amd64/ga-20.10/generic 20200814squashfs
groovy
https://code.launchpad.net/~raharper/cloud-initramfs-tools/+git/cloud-
initramfs-tools/+merge/389422
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1890803
Title:
Groovy amd64 / arm64 / PowerPC
It turns out the 20200814 squashfs from maas *now* has an /etc/fstab in
it ...
So after overlayroot runs, we have an fstab like this:
root@(none):/# cat /etc/fstab
LABEL=cloudimg-rootfs /ext4 defaults0 0
#
# This fstab is for overlayroot. The real one can be found at
#
@Rafael
It's in both places:
https://github.com/koverstreet/bcache-tools/pull/1
I can update the PR there as well; though I don't think upstream cares
as Kent's working on bcachefs instead of bcache AFAICT.
> I see that you are trying to come up with something nor relying in the
kernel fix (to
@Rafael
For bcache-tools changes, bcache-export-cached-uuid needs the full path
to bcache-super-show, as PATH is not exported when running from udev.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I think we want two flags; keep the default behavior of all deps output:
and then
--build-requires # print the build package requirements
--requires # print the runtime package requirements
Then brpm needs to be updated to call read-deps with those two flags, and
adjust its
** Changed in: cloud-init (Ubuntu)
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1886080
Title:
lxd cloud_tests fail to export images on latest/stable
https://github.com/canonical/cloud-init/pull/484
** Changed in: cloud-init
Importance: Undecided => Medium
** Changed in: cloud-init
Assignee: (unassigned) => Ryan Harper (raharper)
** Changed in: cloud-init
Status: New => In Progress
--
You received this bug not
Public bug reported:
% ./tools/run-container centos/8 --package --artifacts=.
...
% rpm -U cloud-init-20.2+89.g818da27a-1.el8.noarch.rpm
Command: rpm -U /tmp/cloud-init-20.2+89.g818da27a-1.el8.noarch.rpm
Exit code: 1
Reason: -
Stdout:
Stderr: error: Failed dependencies:
@ddstreet
I'm not sure where upstream is going just yet. For Ubuntu; I think
1) Adjusting the bcache-tools patch to use the full path to bcache-
super-show should change;
2) If we fix (1) then I think we can drop the systemd patch from a bug
fixing perspective; on the openSUSE image I did
Public bug reported:
% tox -e citest -- run --verbose --os-name centos70 --preserve-data --data-dir
ctestout --test bugs/lp1885952-chrony
...
Command: ['lxc', 'image', 'export',
'b73b65fa3d3ce2b5aad9c22ac1c83575c15262e157db5651219318aad13cb94f',
'/tmp/cloud_test_util_9kido331']
Exit code: 1
On Tue, Jun 30, 2020 at 6:35 AM Balint Reczey <1861...@bugs.launchpad.net>
wrote:
> @raharper I've forwarded the systemd fix for you with minimal tidying of
> the commit message https://github.com/systemd/systemd/pull/16317
Thanks!
>
> --
> You received this bug notification because you are
> @Ryan,
>
> Since the installer refuses to install, there are no crash logs that I can
> provide you with. If you try to install 20.04 onto a disk with the mentioned
> layout (the "Custom layout" option), you should find that you are unable to
> choose sda1 and sda3 as destinations for /boot and
@Kai
Can you provide the installer crash or logs?
"refuses to use /dev/sda1 as boot partition and /dev/sda3 as root
partition"
I wonder if recent changes in subiquity around ESPs may have something to do
with this.
--
You received this bug notification because you are a member of Ubuntu
Bugs,
** Changed in: cloud-init (Ubuntu)
Importance: Undecided => High
** Changed in: cloud-init (Ubuntu)
Status: New => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1878682
Title:
> Ryan,
>
> Thank you so much for taking the time to go over the constraints and
> competing goals. It's always helpful to know what constituencies are
> involved.
Sure.
>
> > That said, I do think that cloud-init can make it easier to enable ipv6
> > where
> > it's desired (but without having
** Description changed:
== Begin SRU Template ==
[Impact]
This release sports both bug-fixes and new features and we would like to
make sure all of our supported customers have access to these improvements.
The notable ones are:
-*
+ *
See the changelog entry below for a
Public bug reported:
Not quite sure if what to do about this one; it's possible the "initial
setup" steps inject one path that the install path doesn; but the result
is that the "duplicate" entries aren't considered similar as the path
(and the name) don't match.
There's nothing *fatal* about
Public bug reported:
Centos vmtests install fine, the first boot phase fails as Centos
requires an selinux relabling process which reboots after relabeling.
The --no-reboot flag prevents this and we fail the test.
*** Warning -- SELinux targeted policy relabel is required.
*** Relabeling could
Public bug reported:
== Begin SRU Template ==
[Impact]
This release sports both bug-fixes and new features and we would like to
make sure all of our supported customers have access to these improvements.
The notable ones are:
*
See the changelog entry below for a full list of changes and
Hi Kevin,
> In the year 2020, IPv6 should be a first class citizen and I should not need
> to provide additional config for it to work right. The issue here is not
> that I can't find a workaround to make my scenarios work. The issue here is
> that I should not need any such workarounds on a
@Michael
I'll sync with mwhudson, subiquity will need to pull in the fix and
release an update to edge, once that's done you can select the Update
Installer option.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
systemd debdiff with a fix to skip creating /dev/disk/by-uuid for bcache
backing, caching devices.
** Patch added: "lp1861941-skip-bcache-links.debdiff"
https://bugs.launchpad.net/ubuntu/+source/bcache-tools/+bug/1861941/+attachment/5375730/+files/lp1861941-skip-bcache-links.debdiff
--
You
Tarball of a source package with a fix for this issue:
bcache-tools_1.0.8.orig.tar.gz
bcache-tools_1.0.8-4ubuntu1_amd64.build
bcache-tools_1.0.8-4ubuntu1_amd64.buildinfo
bcache-tools_1.0.8-4ubuntu1_amd64.changes
bcache-tools_1.0.8-4ubuntu1_amd64.deb
bcache-tools_1.0.8-4ubuntu1.debian.tar.xz
debdiff of the changes
** Attachment added: "bcache-tools-debdiff-1.0.8-4_to_1.0.8-4ubuntu1"
https://bugs.launchpad.net/ubuntu/+source/linux-signed/+bug/1861941/+attachment/5375722/+files/bcache-tools-debdiff-1.0.8-4_to_1.0.8-4ubuntu1
--
You received this bug notification because you are a
Updated test to be a bit more resilient.
** Attachment added: "test-bcache-byuuid-links-fixed.sh"
https://bugs.launchpad.net/ubuntu/+source/linux-signed/+bug/1861941/+attachment/5375723/+files/test-bcache-byuuid-links-fixed.sh
--
You received this bug notification because you are a member
Lastly, much of the focus on DOS partition tables comes from subiquity's re-use
existing partitions; it's still extremely common to have a dos partition table
rather than gpt.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
> On Fri, May 22, 2020 at 04:09:51PM -0000, Ryan Harper wrote:
> > We will need two formats for the hybrid mode, ptable: gpt and ptable:
> > dos
>
> I don't see why this should be the case. Are we not emitting GPT everywhere
> today, even when the system is booting in BIOS
OK.
I've reviewed the kernel code, and there are no unexpected changes w.r.t
the CACHED_UUID change event. So I don't think we will need any kernel
changes which is good.
With the small change to the 60-persistent-storage.rules to not attempt
to create a /dev/disk/by-uuid symlink for the
We will need two formats for the hybrid mode, ptable: gpt and ptable:
dos
For gpt, the config from comment #1 applies, we'll have both bios_grub
and an efi partition (possibly a secondary for resilient boot).
For dos, we'll have:
config:
- id: main_disk
type: disk
Digging deeper and walking through this in a focal vm, I'm seeing some
strange things.
Starting with a clean disk, and just creating the backing device like
so:
make-bcache -B /dev/vdb
We see /dev/bcache0 get created with vdb as the backing device. Now,
after this, I see:
/dev/bcache/by-uuid/
@Balint
I do not thing the fix you're released is correct, can you upload a new
version without the scripts?
Also, we should fix make-bcache -B to ensure that cset.uuid is not
initialized; that may be why the kernel thinks it should emit the
CACHED_UUID if the suerpblock of the device has a
In your dual stack example, can you run cloud-init collect-logs and
attach the created tarball?
In particular the cloud-init.log and what, if any network configuration
you're supplying in your NoCloud datasource.
> This tells me that someone enabled dhcp4 but not dhcp6 for cloud-init. We
>
Thanks for submitting the bug. Curtin project is not currently part of
the desktop installer. I've added the correct project (Ubiquity) for
your request.
** Also affects: ubiquity (Ubuntu)
Importance: Undecided
Status: New
** Changed in: curtin (Ubuntu)
Status: New => Invalid
That doesn't explain why they show up sometimes, but not all of
the time.
There are 3 devices in play here.
* The backing device, let's say /dev/vda; this is where we want
to store the data.
* The caching device, let's say /dev/vdb; this holds the cache.
* The bcache device; this only appears
I guess I don't understand why we see this in focal. The two events in
Colin's trace always happen on any Ubuntu kernel. We should see if we
can get another udev trace on bionic that captures both CHANGE events,
one will be from the bcache driver itself, and one is from the block
layer. THe
I believe the current failure you see is this one:
https://bugs.launchpad.net/subiquity/+bug/1878890
A fix has been created, it's getting reviewed and should land soon.
Once merged subiquity can pull in the fix.
--
You received this bug notification because you are a member of Ubuntu
Bugs,
This issue was fixed a while back in:
https://github.com/canonical/cloud-init/commit/4bcc94730
cloud-init retains the legacy bits, but prefers the use of os-release
file or kernel commandline to for checking for UbuntuCore.
** Changed in: cloud-init (Ubuntu)
Status: Confirmed => Fix
I would very much agree with xnox (it's a duplicate) (and Dan, nothing
for curtin to do);
curtin generated dname rules rely upon pointing to a /dev/bcache/by-
uuid/* symlink which is currently broken per
https://bugs.launchpad.net/ubuntu/+source/linux-signed/+bug/1861941
which at this time points
>From the crash:
Verifying /dev/sda2 exists
Running command ['sfdisk', '--json', '/dev/sda'] with allowed return codes [0]
(capture=True)
Verifying /dev/sda2 size, expecting 86564143104 bytes, found 86564143104 bytes
Device /dev/sda2 ptable
@Stian
No worries; it's nothing you configured/changed as far as I can tell.
We look up device paths to disk via serial or wwn; as it turns out your
two disks have different serials, but a duplicate (and invalid WWN); so
we'll need to fix our code to ignore these invalid WWN and not include
them
** Attachment added: "Source package tarball for upload"
https://bugs.launchpad.net/cloud-utils/+bug/1876139/+attachment/5367036/+files/cloud-utils-groovy-source-pkg.tar
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
1 - 100 of 1546 matches
Mail list logo
