Windows NT 4.0 fails to boot from qcow2 installation

[John Arbuckle]

Windows NT 4.0 will not boot from an installation more than once if installed in a qcow2 image file. A quick fix to this problem is to use the qcow format instead.

Steps to reproduce this issue:

Create the image file:
qemu-img create -f qcow2 winnt4.qcow2 1G

Boot from a Windows NT 4.0 Workstation CD:
qemu-system-i386 -hda winnt4.qcow2 -cdrom /dev/cdrom -boot d -m 128 -cpu pentium -vga cirrus

During the installation process you have the choise between FAT and NTFS. You can pick anyone.

After finishing the installation the guest will reboot to install additional items. Once this is done the guest will be bootable. Eject any CD media from QEMU and reboot. You will then see Windows NT 4.0 booting up to the desktop. Go to "Start->Shut down" to shut down. Then when Windows is ready quit QEMU.

Now try to boot using this command:
qemu-system-i386 -hda winnt4.qcow2 -boot c -m 128 -cpu pentium -vga cirrus

The BIOS screen will display an error message:

For NTFS:
Booting from Hard Disk...
A disk read error occurred.
Insert a system diskette and restart
the system.

For FAT:
No bootable device.

Additional information:
qemu-system-i386 version: 2.10.1
qemu-img version: 2.10.92 (v2.11.0-rc4-dirty)

If you don't have a Windows NT 4.0 Workstation installation CD, you may download one from here:
https://winworldpc.com/product/windows-nt-40/40

[John Snow (jnsnow)]

If you do two identical installs with qcow2 and raw, do you see any differences with qemu-img compare afterwards that might indicate what could possibly have gone wrong?

[John Arbuckle (programmingkidx)]

> On Dec 8, 2017, at 1:41 PM, John Snow <email address hidden> wrote:
>
> If you do two identical installs with qcow2 and raw, do you see any
> differences with qemu-img compare afterwards that might indicate what
> could possibly have gone wrong?

I think what you want is for me to compare a broken qcow2 file with a working qcow file. I'm not sure how to do that but if you sent me directions I can send you the results.

I did try using the broken qcow2 file in a Windows XP VM. When I try to open the "Program Files" folder I see this error message: "D:\Program Files is not accessible. The file or directory is corrupted and unreadable". The WINNT folder does open.

I tried checking the disk with Windows XP's disk repair utility. It failed to complete and displayed this error message: "Windows was unable to complete the disk check".

>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1737194
>
> Title:
> Windows NT 4.0 fails to boot from qcow2 installation
>
> Status in QEMU:
> New
>
> Bug description:
> Windows NT 4.0 will not boot from an installation more than once if
> installed in a qcow2 image file. A quick fix to this problem is to use
> the qcow format instead.
>
> Steps to reproduce this issue:
>
> Create the image file:
> qemu-img create -f qcow2 winnt4.qcow2 1G
>
> Boot from a Windows NT 4.0 Workstation CD:
> qemu-system-i386 -hda winnt4.qcow2 -cdrom /dev/cdrom -boot d -m 128 -cpu pentium -vga cirrus
>
> During the installation process you have the choise between FAT and
> NTFS. You can pick anyone.
>
> After finishing the installation the guest will reboot to install
> additional items. Once this is done the guest will be bootable. Eject
> any CD media from QEMU and reboot. You will then see Windows NT 4.0
> booting up to the desktop. Go to "Start->Shut down" to shut down. Then
> when Windows is ready quit QEMU.
>
> Now try to boot using this command:
> qemu-system-i386 -hda winnt4.qcow2 -boot c -m 128 -cpu pentium -vga cirrus
>
> The BIOS screen will display an error message:
>
> For NTFS:
> Booting from Hard Disk...
> A disk read error occurred.
> Insert a system diskette and restart
> the system.
>
> For FAT:
> No bootable device.
>
> Additional information:
> qemu-system-i386 version: 2.10.1
> qemu-img version: 2.10.92 (v2.11.0-rc4-dirty)
>
> If you don't have a Windows NT 4.0 Workstation installation CD, you may download one from here:
> https://winworldpc.com/product/windows-nt-40/40
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1737194/+subscriptions

