Jump to content

RootWyrm

Members
  • Posts

    9
  • Joined

  • Last visited

Profile Information

  • Gender
    Male
  • OS
    Windows 7 x64

RootWyrm's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. EDIT - whoops, I meant to post up one level as this is 1.5.4.. can someone please move? Thanks! F:\7Toolkit>chcp 65001F:\7Toolkit>Set SEE_MASK_NOZONECHECKS=1F:\7Toolkit>"C:\Windows\WinToolkit_Temp\cdimage.exe" -L"Shrike_Gen6" -m -o -u2 -udfver102 -h -bootdata:2#p0,e,b"C:\Windows\WinToolkit_Temp\BIOS.com"#pEF,e,b"C:\Windows\WinToolkit_Temp\UEFI.bin" "F:\7Toolkit\_WorkingImage" "D:\shrike_gen6.iso"OSCDIMG 2.56 CD-ROM and DVD-ROM Premastering UtilityCopyright (C) Microsoft, 1993-2012. All rights reserved.Licensed only for producing Microsoft authorized content.Scanning source treeScanning source tree complete (1995 files in 319 directories)Computing directory informationComputing directory information completeImage file is 5338038272 bytes (before optimization)Writing 1995 files in 319 directories to D:\shrike_gen6.isoReadFile failed (\\?\F:\7Toolkit\_WorkingImage\autorun.inf, off=0 len=800 status=103)Error 87: The parameter is incorrect.Checked the autorun.inf and it looks fine to me.. I can't find any issues. Builds just fine in AIO and WIM rebuild returns no errors. Any ideas? This is a pretty hefty install of 7 Ultimate, but it's far from the biggest I've done.
  2. that's responsible for the X79 C600 mass storage device. I offered you a simple solution to modify the .infs so they are integratable with Win Toolkit; if you have another, that's great. But don't expect Legolash to update his app soon, and do this by default (detect those drivers as also windows 7 compatible without other changes), as he's gone for a very long time now. This is incorrect. While X79 / C600 is Patsburg, there are not two drivers - there are four. X79 is IRST, RSTe. C600 is SCU+RSTe or SCU, depending on PCH Strap 16. (C606 can also operate as RSTe if the SCU ports are configured as SATA and not SAS.) This all comes from the fact that the X79 and C600 are not the same chipset. Remember that the X79 was supposed to ship with quad SAS/SATA-III ports in addition to the base six, but that got nixed due to silicon defects. It's still nixed, in fact. So on an X79 your controller layout is this: X79 PCH -> SATA (IDE, AHCI, IRST, RSTe) On a C606 your controller layout is THIS: C606 PCH -> SATA A, PCH Config -> SCU A+B (two units, 4 ports each, common BAR) -> SCU Mode So your information is absolutely incorrect: a properly configured C606 has (all VEN_ID 8086) any one of 1D00-1D06, two instances 1D40 or 1D41, one or two instances 1D54 or 1D55 or 1D58, two to four 1D22, etc. You get the idea. It is not and never has been a single device on C600 and C600 is not equivalent or equal to X79. It'd probably take me an hour to draw out all the permutations of C606 configuration. Suffice to say, the SCU setup complicates things substantially and there's not a lot of folks out there who have access to or can test multiple C600 boards. Plus because the SCUs are configured by PCH Soft Strap, the C606 has a single SKU for over a dozen operational modes including SATA passthrough, limited RSTe and ROMB keyed RAID. And depending how smart or stupid your motherboard manufacturer is, it may or may not be sensitive to load order. For maximum "WTF" factor you can put two Supermicro C606 boards side-by-side and observe as one uses RSTe 12.x (SATA Passthrough) while the other uses SCU 3.7+. Even more WTF: combine Shrike Gen6 (SCU 3.8 UEFI) with the same physical board (RSTe 12.x UEFI + SCU 3.7 Legacy) - just from BIOS. I do appreciate the fix and did put it into play, but my greater concern is that as time goes on, we're going to see more drivers and INFs taking this route, hence why it's flagged up as a bug. This is unlikely to be the last occurrence, and the SCU INF is relatively straightforward. Other ones, substantially less so, to put it mildly. So hopefully Legolash will be able to get a fix in at some point in the future. There's obviously no huge rush, but it's definitely something that people need to be aware of and is going to require some longer term considerations.
  3. This is false. You are confusing IRST (Intel Rapid Storage / Rapid Response crap) with the SCU driver. These are not the same. They are not related. RSTe has nothing to do with SCU. If you attempt to equate SCU with RSTe, you're just plain wrong, even though the C606's SCU identify as RSTe. It is fundamentally and completely incompatible. IRST absolutely does not work with the SCU; enabling IRST either disables the ports completely (-D config) or forces to AHCI SAS (some -T configs) with no boot capability. This bug will immediately impact any and all C600 boards, worst being C606's (e.g. Gigabyte GA-X79S-UP5-WIFI and Supermicro X9SRi-3F.) The C606 can operate in two modes off a single SKU, too - D and T modes. D enables the SCU as a SAS controller, T enables the SCU as a SATA controller, both in a 2x4 arrangement. (2 SCU bundles of 4 ports using a common PCIe BAR.) In a T+SCU-SATA RAID config, you must use F6 SCU and all drivers must load in the correct order. If you load iaStorS after iaStorF, it can't establish communication with the SCU. More to the point, it is in fact, a bug that will need addressed as more Windows 8 drivers are released. The simple fact is that it's indicative of probable misinterpretation of the INF. And that's the 'best practices' way to deal with a driver which is common between 7/8, according to what I've been told. So basically, more drivers are going to have that sort of INF layout. Thankfully, the fix is relatively simple. Half-baked pseudocode example: if "[INTEL.NTamd64.6.2]" -> // Check for specific driver assignment. check_string [*sys, *cat] if check_string = 1 { // Not found, but found Windows 8 support. if "[INTEL.NTamd64.5.2]" check_string [*sys, *cat] if check_string = 1 { // Not found, so no Windows support bailout; // Can't use it. } else { support_add (Windows_8, Windows_7) } fi fifi
  4. No, it is not an INF error. I checked the INFs. The INF in fact, does not specify any drivers for Windows 8. Relevant bits: [Version] Signature = "$Windows NT$" Class=SCSIAdapter ClassGUID={4D36E97B-E325-11CE-BFC1-08002BE10318} Provider=%INTEL% CatalogFile=iaStorS.cat DriverVer=09/03/2013,3.8.0.1108; [PackageInfo] Name=SCU[SourceDisksFiles.amd64] iaStorS.sys = 1,,, iaStorF.sys = 1,,, ; [INTEL.NTamd64.6.2] ;windows_8_64-bit ; [INTEL.NTamd64.5.2] ;server_2003_enterprise_x64 %Intel_SAS_RAID.Desc% = Intel_SCU_iaStorS_Inst,PCI\VEN_8086&DEV_1D60 %Intel_SATA_RAID.Desc% = Intel_SCU_iaStorS_Inst,PCI\VEN_8086&DEV_1D61 %Intel_SAS_RAID.Desc% = Intel_SCU_iaStorS_Inst,PCI\VEN_8086&DEV_1D62 %Intel_SAS_RAID.Desc% = Intel_SCU_iaStorS_Inst,PCI\VEN_8086&DEV_1D63 %Intel_SAS_RAID.Desc% = Intel_SCU_iaStorS_Inst,PCI\VEN_8086&DEV_1D64 %Intel_SAS_RAID.Desc% = Intel_SCU_iaStorS_Inst,PCI\VEN_8086&DEV_1D65 %Intel_SAS_RAID.Desc% = Intel_SCU_iaStorS_Inst,PCI\VEN_8086&DEV_1D66 %Intel_SAS_RAID.Desc% = Intel_SCU_iaStorS_Inst,PCI\VEN_8086&DEV_1D67 %Intel_SAS_RAID.Desc% = Intel_SCU_iaStorS_Inst,PCI\VEN_8086&DEV_1D68 %Intel_SAS_RAID.Desc% = Intel_SCU_iaStorS_Inst,PCI\VEN_8086&DEV_1D69 %Intel_SATA_RAID.Desc% = Intel_SCU_iaStorS_Inst,PCI\VEN_8086&DEV_1D6A %Intel_SATA_RAID.Desc% = Intel_SCU_iaStorS_Inst,PCI\VEN_8086&DEV_1D6BSo, as I said, it's a detection bug in that it's keying off the INTEL.NTamd64.6.2 and ignoring the INTEL.NTamd64.5.2.
  5. This one's got me scratching my head. The only explanation I can come up with is that WTK is not properly integrating the F6 driver due to incorrect detection. Either way, the incorrect detection is a fairly serious problem in and of itself. You'll want to grab Intel SCU F6 drivers, version 3.8.0.1108 (latest as of this writing.) In WTK the drivers detect as follows: iaAHCI.INF SCSIADAPTER x64 7, 8 9/3/2013 3.8.0.1108iaAHCIB.inf SCSIADAPTER x64 7, 8 9/3/2013 3.8.0.1108iaStorS.inf SCSIADAPTER x64 Win 8 9/3/2013 3.8.0.1108 <-- Whoops!iaStorA.inf SCSIADAPTER x64 7, 8 9/3/2013 3.8.0.1108iaStorB.inf SCSIADAPTER x64 7, 8 9/3/2013 3.8.0.1108Well, one, iaStorS.inf is definitely the Windows 7 version. Manual load confirms it. Secondly, the set doesn't seem to be working as a whole. It should be noted, these are the REPLACEMENT set for RSTe and exclusively for the C600 chipset. And yes, you actually need ALL of them. In roughly that order. (I'm not clear on whether iaAHCI can go after iaAHCIB+iaStorS. But iaStorS has to go first if you want to boot off SAS, even though Windows says it can't. It can.) Instead, when I boot from an image using that load, I get zero disks until I manually load the F6 drivers off another USB drive. Which of course, completely breaks my autounattend.xml - and yes, the load order of the drivers is EXTREMELY critical with this board. Otherwise, you WILL end up with the SATA before the SAS - reverse disk order - which breaks booting. It's very hard to overstate the extreme severity of this problem for C600-series boards. No load, you're dead in the water. EDIT: Because I obviously derped and forgot to mention - I did check the boot.wim file with DISM - none of these are getting loaded in there. Manually adding them to the WIM with DISM of course, fixes it. (Ignoring other major faults with the broken BIOS.)
  6. Hm, here's an interesting one for you.. I have a workstation I want to autounattend which has a total of two physical disks; an SSD and a RAID set. Now my understanding has been that I would do this: <settings pass="windowsPE"> <component name="Microsoft-Windows-Setup" ...> <DiskConfiguration> <WillShowUI>Always</WillShowUI> <!-- Force confirm wipes --> <Disk> <DiskID>0</DiskID> <!-- C: and Recovery, first disk --> ... misc config bits <CreatePartition> <ModifyPartition> ... <DiskID>1</DiskID> <!-- Second Disk, D: and E: --> ... misc config bits <CreatePartition> <ModifyPartition> ... </Disk> </DiskConfiguration>... but this continually fails WSIM validation claiming that "DiskID 0 already exists." I can't prep on an identical machine, but the machine I'm attempting to validate on also has two physical drives with 4 partitions. Is this just WISM being weird or do I have it wrong? If so, how do I set it up for multiple disks properly? <Disk><DiskID>0</DiskID>...</Disk> <Disk><DiskID>1</DiskID>...</Disk>?
  7. I can confirm this bug in latest build as well, currently hosing my AMD CCC integration. Tried with and without spaces, lots of different names, same results every time. In my case, it's a bit weirder. Latest available build copies ALL files except for Setup.exe. I can also confirm this is a new bug as of 1.4.1.22 - using the same setup with 1.4.1.21 works without any issues at all.
  8. Oh, and probably also a relevant element, the disk setup portion of the autounattend.xml - yes, manually added. Should also note, this is only occurring with W7TK prepared images. <DiskConfiguration> <!--Debugging--> <WillShowUI>Always</WillShowUI> <Disk> <!-- C602_SAS0,0 --> <DiskID>0</DiskID> <CreatePartitions> <CreatePartition wcm:action="add"> <!--Recovery Partition--> <Order>1</Order> <Type>Primary</Type> <Size>128</Size> </CreatePartition> <CreatePartition wcm:action="add"> <!-- C:, %SystemDrive% --> <Order>2</Order> <Type>Primary</Type> <Extend>true</Extend> </CreatePartition> </CreatePartitions> <ModifyPartitions> <ModifyPartition wcm:action="modify"> <Active>true</Active> <Extend>true</Extend> <Format>NTFS</Format> <Label>LocalSSD</Label> <Letter>C</Letter> <PartitionID>2</PartitionID> <Order>2</Order> </ModifyPartitions> <!-- C602_RAID5,0 --> <DiskID>1</DiskID> <CreatePartitions> <CreatePartition wcm:action="add"> <!-- D:, %UserProfiles%, $VMTGT --> <Order>1</Order> <Type>Primary</Type> <Size>768000</Size> </CreatePartition> <CreatePartition wcm:action="add"> <!-- E:, $DBSTOR --> <Order>2</Order> <Type>Primary</Type> <Size>1048576</Size> </CreatePartition> </CreatePartitions> <ModifyPartitions> <ModifyPartition wcm:action="modify"> <Active>false</Active> <Format>NTFS</Format> <Label>RAID5_0</Label> <Letter>D</Letter> <Order>1</Order> <PartitionID>1</PartitionID> </ModifyPartition> <ModifyPartition wcm:action="modify"> <Active>false</Active> <Format>NTFS</Format> <Label>RAID5_1</Label> <Letter>E</Letter> <Order>2</Order> <PartitionID>2</PartitionID> </ModifyPartitions> </Disk> </DiskConfiguration> <WindowsDeploymentServices> <ImageSelection> <InstallTo> <DiskID>0</DiskID> <PartitionID>1</PartitionID> </InstallTo> </ImageSelection>
  9. I've been trying to use W7Toolkit to automate certain complicated installations, but I've run into a really bad problem with Windows 7 SP1 and the Autounattend.xml not doing %UserProfiles% correctly. System installs just fine, but on first boot it's unusable reporting all User Profiles are inaccessible. So it's definitely not being set correctly. And installing them to the right drive is critically important - if they go on the wrong drive, bad things happen. This is occurring with DiskConfiguration settings and with partially manual installation which guarantees the correct disk letters. Here's the relevant portions from my Autounattend.xml <FolderLocations> <ProfilesDirectory>D:\Users\</ProfilesDirectory> </FolderLocations> For all users, it just throws "The User Profile Service failed the logon". This includes Administrator and created users. Checking disk contents reveals that there is a D:\Users\Administrator and so on. Any ideas? (Derp: typing by hand leads to silly mistakes. Fixed typo that is not present in autounattend.xml.)
×
×
  • Create New...