Windows 10 LTSC 2019 endlessly spins hard drive instead of booting unless I unplug it

aitap

I have three hard drives, a, b and d:

Hard drive a is a 250GB IDE HDD connected with the help of an adapter. It has MBR partition table with three primary partitions, one extended and one logical. Long time ago it was NTFS-formatted, then coverted to ext3.
Hard drive b is a 1000GB SATA HDD. It has GPT partition table with a single LUKS partition. Some time ago GPT was converted to MBR and LUKS partition was shrunk to host a BIOS-booted Windows 7 installation. Later the change was reversed; now it has a single GPT partition with protective MBR again:

# dd if=/dev/sdb bs=1 skip=446 count=$((16*4)) 2>/dev/null | hd
00000000  00 00 01 00 ee fe ff ff  01 00 00 00 af 6d 70 74  |.............mpt|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000040
# fdisk -t mbr -l /dev/sdb
Disk /dev/sdb: 931,5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xe3701004

Device     Boot Start        End    Sectors   Size Id Type
/dev/sdb1           1 1953525167 1953525167 931,5G ee GPT
# gdisk -l /dev/sdb
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdb: 1953525168 sectors, 931.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): ████████-████-████-████-████████████

Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1953525134
Partitions will be aligned on 2048-sector boundaries
Total free space is 5485 sectors (2.7 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048      1953521663   931.5 GiB   8300  Linux filesystem

Windows 7 didn't have any of the problems described below.

Hard drive d is a 160GB SATA drive. It now has MBR partition table and hosts a BIOS-booted Windows 10 installation.

When I first tried to install Windows 10 on then-empty (all zeroes in MBR) hard drive d, installation image didn't boot past the windows logo with spinning dots. I waited for about 5-10 minutes; the HDD LED was kept on the whole time. I turned off the system and physically unplugged HDDs a and b. Installation proceeded normally without issues. When I plug the hard drives back and try to boot from HDD d again, the installed system exhibits the same symptoms.

I have not tried unplugging only one of the hard drives, but I think that Windows 10 is getting confused by HDD b, because a would produce much more noise.

Has anyone else encountered such problems? What can I try to fix this?

Tsaukpaetra

@aitap said in Windows 10 LTSC 2019 endlessly spins hard drive instead of booting unless I unplug it:

Has anyone else encountered such problems?

I had a similar issue when I cloned my hard drive and kept the original still plugged in. For some reason partitions managed to keep the same ID or something and Windows would boot the new drive using the original drive for the OS once it actually started Windows.

If you wait long enough, Windows should error out with a message (like, Inaccessible Boot Device or similar). Alternatively, I think if you have a com port and another computer handy to connect it to, you might be able to enable the serial console to see the boot process as well, though that's probably overkill.

What type of adapter is a using? Perhaps Windows is getting confused talking to it and can't initialise it properly. I've had that happen with shitty SATA-to-IDE converters.

aitap

@Tsaukpaetra said in Windows 10 LTSC 2019 endlessly spins hard drive instead of booting unless I unplug it:

If you wait long enough, Windows should error out with a message (like, Inaccessible Boot Device or similar).

Probably not "inaccessible boot device", since in my cases it was always accessible, be it a USB stick or a SATA HDD. I even found a case when plugging a specific harddrive would delay Windows 10 boot by about an hour, after which it would work as if nothing abnormal happened, but there was no solution and I didn't bookmark it.

I'll try to wait longer and see if anything interesting happens.

Alternatively, I think if you have a com port and another computer handy to connect it to, you might be able to enable the serial console to see the boot process as well, though that's probably overkill.

Hmm, I do have a CH340 USB-to-(TTL/serial) adapter with a jumper to switch between 3.3V and 5V (it should be 5V, right?) and there are COM pins described in the mainboard manual, so if all else fails, I could allocate some time next weekend and see what would EMS redirection tell me.

What type of adapter is a using? Perhaps Windows is getting confused talking to it and can't initialise it properly. I've had that happen with shitty SATA-to-IDE converters.

You are right, thank you! It only hangs on boot when I plug the a, not the b hard drive.

Then it's most probably caused by the "Orient 1S-1BN" adapter I'm using (pictures: 1 2; no official website I could find), since every time I touch it (when moving the hard drive between mainboards, for example), I almost literally have to perform dark magic rituals before it agrees to talk to the mainboard (instead of delaying POST by half a minute and not showing up in the device list at all). Though once it starts working, it's usually reliable.

I wonder what is so different in Windows 10 (as opposed to Windows 7 and Linux) that it prevents the adapter from working.

Unperverted Vixen

@aitap Did you use the same BIOS mode (UEFI vs legacy) for both Windows installs?

aitap

@Unperverted-Vixen, Yes, I always used BIOS (because I'm too lazy to install grub-efi instead of grub-pc and I want "other OS" options in GRUB menu to work).

@Tsaukpaetra, On the first try, Windows tried to start automatic recovery, but got a PNP_DRIVER_WATCHDOG BSOD. On the second try, Windows booted normally after about an hour of waiting. The event log is full of Reset to device, \Device\RaidPort0, was issued (source: storahci, ID: 129) and The IO Operation at logical block address 0x0 for disk 0 (PDO name: \Device\0000002c) was retried (source: Disk, ID: 153). I also cannot start diskmgmt.msc, it keeps "trying to connect to the virtual disk service..." with no results.

At this point I would conclude that the adapter was broken if it didn't work so well otherwise.

cvi

@aitap said in Windows 10 LTSC 2019 endlessly spins hard drive instead of booting unless I unplug it:

storahci

Wild-ass-guess: Could it be that your adapter doesn't support AHCI (well enough) but Windows 10 tries to talk AHCI to it? Linux might be falling back to PATA or whatever...

Tsaukpaetra

@aitap said in Windows 10 LTSC 2019 endlessly spins hard drive instead of booting unless I unplug it:

, I almost literally have to perform dark magic rituals before it agrees to talk to the mainboard

Ah, that's usually my first hint. Also almost anything drive related should be plug-n-play at this point, even IDE shouldn't throw too much of wrench into things (just make sure it's set to Master mode or cable select).
If it's that much trouble pre-OS I would have tossed it.

@aitap said in Windows 10 LTSC 2019 endlessly spins hard drive instead of booting unless I unplug it:

got a PNP_DRIVER_WATCHDOG BSOD. On the second try, Windows booted normally after about an hour of waiting. The event log is full of Reset to device, \Device\RaidPort0, was issued (source: storahci, ID: 129) and The IO Operation at logical block address 0x0 for disk 0 (PDO name: \Device\0000002c) was retried (source: Disk, ID: 153)

Yeah, the first error message essentially means "our plug-n-play service got stuck trying to initialize devices". The rest mean that Windows tried to talk to the disk and it never responded.

At this point I would conclude that the adapter was broken if it didn't work so well otherwise.

I think the "work so well otherwise" is a Stockholm syndrome indicator, especially considering the "perform dark magic rituals" statement above.

Consider the following: "my WiFi dongle works great! After I install it on XP compatibility mode and don't connect to any 802.11n or faster networks! Oh sure, it finds them well enough, but as soon as I try it freezes or crashes the system! But it works great otherwise!"
(real world scenario. Mother did not want to buy a newer dongle)

aitap

@cvi, there is no easy way to fix that, is it?

@Tsaukpaetra said in Windows 10 LTSC 2019 endlessly spins hard drive instead of booting unless I unplug it:

If it's that much trouble pre-OS I would have tossed it.

I had given up on it in the past once, but then I ended up in a situation where I could choose between trying the flaky adapter again and spending time restoring the backed up system image to a non-IDE hard drive. After I changed the jumper position back and forth and took it out and plugged back in a few times it suddenly started working.

But, ultimately, you are right. I've got to replace the adapter. Thank you for pointing me in the right direction.

JBert

@aitap said in Windows 10 LTSC 2019 endlessly spins hard drive instead of booting unless I unplug it:

But, ultimately, you are right. I've got to replace the adapter. Thank you for pointing me in the right direction.

I would replace the 250 GB IDE HDD with a SATA SSD, should give a nice speed boost as extra and might actually prevent disaster if the HDD is getting somewhat old.

Of course, I don't know your budget and your location (which could mean high hardware import costs), but with storage I'd rather be safe than sorry (similar to Power Supply Units).

cvi

@aitap said in Windows 10 LTSC 2019 endlessly spins hard drive instead of booting unless I unplug it:

there is no easy way to fix that, is it?

I don't know enough about Windows to really answer that. If you're dead set trying to make that thing work (or at least boot in both OSes), you could try the following.

See if you can disable AHCI in the bios. I remember that being an option at one point or another. No idea if a modern Windows supports that still. Either way, it maybe gives you a hint at whether AHCI-support is the problem or not. (If I had to disable AHCI for the whole system because one of the drives, I'd probably rather just replace the drive.)
See if you can disable that SATA port in the bios. I vaguely remember that Windows relies (or used to rely) on the information from the bios, whereas Linux enumerates the drives in a different way. So that could disable the particular port in Windows, allowing it to boot, while still remaining accessible in Linux (maybe).

No idea if either will work (or if that's even possible on your machine). Should be quick to test, though, and perhaps more importantly, easy to undo afterwards. Maybe also see if you get any weird messages about the drive in Linux (dmesg, and perhaps hdparm).