[David Lindsay (asmqb7)]

Hi,

I've been experiencing various disk I/O issues with Windows NT too, as well as with Windows 3.1. I think `-M isapc` may be to blame somehow.

I've documented my experiences over at https://bugs.launchpad.net/qemu/+bug/1745312.

That report contains information on how to lift out and build the before-and-after QEMU commits that I think relate to this being broken. John Arbuckle, perhaps you could run through that and see if you continue to have issues.

I was initially going to post that report as a comment in this thread, until I realized I was having I/O issues on multiple operating systems.

[John Arbuckle (programmingkidx)]

> On Jan 25, 2018, at 2:53 AM, i336_ <email address hidden> wrote:
>
> Hi,
>
> I've been experiencing various disk I/O issues with Windows NT too, as
> well as with Windows 3.1. I think `-M isapc` may be to blame somehow.
>
> I've documented my experiences over at
> https://bugs.launchpad.net/qemu/+bug/1745312.
>
> That report contains information on how to lift out and build the
> before-and-after QEMU commits that I think relate to this being broken.
> John Arbuckle, perhaps you could run through that and see if you
> continue to have issues.
>
> I was initially going to post that report as a comment in this thread,
> until I realized I was having I/O issues on multiple operating systems.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1737194
>
> Title:
> Windows NT 4.0 fails to boot from qcow2 installation
>
> Status in QEMU:
> New
>
> Bug description:
> Windows NT 4.0 will not boot from an installation more than once if
> installed in a qcow2 image file. A quick fix to this problem is to use
> the qcow format instead.
>
> Steps to reproduce this issue:
>
> Create the image file:
> qemu-img create -f qcow2 winnt4.qcow2 1G
>
> Boot from a Windows NT 4.0 Workstation CD:
> qemu-system-i386 -hda winnt4.qcow2 -cdrom /dev/cdrom -boot d -m 128 -cpu pentium -vga cirrus
>
> During the installation process you have the choise between FAT and
> NTFS. You can pick anyone.
>
> After finishing the installation the guest will reboot to install
> additional items. Once this is done the guest will be bootable. Eject
> any CD media from QEMU and reboot. You will then see Windows NT 4.0
> booting up to the desktop. Go to "Start->Shut down" to shut down. Then
> when Windows is ready quit QEMU.
>
> Now try to boot using this command:
> qemu-system-i386 -hda winnt4.qcow2 -boot c -m 128 -cpu pentium -vga cirrus
>
> The BIOS screen will display an error message:
>
> For NTFS:
> Booting from Hard Disk...
> A disk read error occurred.
> Insert a system diskette and restart
> the system.
>
> For FAT:
> No bootable device.
>
> Additional information:
> qemu-system-i386 version: 2.10.1
> qemu-img version: 2.10.92 (v2.11.0-rc4-dirty)
>
> If you don't have a Windows NT 4.0 Workstation installation CD, you may download one from here:
> https://winworldpc.com/product/windows-nt-40/40
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1737194/+subscriptions

I did try to build at commits 306ec6c3cece7004429c79c1ac93d49919f1f1cc and e689f7c668cbd9d08f330e17c3dd3a059c9553d3. Both failed to build on my Mac OS X system. Here is the error message I usually saw:

  LINK qemu-io
Undefined symbols for architecture x86_64:
  "_use_rt_clock", referenced from:
      _bdrv_acct_start in block.o
      _bdrv_acct_done in block.o
Undefined symbols for architecture x86_64:
      _qemu_clock_get_ns in qemu-timer.o
  "_use_rt_clock", referenced from:
      _bdrv_acct_start in block.o
      _bdrv_acct_done in block.o
      _qemu_clock_get_ns in qemu-timer.o

In your report you mention using the raw disk image format and VHD...

[Peter Maydell (pmaydell)]

