 |
Thank you for the report. You're right the image seems not very functional. I did basic smoke tests on it, but clearly need to validate some more. I'll rebuild this in the morning and check what's going on. |
 |
Also of note here is that the cloud image is missing LVM support at boot for the root filesystem by default (I know that is probably not minimal but in my estimation it is essential for most instances) |
|
|
The majority of cloud images do not have LVM in them, at least as far as I have seen with all downloaded images over the past few years that I've used with Openstack. Usually an image has a single standard partition, since cloud-init manages the images, and if an instance is resized, then it uses growpart to increase the disk partition. If the image has an LVM partition, then chances are this isn't going to work. |
|
|
Thanks Ian - but I've found the opposite to be true. Our use case is the same in Openstack, we have been using Centos images (from the Centos qcow resource at https://cloud.centos.org/centos/7/images) and more recently the Rocky image in question. From 7.2 right up to and including 8.5 LVM for the root file system was enabled by default and works completely as expected with growpart. The problem we have now with this image is partly to do with growpart failing due specifically due to LVM being missing (makes this image a special case to work around for our build system) For now I've taken the 8.5 image (which works absolutely fine) and updated it to 8.6 using virt tools (as a workaround) |
|
|
Martin, OK good to know :) I know previously a lot of the centos/rhel/sles jeos images that I used were standard images, hadn't seen anything with lvm yet, so if that's the case, fair enough :) |
|
|
@marnixgb I've seem the same as you in most cases. @iwalker Which image are you referring to? The latest x86_64 image at https://cloud.centos.org/centos/7/images, **CentOS-7-x86_64-GenericCloud-2111.qcow2** does not have any `lvm2` RPMs installed by default. Neither does the **rhel-8.5-x86_64-kvm_password.qcow2** image available from redhat.com. I have not used the ppc64le or the aarch64 images, so am not sure they handle disks the same way. Are you sure the image wasn't customized first, or a cloud-init configuration is installing them for you? |
|
|
You can ignore the _password on the qcow image. I just happened to use virt-customize really quickly to set the password of root for a quick confirmation test without modifying the original image. |
|
|
@Trevor Benson I used the official images downloaded from CentOS, RHEL, Debian, Ubuntu. To date I didn't see these images with LVM installed, let alone with LVM partitions (but they were images pre December 2021 - not downloaded new ones since). But if things change and they start to use LVM like @Martin said then fair enough. I only mentioned, because if the majority of other images do not have it, then Rocky can also be without LVM as well. It doesn't make a huge difference, since growpart will resize it anyway. |
|
|
Also doesn't appear to have `hostname` installed. |
|
|
@iwalker I got the @'s backwards in my message. I was intending to @ you that I saw the same as you (no lvm) in many images from upstream. Sorry for the confusion by swapping the @'s in the note. |
|
|
First off apologies on the LVM front - I saw something and jumped to a conclusion (the wrong one) that was incorrect as it turns out : On images of 8.5 and prior the filesystem is created by anaconda as below : [root@test85 ~]# lsblk -f NAME FSTYPE LABEL UUID MOUNTPOINT vda └─vda1 xfs 4c90d825-f649-4c1b-97b8-11f283331ef5 / vdb swap 50020188-cb9d-4df7-8e0e-2391886d4978 [SWAP] [root@test85 ~]# cat /etc/fstab # # /etc/fstab # Created by anaconda on Sun Nov 14 18:50:49 2021 # # Accessible filesystems, by reference, are maintained under '/dev/disk/'. # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info. # # After editing this file, run 'systemctl daemon-reload' to update systemd # units generated from this file. # UUID=4c90d825-f649-4c1b-97b8-11f283331ef5 / xfs defaults 0 0 /dev/vdb none swap sw,comment=cloudconfig 0 0 On the 8.6 image the filesystem is as below (quite different) : [root@test86 ~]# lsblk -f NAME FSTYPE LABEL UUID MOUNTPOINT vda ├─vda1 vfat EFI 49AB-A4B4 ├─vda2 └─vda3 xfs root ebb44e1a-2801-4e1e-a8c5-921204153736 / vdb swap b2e2ed61-7ca0-4c82-a2e7-fa945ec59adc [SWAP] [root@test86 ~]# cat /etc/fstab /dev/vdb none swap sw,comment=cloudconfig 0 0 I have bought up two test machines, one 8.5 and one 8.6, from the stock qcow2 images and got together the below list - these are the packages that were in 8.5 but are no longer in 8.6. There are no packages in 8.6 that did not exist in 8.5. abattis-cantarell-fonts.noarch audit.x86_64 authselect-compat.x86_64 authselect-libs.x86_64 authselect.x86_64 cairo-gobject.x86_64 cairo.x86_64 c-ares.x86_64 cronie-anacron.x86_64 cronie.x86_64 crontabs.noarch crypto-policies-scripts.noarch dejavu-fonts-common.noarch dejavu-sans-mono-fonts.noarch dmidecode.x86_64 dracut-config-rescue.x86_64 elfutils-debuginfod-client.x86_64 fontconfig.x86_64 fontpackages-filesystem.noarch gdk-pixbuf2.x86_64 geolite2-city.noarch geolite2-country.noarch gnupg2-smime.x86_64 gobject-introspection.x86_64 groff-base.x86_64 grubby.x86_64 hardlink.x86_64 hdparm.x86_64 hostname.x86_64 hwdata.noarch initscripts.x86_64 irqbalance.x86_64 kbd-legacy.noarch kbd-misc.noarch kbd.x86_64 kernel-tools-libs.x86_64 kernel-tools.x86_64 kpartx.x86_64 less.x86_64 libappstream-glib.x86_64 libdaemon.x86_64 libdhash.x86_64 libestr.x86_64 libfastjson.x86_64 libldb.x86_64 libmaxminddb.x86_64 libnl3-cli.x86_64 libnl3.x86_64 libpipeline.x86_64 libsecret.x86_64 libsoup.x86_64 libsss_autofs.x86_64 libsss_certmap.x86_64 libsss_idmap.x86_64 libsss_nss_idmap.x86_64 libsss_sudo.x86_64 libstemmer.x86_64 libsysfs.x86_64 libtalloc.x86_64 libtdb.x86_64 libteam.x86_64 libtevent.x86_64 libuser.x86_64 libX11-common.noarch libX11.x86_64 libXau.x86_64 libxcb.x86_64 libXext.x86_64 libxkbcommon.x86_64 libXrender.x86_64 lmdb-libs.x86_64 logrotate.x86_64 lshw.x86_64 lsscsi.x86_64 man-db.x86_64 memstrack.x86_64 microcode_ctl.x86_64 mozjs60.x86_64 NetworkManager-team.x86_64 NetworkManager-tui.x86_64 newt.x86_64 numactl-libs.x86_64 oddjob-mkhomedir.x86_64 oddjob.x86_64 openssl-pkcs11.x86_64 PackageKit-glib.x86_64 PackageKit.x86_64 parted.x86_64 passwd.x86_64 pciutils-libs.x86_64 pigz.x86_64 pinentry.x86_64 pixman.x86_64 platform-python-pip.noarch policycoreutils-python-utils.noarch polkit-pkla-compat.x86_64 polkit.x86_64 prefixdevname.x86_64 python3-cairo.x86_64 python3-decorator.noarch python3-gobject-base.x86_64 python3-gobject.x86_64 python3-linux-procfs.noarch python3-netifaces.x86_64 python3-perf.x86_64 python3-pexpect.noarch python3-ptyprocess.noarch python3-pydbus.noarch python3-pyudev.noarch python3-slip-dbus.noarch python3-slip.noarch python3-syspurpose.x86_64 python3-systemd.x86_64 python3-unbound.x86_64 rocky-logos.x86_64 rpm-plugin-selinux.x86_64 rpm-plugin-systemd-inhibit.x86_64 rsyslog.x86_64 selinux-policy.noarch selinux-policy-targeted.noarch setroubleshoot-plugins.noarch setroubleshoot-server.x86_64 sg3_utils-libs.x86_64 sg3_utils.x86_64 shared-mime-info.x86_64 slang.x86_64 sscg.x86_64 sssd-client.x86_64 sssd-common.x86_64 sssd-kcm.x86_64 sssd-nfs-idmap.x86_64 sudo.x86_64 teamd.x86_64 timedatex.x86_64 trousers-lib.x86_64 trousers.x86_64 tuned.noarch unbound-libs.x86_64 virt-what.x86_64 xkeyboard-config.noarch |
|
|
Seems strange, normally images are a single disk, and yet this mentioned vda for the main partition and vdb for swap (unless that was added later and not part of the initial Rocky image). As with all the other images I've mentioned, they were all single disks and partitions, no swap, so I think the Rocky image doesn't need this second disk or swap for that matter, it can only be more problematic this way. Generally, if I spin up an instance on Openstack or wherever (eg: other vps hosting platforms that spin up from an image), it's easy enough to add swap using fallocate and dropping the file on the main disk partition. |
|
|
You can safely ignore the vdb entries - they are a product of bringing up instances in openstack where the swap is defined in the flavor (which we do as standard through TerraForm) I was trying to illustrate that the regular partitioning standard that occurs at init typically is not happening in this case (with 8.6) |
|
|
Also to note that static IP assignment with generic cloud image fails with 8.6. With 8.5 it worked normally. Might be related to the same deficiencies listed above. |
|
|
Hi all, Thank you for the reports here and for your patience. I've got some new images cooking and should have them up later tonight! The short resolution is, as I should have known, "If it ain't broke, don't fix it" (: |
|
|
Please consider also one more thing in the new image creation. It is that "virsh console" does not work to a VM running 8.6 image on kvm hypervisor. I think it is because it is missing "console=ttyS0" in the kernel command line, but has "rhgb" which means graphical console. The console of 8.6 works when viewed through the graphical console of OpenStack but for most users it is important that "virsh console" would work as it has always been in earlier images. Rocky 8.5: $ dmesg |grep -i boot_image [ 0.000000] Command line: BOOT_IMAGE=(hd0,msdos1)/boot/vmlinuz-4.18.0-348.el8.0.2.x86_64 root=UUID=4c90d825-f649-4c1b-97b8-11f283331ef5 ro console=ttyS0,115200n8 no_timer_check net.ifnames=0 crashkernel=auto Rocky 8.6: $ dmesg |grep -i boot_image [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.18.0-372.9.1.el8.x86_64 root=UUID=ebb44e1a-2801-4e1e-a8c5-921204153736 ro rhgb selinux=0 audit=0 rw |
|
|
Apologies for pestering Neil but any guesstimate for when you would have new images available to download? :-) |
|
|
Noticed that there is a new image available (20220702.0) and in our tests the x86_64 version at least appears to be working as expected: - Static IP assignment working - virsh console access working - Ansible deployment in general (included sudo etc.) working Thanks! |
|
|
Looks good to me, deploys just like 8.5 through our ansible/openstack (which the original image did not). Cheers David |
|
|
Excellent news. Thank you everyone for your extreme patience with getting this fixed. In the future this will not be a problem. |
|
|
Looks good but I would just like to add - the image really needs virt-sparsify applied The original image is 2674917376, applying a sparsify myself brings that down to 1402798080 - that's a pretty epic difference |
|
|
Thanks Martin - I've compressed them by default. The new ones will come out sometime this week, pre-compressed. https://git.resf.org/sig_core/toolkit/commit/1f9468092453d9025fe57b570c615617f1904f0e |
|
|
Any progress on sparsified images please? https://download.rockylinux.org/pub/rocky/8/images/ only seems to have the `..0702` images still. |
- Anonymous
