From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [96.44.175.130]) by mx.groups.io with SMTP id smtpd.web11.1036.1628605613909745891 for ; Tue, 10 Aug 2021 07:26:54 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@hansenpartnership.com header.s=20151216 header.b=mmo+FQXv; spf=pass (domain: hansenpartnership.com, ip: 96.44.175.130, mailfrom: james.bottomley@hansenpartnership.com) Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id EB19B128109A; Tue, 10 Aug 2021 07:26:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1628605612; bh=g0WXvt4RfLuQxV6kDsKCLiyWbiXnARAE1Cd7f+MV56I=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=mmo+FQXvKraHMM3lj4bZKFMuV06/3i4FAKeuzi4qeKv+bqwyOGgCxVSScKeJFatPe D5vJvhLizL4nnee0rjRw0wo3CFO6Wy7rjMOC/GOlbIxQDyx1ddygKglTN6Bl6jmAVj VfhPAGlpPYtQjhqdJFG2EacSO+Wa2OSMcHGl1zfM= Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8fCnEjQARtF; Tue, 10 Aug 2021 07:26:52 -0700 (PDT) Received: from jarvis.int.hansenpartnership.com (unknown [IPv6:2601:600:8280:66d1::527]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id 9496B1281099; Tue, 10 Aug 2021 07:26:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1628605612; bh=g0WXvt4RfLuQxV6kDsKCLiyWbiXnARAE1Cd7f+MV56I=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=mmo+FQXvKraHMM3lj4bZKFMuV06/3i4FAKeuzi4qeKv+bqwyOGgCxVSScKeJFatPe D5vJvhLizL4nnee0rjRw0wo3CFO6Wy7rjMOC/GOlbIxQDyx1ddygKglTN6Bl6jmAVj VfhPAGlpPYtQjhqdJFG2EacSO+Wa2OSMcHGl1zfM= Message-ID: <5c85a3f963d1ab7d20e177db9a07a73e82a0eed0.camel@HansenPartnership.com> Subject: Re: [edk2-devel] [PATCH 1/1] OvmfPkg PlatformBootManagerLib: Move TryRunningQemuKernel() From: "James Bottomley" To: devel@edk2.groups.io, chris.willing@linux.com Cc: ardb+tianocore@kernel.org, jiewen.yao@intel.com Date: Tue, 10 Aug 2021 07:26:51 -0700 In-Reply-To: <1b544f28-b5b9-c08c-bab7-8c1f41778dce@linux.com> References: <20210728020232.127332-1-chris.willing@linux.com> <1695D2E15A92C8E7.3876@groups.io> <62f9ffa0-786f-09dd-9546-c4c118fa2a17@linux.com> <1b544f28-b5b9-c08c-bab7-8c1f41778dce@linux.com> User-Agent: Evolution 3.34.4 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Tue, 2021-08-10 at 10:10 +1000, Christoph Willing wrote: > On 10/8/21 12:52 am, James Bottomley wrote: > > On Mon, 2021-08-09 at 22:53 +1000, Christoph Willing wrote: > > > With soft feature freeze started, I wonder if this patch could be > > > reviewed and pushed for edk2-stable202108 tag? I think it has > > > languished because I didn't initially Cc appropriately - pls add > > > others as necessary. > > > > > > This patch is a trivial (I think) change which fixes a long > > > standing > > > and annoying bug for those booting Qemu with UEFI using external > > > kernel & initrd. > > > > I'm with Ard on this one: -kernel is working just fine for me and > > the > > team at IBM working on Kata containers. It sounds like this might > > be a > > problem local to your environment, so we need to debug it to > > understand > > the issue rather than blindly reverse existing commits. > > > Thanks for responding James & Ard. > > Below is the script I'm using to create, then run, the VM. To verify > that it works normally with UEFI boot, it initially uses the internal > kernel & initrd. > > The OVMF_CODE & my_VARS lines contain git hash to identify the build > from which OVMF_CODE.fd & OVMF_VARS.fd were taken; 97fdcg is from a > build of yesterday's git master. > > After the OS has been installed, I can run the VM multiple times to > verify that it boots under UEFI OK (I see the TianoCore splash > screen) > with internal kernel. > > > #!/bin/bash > > /usr/bin/qemu-kvm \ > -name "UEFI Testing" \ > -enable-kvm \ > -cpu kvm64 \ > -smp cores=4 \ > -boot once=c \ > -m 8192 \ > -device intel-hda \ > -device hda-duplex \ > -vga virtio \ > -drive if=pflash,format=raw,file=OVMF_CODE_97fdcb.fd,readonly=on \ > -drive if=pflash,format=raw,file=my_VARS_97fdcb.fd \ > -drive file=disk.img,format=raw,cache=none,index=0,media=disk \ > -cdrom > /storage/iso/slackware/slackware64-15.0/slackware64-15.0-20210807.iso > \ > -daemonize \ > "$@" There's no definition of a disk device in here. > To now use external kernel, I add the lines: > > -kernel /var/cache/vmbuilder/boot/15.0/x86_64/vmlinuz \ > -initrd /var/cache/vmbuilder/boot/15.0/x86_64/initrd \ > -append "root=/dev/sda2 rootfstype=ext4 ro vga=0x386" \ > > to the script just after "-boot once=c" (but I doubt the exact > positioning makes any difference). > > In this case, I see the kernel running and initrd unpacked and its > modules loaded but the root partition is unable to be mounted - the > disk > is not visible (running 'ls -l /dev/sd*' in recovery shell gives 'ls: > /dev/sd*: No such file or directory'). > > The last lines of the Qemu screen are: > > /boot/initrd-5.13.8.gz: Loading kernel modules from initrd image: > insmod /lib/modules/5.13.8/kernel/fs/jbd2/jbd2.ko > insmod /lib/modules/5.13.8/kernel/fs/mbcache.ko > insmod /lib/modules/5.13.8/kernel/fs/ext4/ext4.ko > mount: mounting /dev/sda2 on /mnt failed: No such file or directory Which looks like why this failed. Where's the vmm supposed to get /dev/sda from? It sort of seems like the CD rom boot script thinks it was mounted as a USB device in this case. In the working kernel dmesg Gerd requested, what does it mount as root? sda? In which case what does the kernel say about where it got sda from? James