On 25 January 2018 at 15:58, John Arbuckle <email address hidden> wrote:
> I did try to build at commits 306ec6c3cece7004429c79c1ac93d49919f1f1cc
> and e689f7c668cbd9d08f330e17c3dd3a059c9553d3. Both failed to build on my
> Mac OS X system. Here is the error message I usually saw:
>
> LINK qemu-io
> Undefined symbols for architecture x86_64:
> "_use_rt_clock", referenced from:
> _bdrv_acct_start in block.o
> _bdrv_acct_done in block.o
> Undefined symbols for architecture x86_64:
> _qemu_clock_get_ns in qemu-timer.o
> "_use_rt_clock", referenced from:
> _bdrv_acct_start in block.o
> _bdrv_acct_done in block.o
> _qemu_clock_get_ns in qemu-timer.o

If you configure with --disable-tools does it manage to build,
or does it just go on to fail to link the main QEMU binary
with the same error? (We've had some issues in the past I think
where configure put libraries on the main binary link line but
not on the tools link lines, so maybe worth a try...)

thanks
-- PMM

[John Arbuckle (programmingkidx)]

> # WinNT 4 Terminal Server
>
> Most of the time, NTLDR will fire up normally. But every so often...
>
> SeaBIOS (version rel-1.7.3-117-g31b8b4e-20131206_080705-nilsson.home.kraxel.org)
>
> Booting from Hard Disk...
> A disk read error occurred.
> Insert a system diskette and restart
> the system.
>
> (NB. You're seeing the old SeaBIOS version included with e689f7c, which was the first buggy commit.)
>
> If NT gets past this point without erroring out (ie, it makes it to the boot menu), the rest of the system is 100% fine and there are no other disk I/O issues whatsoever. For example, on QEMU 2.9.0 I was able to enable disk compression, answer "Yes" to "Compress entire disk now?" and have the process fully complete. No hitches.
>

I tried adding -M isapc to my Windows NT 4.0 VM's arguments and I saw the same error message at first. Then I tried it again by making a few changes. I played with the network card settings and removed the "-M isapc" argument to make things work again. Then I went back and added the "-M isapc" option again and Windows booted. I restarted several times and didn't see the error message. I am using qemu-system-i386 version 2.10.1. Just to see if I could see any of the disk errors you saw I ran in the command prompt "chkdsk c:" a couple of times. It came back with no errors every time.

[John Arbuckle (programmingkidx)]

> On Jan 25, 2018, at 11:16 AM, Peter Maydell <email address hidden> wrote:
>
> On 25 January 2018 at 15:58, John Arbuckle <email address hidden> wrote:
>> I did try to build at commits 306ec6c3cece7004429c79c1ac93d49919f1f1cc
>> and e689f7c668cbd9d08f330e17c3dd3a059c9553d3. Both failed to build on my
>> Mac OS X system. Here is the error message I usually saw:
>>
>> LINK qemu-io
>> Undefined symbols for architecture x86_64:
>> "_use_rt_clock", referenced from:
>> _bdrv_acct_start in block.o
>> _bdrv_acct_done in block.o
>> Undefined symbols for architecture x86_64:
>> _qemu_clock_get_ns in qemu-timer.o
>> "_use_rt_clock", referenced from:
>> _bdrv_acct_start in block.o
>> _bdrv_acct_done in block.o
>> _qemu_clock_get_ns in qemu-timer.o
>
> If you configure with --disable-tools does it manage to build,
> or does it just go on to fail to link the main QEMU binary
> with the same error? (We've had some issues in the past I think
> where configure put libraries on the main binary link line but
> not on the tools link lines, so maybe worth a try...)
>
> thanks
> -- PMM
>

It still fails to build:

Build commands: ./configure --disable-tools --target-list=i386-softmmu && make -j 4

QEMU at commit: 306ec6c3cece7004429c79c1ac93d49919f1f1cc

  LINK i386-softmmu/qemu-system-i386
Undefined symbols for architecture x86_64:
  "_use_rt_clock", referenced from:
      _bdrv_acct_start in block.o
      _bdrv_acct_done in block.o
      _qemu_clock_get_ns in qemu-timer.o
      _cpu_get_clock in cpus.o
      _cpu_enable_ticks in cpus.o
      _cpu_disable_ticks in cpus.o
      _icount_warp_rt in cpus.o
      ...
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [qemu-system-i386] Error 1
make: *** [subdir-i386-softmmu] Error 2

[Peter Maydell (pmaydell)]

On 25 January 2018 at 16:43, John Arbuckle <email address hidden> wrote:
>> On Jan 25, 2018, at 11:16 AM, Peter Maydell <email address hidden> wrote:
>> If you configure with --disable-tools does it manage to build,
>> or does it just go on to fail to link the main QEMU binary
>> with the same error?

> It still fails to build:

That's a shame. Thanks for testing. I guess there was a bug that
we fixed at some point but figuring out what the bug fix was and
backporting it to the commits to be tested is probably too much
effort to be worthwhile.

-- PMM

[David Lindsay (asmqb7)]

Hi John & others:

(3 separate things.)

1: Image formats

Regarding qcow, unfortunately there is no change if I use this format.

- Windows 3.1 initially hung at "Starting MS-DOS..."; upon restart it crashed when it decided it couldn't find COMMAND.COM (a frequent failure mode I forgot to mention).

- NT initially crashed with one of its famous disk read errors. Of course.

- After the initial NT crash, repeated QEMU reloads began showing the boot menu rather consistently, so I pointed my test harness to the qcow image. Of course, it crashed on the first try in the test harness :), then launched successfully 42 times before crashing again. This sort of behavior is pretty consistent with what happened with raw images.

