Inaccessible_Boot_Device after install

[BogdanV]

As the title suggests, I'm having a hard time trying to make my "HFSLIP-ed" install to work.

As a introductory note, I've followed Vorck's "Windows 2000 total slipstream" tutorial: http://www.vorck.com/windows/2ksp5.html, applied of course on a win2k setup.

My problem, as far as I've managed to track it, is the fact that the uniata driver fails to work on my PC (fact indicated by the "INACCESSIBLE_BOOT_DEVICE" stop message that "greeted" me immediately after install and the fact that on Virtual PC, it worked flawlessly, which lead me to believe that the problem is driver-related).

Since the default atapi driver works on my PC without any noticeable limitations on my SATA drive, I tried several methods of replacing uniata with atapi. Sadly, all failed.

What I tried:

1.Commented-out all entries relating to uniata in txtsetup.sif and layout.ini (as mentioned on Vorck's site). Result: either a "uniata.sys not found" halt error, or a setup that continuously popped-out false "file missing" reports during copy, coupled with a snail-ish install that never finished.

2.Tried renaming atapi.sys to uniata,sys, but setup's file protection "caught" me ("uniata.sys not found" halt error).

3.Compiled without deleting the "[uniata]" header in txtsetup.sif. It didn't work (can't remember exact behaviour though).

4.Installed in parallel a unmodified version of Win2k and tried changing the registry entries as per this site: http://www.mostlycreativeworkshop.com/Article11.html (it details on how to move a IDE drive to another PC, without throwing the "inaccessible_boot_device" stop message).

This last step worked half-way. It passed the "Windows loading" start-up screen and did a auto-reboot right after popping the cursor on a black background.

This is as far as I've managed to go. If anyone could lend me a helping hand in solving this issue, I'd be more than grateful !

[fdv]

If you did not change anything, the Inaccessable boot device wouldn't be from my fileset, actually.

If you download my fileset and did not modify it at all and ran HFSLIP, then all it does is look for the uniata file -- it does nothing else. You can comment uniata out of the file lists in TXTSETUP and LAYOUT.

The install WILL default to the regular, no-frills atapi driver.

If, however, you made changes to the TXTSETUP file and at any point uncommented any uniata sections, setup matched a uniata device string with the device string of your hard drive controller.

BTW... I don't understand how windows 2000's default atapi driver can work if you have a SATA drive. Did you install XP and find that XP's default atapi driver worked? 2000's default atapi driver just does not see SATA.

[BogdanV]

Sorry to reply after such a long time, but yes, I never had any problems running Win2k and XP on my machine. It always worked since I never had any clue about atapi and uniata until this thing hit me (oh and both installs were clean installs).

Hmm.., well, I do remember at one point in the tutorial mentioned in my first post I had to do the following:

Search for "[uniata]" (with brackets) in TXTSETUP and delete it. By doing this, you make it part of the [HardwareIdsDatabase] section. Now save and close the file.

.

That's the only modification I've done to TXTSETUP.

Edited February 15, 2009 by BogdanV

[BogdanV]

Okay. I compiled another CD without touching anything from the fdv files.

After launching the setup from WINNT32.EXE (didn't burn a CD) and rebooting, I end up with a "uniata.sys not found" setup error.

Rebooted and checked "$WIN_NT$.~LS". To my surprise, Setup didn't copy uniata, although I have included the file both in FDV and in Source, Source/I386, in .sys and .sy_ forms.

Once I've seen that, I copied the file in $WIN_NT$.~LS's I386 folder. It found uniata and carried on.

But..., when copying files, it started throwing quite a lot of "file not found, retry/ignore/skip" messages, all ranging from NT4ICONS.DLL to mrukill.sys and usbintel.sys (12 in total).

It passed over this and entered the graphical stage of Setup.

There, it started with SPCHAPI.INF not found and carried on in the hardware detection part with some files that I wasn't able to track in my HFSLIP folder and not even on my Win2k CD.

(They are: usbui.dll, swenum.sys and mga.sys)

Also in the detection part, it warned me that Setup was unable to initialize several network related installs.

Then, it carried on with the Regional Settings. After that, in the final phaze, it threw a file not found error regarding "desktop.scf" and after several seconds, it rebooted by itself!

All these happend with the following setup of my HFSLIP folder:

-Win2k SP4 I386, CDROM_IP.5, CDROM_NT.5, CDROM_SP4.TST ->SOURCE

-latest FDV files (downloaded from the forums) -> unpacked in FDVFILES

-uniata.sys + uniata.sy_ (renamed) ->HFSLIP/SOURCE and FDVFILES

As a note. uniata.sys was taken from ReactOS 0.3.8

Edited February 15, 2009 by BogdanV

[fdv]

After launching the setup from WINNT32.EXE

Setup is using DOSNET, which I don't include. Technically this will work for an IE free install, but my fileset, and HFSLIP, are optimized for CD installs. So, while this method does work, it produces the errors you note here... To avoid all problems, do NOT use the winnt32 method for installs.

[Brabant]

Did anyone have error 0x7B INACCESSIBLE_BOOT_DEVICE and get it solved? I use viamraid.sys to get 2k to install on an SATA drive with the 'single file driver' method (PCI\VEN_1106&DEV_3149 = "mySATAdevice").

The uniata stuff is left commented out because there's also a PCI\VEN_1106&DEV_3149 in that section.

Four different file versions of viamraid.sys all get through the txtmode of the setup and none of them any further. (I read about setting the drive in 'compatibility mode' but can't find that in the BIOS.)

Edit: The board does not have the 'compatibility' setting.

What to do?

Edited July 20, 2010 by Brabant

[Brabant]

Kankerzooi. [oemboottroep] vergeten.

Edited July 28, 2010 by Brabant

[billtodd]

Please forgive my vague memory about this (and my laziness in not refreshing it by running tests), but I may have had a similar problem after having updated the contents of \HF (in order to prune entries that had been superseded by post-1.7.9 patches) and then running the result with the 1.7.9 command file (I'm sure that doing so resulted in problems running the resulting .iso image from CD, where the size of the target 500 GB SATA drive got reported as 131 GB and the existing partitions on the drive were all reported as corrupt).

Clearly, removing those superseded patches (but leaving out the newer ones that had superseded them until the initial installation had completed, because I wasn't sure that the 1.7.9 command file could process them properly) had caused some updates needed DURING the installation to disappear. I seem to remember at one point forging ahead anyway and getting the boot device failure shortly thereafter.

Since then I've just used the 1.7.9 installation as-is and installed the later patches on top of the result without problems.