Bug 1911177 - virt-builder + virt-install creates a VM that cannot boot fedora 33
Summary: virt-builder + virt-install creates a VM that cannot boot fedora 33
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: libguestfs
Version: 33
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Richard W.M. Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-12-28 04:33 UTC by John Schmitt
Modified: 2021-03-21 14:34 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2021-03-21 14:34:01 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
picture of the failed boot process for virtual fedora33 instance (86.58 KB, image/png)
2021-01-12 21:40 UTC, Mike C
no flags Details

Description John Schmitt 2020-12-28 04:33:59 UTC
Description of problem: I can create a fedora 32 VM successfully with virt-builder and virt-install. The fedora 33 VM I create with these steps fails to boot.


Version-Release number of selected component (if applicable):

Version     : 1.43.2
Release     : 2.fc33


How reproducible: Always


Steps to Reproduce:

This script will successfully create a VM that boots to a login prompt:

#!zsh

set -e
set -x
set -u
set -o pipefail

IMAGES_PATH=.
OS=fedora-32
OS_VARIANT=fedora32
OS_IMAGE=${OS}.qcow2

virt-builder ${OS}                                 \
    --output ${IMAGES_PATH}/${OS_IMAGE}            \
    --ssh-inject root:file:${HOME}/.ssh/id_rsa.pub \
    --root-password password:password

echo

virt-install                  \
    --connect qemu:///system  \
    --name ${OS}              \
    --ram 2048                \
    --vcpus 2                 \
    --nographics              \
    --os-variant ${OS_VARIANT}\
    --network none            \
    --import                  \
    --disk path=${IMAGES_PATH}/${OS_IMAGE}





This script will create a VM that prompts for a root password to enter a rescue shell. The root password provided does not allow me to launch the rescue shell:

#!zsh

set -e
set -x
set -u
set -o pipefail

IMAGES_PATH=.
OS=fedora-33
OS_VARIANT=fedora33
OS_IMAGE=${OS}.qcow2

virt-builder ${OS}                                 \
    --output ${IMAGES_PATH}/${OS_IMAGE}            \
    --ssh-inject root:file:${HOME}/.ssh/id_rsa.pub \
    --root-password password:password

echo

virt-install                  \
    --connect qemu:///system  \
    --name ${OS}              \
    --ram 2048                \
    --vcpus 2                 \
    --nographics              \
    --os-variant ${OS_VARIANT}\
    --network none            \
    --import                  \
    --disk path=${IMAGES_PATH}/${OS_IMAGE}

Comment 1 Mike C 2021-01-12 21:40:53 UTC
Created attachment 1746816 [details]
picture of the failed boot process for virtual fedora33 instance

Comment 2 Mike C 2021-01-12 21:43:54 UTC
I'm having the same issue with a very similar script. Fedora 32 boots fine but fedora 33 fails with:

"[FAILED] Failed to start Switching Root.

See 'systemctl status initrd switch root.service' for details."

If do not bring up the console right away you might not see the above message.

I've attached an image of the error I'm seeing.

thanks,
Mike

Comment 3 Richard W.M. Jones 2021-01-13 08:47:16 UTC
I just kicked off another build of the Fedora 33 template in the hope that
whatever was broken in Fedora before is now fixed.

Comment 4 Richard W.M. Jones 2021-01-13 09:15:07 UTC
That didn't work.  There's something broken in Fedora that prevents virt-install
installations from working.  I wasn't able to work out what had gone wrong last
time, but enabling debugging to try to get to the true error (somehow) would
be helpful.

Comment 6 Richard W.M. Jones 2021-01-13 12:42:42 UTC
Seems as if we have a fix now.  Try revision 2 of the image which virt-builder
should pull automatically.

Comment 7 Mike C 2021-01-14 14:51:01 UTC
Success! Thanks for taking a look at this and getting it fixed... using virt-builder makes everything so much easier for quick homelab deployments! I was going to test it yesterday but got sidetracked several times...

I wasn't the original poster of this bug but it's working for me...

thanks,
Mike

Comment 8 Richard W.M. Jones 2021-03-21 14:34:01 UTC
This has been fixed for a while, closing.


Note You need to log in before you can comment on or make changes to this bug.