I just did 77 runs with commit 306ec6c and the qcow image worked just as well as the raw image did.

One thing. I converted my raw disk images to qcow so I could test and reply somewhat more quickly. (Just stumbled on the new activity in the thread after manually checking a couple hours ago, glad I did!. I'm actually subscribed now :) )

It could be strongly argued that I should create _new_ disk images. But my three counter-arguments are that

 a) the storage format shouldn't influence the guest.
 b) I exhaustively tested the bisection point I found, and the "before" state is absolutely rock solid. I'd say I've tested 450+ consecutive good runs without any hitches at this point - the 350 runs I documented, and a hundred or so more that I did before that.
 c) it could be very well argued that QEMU-level errors have left corruption in the disk image. My argument here is to reiterate (b).

If anyone wants to strongly argue for creating new images, I can try that. *resigned grumble*

Also... is qcow working stably for you, with no issues? If it is I'm very fascinated to hear that.

And - you're using `-M isapc`, right? I find that if I don't, NT will hit a STOP error pretty much instantaneously (within the first few fractions of a second after it's obvious the kernel has initialized).

---

2: Bitness

The few error messages I saw in your build failure hinted at 64-bit incompatibility.

Well... I was able, at length, to get QEMU to build for 32-bit. It mostly boiled down to careful analysis of config-host.mak, removing -m64 and substituting -m32, and poking {C,LD}FLAGS until it compiled.

As I noted in the other thread, the built QEMU had a 100% broken TCG and required some form of hardware acceleration to even start correctly. In my case this was KVM.

Oh, also, on the subject of compilation - this isn't bitness-related, but QEMU's Makefiles accept the standard `V=2` for verbose build that shows the compilation commands. I'd imagine the result would probably be best attached as a file. I have no idea if this information will be useful to the QEMU developers.

---

3: Bisection

I initially thought to cram this info somewhere in the I/O report but decided against it due to that post's final length. But it could be relevant here.

Here's the approach I used to rapidly bounce back and forth and in search of the before-and-after "edges". I used this for the I/O issues discussed here and also for another issue (https://bugs.launchpad....

[John Arbuckle (programmingkidx)]

> On Jan 26, 2018, at 9:51 AM, David Lindsay <email address hidden> wrote:
>
> Hi John & others:
>
> (3 separate things.)
>
> 1: Image formats
>
> Regarding qcow, unfortunately there is no change if I use this format.
>
> - Windows 3.1 initially hung at "Starting MS-DOS..."; upon restart it
> crashed when it decided it couldn't find COMMAND.COM (a frequent failure
> mode I forgot to mention).

