Jump to content

RootWyrm

Members
  • Content Count

    9
  • Joined

  • Last visited

About RootWyrm

  • Rank
    Wanderer

Profile Information

  • Gender
    Male
  • OS
    Windows 7 x64
  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 treeScanni
  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
  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.
  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.
  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,
  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> ...
  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&g
  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.
×
×
  • Create New...