Thanks for the update @davidkrauser, and very happy that groovy is
working out. Is the fix due for focal sometime in the coming weeks or
months? Any extra info is appreciated. Also happy holidays and end of
year, and thank you all for what you do!
--
You received this bug notification because you
Hey, is there some transparency into an actual fix here? https://cloud-
images.ubuntu.com/focal/20201210/focal-server-cloudimg-amd64.img still
has this issue. I still cannot use the cloudimg with libvirt / qemu
without modification to workaround this issue.
--
You received this bug notification b
Awesome, thanks for categorizing that for me @vorlon! I was trying hard
to find the right home for the issue, but didn't even think of livecd-
rootfs :)
I still am not too sure about the ultimate value offered by the
initramfs fallback. It seems like you would: (a) never want initramfs,
or (b) alw
Hi! Has any information surfaced about the cloudimg kernel and virtio-
scsi?
After thinking about this for some time, I propose that the "initrdfail"
design isn't ultimately helpful and should be reverted, because: (1) It
substantially increases the complexity of grub.cfg, (2) it is not clear
that
> These images should likewise be bootable under libvirt with, at most,
a boot performance penalty because of the second boot.
Well, yes, it does boot on the second boot. Not trying to be contrarian
here, but isn't a moot point that booting on the first boot is the de
facto way things should work?
** Summary changed:
- focal-server-cloudimg-amd64.img panics on first boot, cannot open root device
+ virt-install of focal-server-cloudimg-amd64.img panics on first boot,
breaking cloud-init
** Description changed:
- Various Focal cloudimg builds fail on first time ever booting (e.g.
- https:/
Thanks for the information @vorlon. I think that makes sense.
What would be the solution for booting focal-server-cloudimg-amd64.img
with libvirt (virt-install) (so, not on Azure, as the OP was; so, I
think the issue is now fractured into two separate issues with same
underlying cause)?
Thanks.
Hey Dan, thanks for getting back. In my case, it's not even my system
though: it's Canonical's system; It's a fresh download of a cloudimg
from https://cloud-images.ubuntu.com/focal/ which has the issue, so it
can't because I didn't build the image right, because I didn't build the
image at all. So
I don't know how to escalate attention to this issue. Is emailing the
author of commit 6a814c759e10feafb40c3669be30aa51eb5ce39b, which seems
to have introduced the issue, acceptable? I'm surprised it's not causing
more issues. I guess people don't care about the cloud images much?
--
You received
I'm actually not sure the best place to file a ticket for the cloudimg
distribution. Any recommendation appreciated.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1870189
Title:
initramfs does not g
Hmmm, I am not using the ISO, but rather the pre-installed cloudimg, and
I am not so sure it is actually fixed. I just tried out the latest one,
and can confirm the issue still persists with it:
https://cloud-images.ubuntu.com/focal/20200430.1/focal-server-cloudimg-
amd64.img
Here is the output f
The git commit which introduced the issue seems to be this:
commit 6a814c759e10feafb40c3669be30aa51eb5ce39b
Author: Mathieu Trudel-Lapierre
Date: Tue Jul 16 11:31:29 2019 -0400
Import patches-unapplied version 2.04-1ubuntu1 to ubuntu/eoan-proposed
Imported using git-ubuntu import.
I've traced the issue back to "00_header" and "10_linux" here:
https://git.launchpad.net/ubuntu/+source/grub2/tree/debian/patches
/ubuntu-add-initrd-less-boot-fallback.patch?h=ubuntu/focal
diffstat debian/patches/ubuntu-add-initrd-less-boot-fallback.patch
Makefile.am |3 ++
Discussing here: https://bugs.launchpad.net/ubuntu/+source/linux-
azure/+bug/1870189
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1874147
Title:
focal-server-cloudimg-amd64.img panics on first boot
Also, this bug is not specific to just Azure. I am using libvirt and
experiencing this issue.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1870189
Title:
initramfs does not get loaded
To manage no
Hi, this issue needs attention because it renders the cloud images for
Ubuntu 20.04 potentially unusable. Thanks.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1870189
Title:
initramfs does not get
This bug may also be affecting focal-server-cloudimg builds at:
https://cloud-images.ubuntu.com/focal/.
See: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1874147
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.lau
** Also affects: grub2 (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/1874147
Title:
focal-server-cloudimg-amd64.img panics on first boot, cannot
*** Update
I was able to reproduce this issue in a fresh provisioning from the
Kubuntu 15.10 ISO, although the boot log now stops at
[OK] Started Accounts Service
(See screen shot).
Steps to reproduce:
1) Create a new VM (VMWare Fusion 8.1.0, although I doubt this matters) 4 cpu
cores, 8GB Ra
I get the same or very similar behaviour running Kubuntu 15.10 running
under VMWare Fusion on a Mac. After doing a sudo apt-get dist-upgrade
the vm fails to boot, getting stuck on the boot logo. Hitting escape
right after the machine starts shows me the boot log, and it gets wedged
on the line "sta
I would like to politely correct the author of post #11, who says this
is only "a particular use-case." The author is mistaken to believe that
the (well written) steps to reproduction make it sound like this is an
obscure use case, whereas this is actually substantial use case, as
iterated in post
I have a temporary workaround for this bug.
Entering these two commands before running any scripts acts as a
workaround for me:
addpath (genpath('/usr/share/octave/site/api-v22/m/octave2.9-forge/'));
addpath (genpath('/usr/share/octave/2.9.12/'));
I tested imread, imagesc, and some other f
22 matches
Mail list logo