I have tried using Windows 3.1 in QEMU in the past. It was a long time ago so I will have to go back and try it again. Hopefully one of the files here would help: https://winworldpc.com/product/windows-3/31

>
> - NT initially crashed with one of its famous disk read errors. Of
> course.
>
> - After the initial NT crash, repeated QEMU reloads began showing the
> boot menu rather consistently, so I pointed my test harness to the qcow
> image. Of course, it crashed on the first try in the test harness :),
> then launched successfully 42 times before crashing again. This sort of
> behavior is pretty consistent with what happened with raw images.
>
> I just did 77 runs with commit 306ec6c and the qcow image worked just as
> well as the raw image did.

Have you tried the latest commit or release of QEMU yet?

> It could be strongly argued that I should create _new_ disk images. But
> my three counter-arguments are that
>
> a) the storage format shouldn't influence the guest.

This is what I thought. But this is just a theory. It doesn't work in real life.

> b) I exhaustively tested the bisection point I found, and the "before" state is absolutely rock solid. I'd say I've tested 450+ consecutive good runs without any hitches at this point - the 350 runs I documented, and a hundred or so more that I did before that.
> c) it could be very well argued that QEMU-level errors have left corruption in the disk image. My argument here is to reiterate (b).
>
> If anyone wants to strongly argue for creating new images, I can try
> that. *resigned grumble*
>
> Also... is qcow working stably for you, with no issues? If it is I'm
> very fascinated to hear that.

That is correct. I went back to QEMU 0.9 and tried a bunch of releases to around 2.x until I realized it was the image file that was the problem. I must have installed Windows NT 4.0 around 20 times before finding the answer to my problem.

> And - you're using `-M isapc`, right? I find that if I don't, NT will
> hit a STOP error pretty much instantaneously (within the first few
> fractions of a second after it's obvious the kernel has initialized).

Actually I like using the PCI network cards so I never had a reason to use "-M isapc" until you contacted me. Windows NT 4.0 runs rock solid for me without it. The only issue I noticed is when I play StarCraft in my Windows NT 4.0 VM, the mouse starts moving around erratically after around 45 minutes of use.

> 2: Bitness
>
> The few error messages I saw in your build failure hinted at 64-bit
> incompatibility.
>
> Well... I was able, at length, to get QEMU to build for 32-bit. It
> mostly boiled down to careful analysis of config-host.mak, removing -m64
> and substituting -m32, and poking {C,LD}FLAGS until it compiled.
>
> As I noted in the other thread...

[John Arbuckle (programmingkidx)]

I have installed Windows 95 OSR 2.5 in QEMU using the qcow2 format. So far there hasn't been any major problems that prevent Windows from booting.

I downloaded the ISO file from here: https://winworldpc.com/product/windows-95/osr-3

Used this floppy boot image to boot QEMU: https://winworldpc.com/product/microsoft-windows-boot-disk/95-osr2x

Created the hard drive image file like this: qemu-img create -f qcow2 ~/windows95.qcow2 2G

I used my Windows XP VM to format this qcow2 file to the FAT format.

My first attempt to boot the hard drive image file failed probably because the CPU was set to something Windows 95 couldn't handle properly. Changing the cpu to a pentium removed the booting problem.

This is the command-line I used to boot Windows 95:
qemu-system-i386 -hda windows95.qcow2 -boot c -netdev user,id=mynet0 -device ne2k_isa,netdev=mynet0 -soundhw sb16 -m 32 -cpu pentium -vga cirrus -localtime

The version of QEMU I used is today's git version (commit e607bbee553cfe73072870cef458cfa4e78133e2).

[Thomas Huth (th-huth)]

The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.

[Launchpad Janitor (janitor)]

[Expired for QEMU because there has been no activity for 60 days.]