public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Christoph Willing" <chris.willing@linux.com>
To: devel@edk2.groups.io, kraxel@redhat.com
Cc: James.Bottomley@hansenpartnership.com, ardb+tianocore@kernel.org,
	jiewen.yao@intel.com
Subject: Re: [edk2-devel] [PATCH 1/1] OvmfPkg PlatformBootManagerLib: Move TryRunningQemuKernel()
Date: Tue, 10 Aug 2021 22:10:27 +1000	[thread overview]
Message-ID: <ec88f2bc-4dc2-b735-4d20-ef37ff206d89@linux.com> (raw)
In-Reply-To: <20210810060150.2fjakuteasiujwmn@sirius.home.kraxel.org>

On 10/8/21 4:01 pm, Gerd Hoffmann wrote:
>   Hi,
> 
>> 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
>> ERROR: No /sbin/init found on rootdev (or not mounted). Trouble ahead.
>>        You can try to fix it. Type 'exit' when things are done.
>>
>> At that point I'm dropped into a recovery shell to try fixing something
>> but there's nothing that can be done since the disk containing the OS is
>> not visible.
> 
>> From the above, I think I've done everything possible to verify the
>> problem and a possible fix. Is there something fundamentally wrong in
>> the way I'm going about this?
> 
> Root cause is not clear.  Grab the kernel log ('dmesg') from a good and
> a bad boot and comparing them should give a clue.
> 
Thanks for your interest Gerd,

I added "-serial mon:stdio" to the qemu invocation and "console=ttyS0"
to the -append line to capture all boot output for both good and bad
cases and saved the results in files.

Rather than spam the list with those outputs, I've added them as
attachments to the bz report at
https://bugzilla.tianocore.org/show_bug.cgi?id=3504

When I first diff'd them, the slight difference in time stamps meant
every line showed up as different - real differences were hard to see.
Therefore I amended the files to replace the time stamps with "xxxx",
enabling diff to show actual differences more meaningfully.

I also attached there the output of a diff between the bad & good cases.
To be honest I can't see anything striking to explain the difference in
behaviour. To me, the main difference is that in the good case, an QEMU
HARDDISK & QEMU DVD-ROM are discovered and allows the system to boot but
no obvious indication why they are discovered in one case but not the
other. Apart from that, there are a few differences in some memory
locations being used but I have insufficient knowledge to judge whether
those differences are significant.

Is it possible for anyone to have a quick look through those files for
anything that may indicate what is causing the defective booting please?

Thanks,
chris

  reply	other threads:[~2021-08-10 12:10 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-28  2:02 [PATCH 0/1] OvmfPkg PlatformBootManagerLib: Move TryRunningQemuKernel() Christoph Willing
2021-07-28  2:02 ` [PATCH 1/1] " Christoph Willing
2021-08-09 13:08   ` [edk2-devel] " Ard Biesheuvel
     [not found] ` <1695D2E15A92C8E7.3876@groups.io>
2021-08-09 12:53   ` Christoph Willing
2021-08-09 14:52     ` James Bottomley
2021-08-10  0:10       ` Christoph Willing
2021-08-10  6:01         ` Gerd Hoffmann
2021-08-10 12:10           ` Christoph Willing [this message]
2021-08-10 14:26         ` James Bottomley
2021-08-10 23:04           ` Christoph Willing
2021-08-10 23:24             ` James Bottomley
2021-08-11  0:34               ` Christoph Willing
2021-08-11  6:12                 ` Gerd Hoffmann
2021-08-11  9:55                   ` Christoph Willing
2021-08-11 10:30                     ` Ard Biesheuvel
2021-08-12 12:41                       ` Christoph Willing
2021-08-12 13:36                         ` Gerd Hoffmann
2021-08-12 14:07                           ` Christoph Willing
2021-08-11  6:08           ` Gerd Hoffmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ec88f2bc-4dc2-b735-4d20-ef37ff206d89@linux.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox