Jump to content

Mr_Smartepants

Members
  • Posts

    807
  • Joined

  • Last visited

  • Days Won

    6

Posts posted by Mr_Smartepants

  1. The clue would be in how the ISO is mastered at the end.  Apparently, this is a known problem with ISO tools like PowerISO (UltraISO is unaffected) where the UEFI boot files are replaced by BIOS boot files as a default.

    I'm willing to bet that W7T is using Etfsboot.com as the default El Torito boot sector file for the ISO master which would make it non-bootable on UEFI systems.

    The AIK tool OSCDIMG is also unaffected, though requires designating the boot file.  I use it in my tool with the following:

    REM (On UEFI: -bC:\winpe_x86\Efisys.bin) (On BIOS: -bC:\winpe_x86\Etfsboot.com)IF /I "%arch%"=="UEFI" (SET "bootfile=EFISYS.BIN") ELSE (SET "bootfile=ETFSBOOT.COM")IF /I EXIST "%src%\boot\%bootfile%" (SET "srcb=%src%\boot") ELSE (ECHO No valid boot file found to build ISO. & GOTO EXIT)"%OSCDIMG%" -b"%srcb%\%bootfile%" -u2 -h -m -l"%iso-name%" "%src%" "%outputDir%\%iso-name%.iso"

     

     
  2. What you need to be careful of with the 2.5" Passport series is that they no longer stick a SATA-USB converter board in a case with a standard SATA drive. Their USB controller is soldered directly onto the drive itself, so you can't remove the drive and connect it directly to a PC via SATA anymore.

    If the drive fails, your data recovery bill just doubled because of that.

    Don't use it as your ONLY backup.

    I follow the 3-2-1 backup solution.

    3 backups of critical data.

    2 different backup media (HDD/Tape/Online/DVD/etc.)

    1 of the backups is off-site (online/cloud/mom's house/ etc.)

  3. My point was that the 45MB language pack the OP selected will only integrate into the install.wim, NOT the boot.wim. The boot.wim language modifications need to come from (in his scenario) the following directory:

    C:\Program Files\Windows AIK\Tools\PETools\x86\WinPE_FPs\TR-TR\

    - LP_TR-TR.CAB

    - WINPE-SETUP_TR-TR.CAB

    - WINPE-SETUP-CLIENT_TR-TR.CAB

    As pointed out in the link I posted, certain other languages (not his) also require the winpe-fontsupport-xx-yy.cab in order to display the setup info in the right font.

    Also need to use the /gen-langini to recreate the correct language listings for setup.

    In the screenshots the OP posted, there is no indication that the language-specific WinPE packages were integrated.

    If these aren't integrated, then during setup the only available language to select would be "English".

    That's all I meant. :-)

  4. Looks like you didn't integrate any of the PE Setup language packs.

    The boot.wim requires very special handling for language integration.

    Instructions:

    Walkthrough: Add Multilingual Support to Windows Setup (WAIK):  http://technet.microsoft.com/en-us/library/dd799268(WS.10).aspx

  5. Would it not be easier (legally) to just create a utility (batch script, vbs script, java script, .NET, or whatever) to extract the contents of a Win7.iso (w/SP1) to a working folder, then extract the Win7 updates from the other .iso (http://support.microsoft.com/kb/913086) and use DISM to integrate the updates into each image and effectively rebuild the original into an updated "vanilla" Win7.iso?

    I'm not talking about Win7Toolkit (which is infinitely more versatile!) but something super-simple that a user can download both .iso files, run the script, then 2 hours later be presented with a vanilla Win7 updated disc?

    I've already done something similar for a company (code protected by NDA or I'd release it here) and the entire codebase is less than 1000 lines.

    My early work from last year is here: http://forum.driverp...pic.php?id=5199

    Just another line-of-attack to achieve the same result. ;)

  6. Yes, this is a known problem.

    I integrate it post-install with Add-to-iso\sources\$oem$\$$\Setup\scripts\setupcomplete.cmd

    @ECHO off & setlocal EnableDelayedExpansion
    SET "LOGFILE=%systemdrive%\install.log"
    for %%i in (C D E F G H I J K L M N O P Q R S T U V W X Y Z) do if exist %%i:\sources\install.wim set CDROM=%%i:
    ECHO>>"%LOGFILE%" 2>>&1 Found CD-Rom as drive %CDROM%

    :PROCESSOR
    :: Detect OS bit-ness on running system. Assumes 64-bit unless 64-bit components do not exist.
    SET "ARCH=64"
    IF NOT EXIST "%SystemRoot%\SysWOW64\cmd.exe" (
    IF NOT DEFINED PROCESSOR_ARCHITEW6432 SET "ARCH=32"
    )
    ECHO>>"%LOGFILE%" 2>>&1 System architecture is %ARCH% bit.
    ::Begin hotfix install
    :Hotfix-install
    ECHO>>"%LOGFILE%" ......................
    ECHO>>"%LOGFILE%" 2>>&1 Installing required HotFix updates
    IF "%ARCH%"=="64" (
    WUSA %CDROM%\updates\Windows6.1-KB2533552-x64.msu /quiet /norestart >>"%LOGFILE%" 2>>&1
    ) ELSE (
    WUSA %CDROM%\updates\Windows6.1-KB2533552-x86.msu /quiet /norestart >>"%LOGFILE%" 2>>&1
    )


    ::all processing finished, delete used files, and EXIT::
    :CLEANUP
    IF EXIST %windir%\Setup\scripts RD /S /Q %windir%\Setup\scripts >nul
    endlocal
    DEL /F /Q %0% >nul

  7. For those that want to add the .NET installer and updates to their Win7 .iso, here's what I do.

    1) Make the following folder structure on your .iso. You can use whatever folders you want, but you'll need to adjust the below code accordingly.

    %source_iso%\updates\NET45

    %source_iso%\updates\NET45\32

    %source_iso%\updates\NET45\64

    (Where %source_iso% is the path to where your source files are kept.)

    2) Put the dotnetfx45_full_x86_x64.exe file in the \NET45\ folder. Put any .NET 4.5 .exe updates (when released) into the appropriate \NET45\32 or \NET45\64 folders.

    3) Add this code to your %source_iso%\sources\$oem$\$$\Setup\scripts\setupcomplete.cmd

    @ECHO off & setlocal EnableDelayedExpansion
    SET "LOGFILE=%systemdrive%\install.log"
    for %%i in (C D E F G H I J K L M N O P Q R S T U V W X Y Z) do if exist %%i:\sources\install.wim set CDROM=%%i:
    ECHO>>"%LOGFILE%" 2>>&1 Found CD-Rom as drive %CDROM%

    :PROCESSOR
    :: Detect OS bit-ness on running system. Assumes 64-bit unless 64-bit components do not exist.
    SET "ARCH=64"
    IF NOT EXIST "%SystemRoot%\SysWOW64\cmd.exe" (
    IF NOT DEFINED PROCESSOR_ARCHITEW6432 SET "ARCH=32"
    )
    ECHO>>"%LOGFILE%" 2>>&1 System architecture is %ARCH% bit.


    :NET-Framework-45
    ECHO>>"%LOGFILE%" ......................
    ECHO Installing .NET 4.5 Framework & ECHO>>"%LOGFILE%" 2>>&1 Installing .NET 4.5 Framework
    %CDROM%\updates\NET45\dotnetfx45_full_x86_x64.exe /passive /norestart >>"%LOGFILE%" 2>>&1

    ECHO Installing .NET 4.5 updates & ECHO>>"%LOGFILE%" 2>>&1 Installing .NET 4.5 updates
    FOR %%X IN ("%CDROM%\updates\NET45\%ARCH%\*.exe") DO (
    "%%X" /passive /norestart >>"%LOGFILE%" 2>>&1
    ECHO>>"%LOGFILE%" 2>>&1 Executed %%X
    )


    ::LAST entry! All processing finished, delete used files, and EXIT::
    :CLEANUP
    IF EXIST %windir%\Setup\scripts RD /S /Q %windir%\Setup\scripts >nul
    endlocal
    DEL /F /Q %0% >nul

    In this way you can drag & drop .NET updates into your .iso whenever they're released and keep it up to date with minimal effort.

    This isn't as compact as Rick's repack, but you can keep it updated yourself as needed.

  8. The only drivers that should be considered for integration into boot.wim are what M$ classifies as "boot-critical" drivers. Namely Mass-Storage and SOME Chipset drivers. Nothing else.

    More info: http://support.microsoft.com/kb/2686316

    Driver Limitations:

    Please keep in mind that there are some drivers that can be included and/or loaded that may not be functional during WinPE portion of installation. This would include, but is not limited too; video drivers, wireless adapter drivers, and audio drivers. The behavior described in this document is not specific to BootCritical drivers (drivers need during boot-up such as controller drivers for access to hard drive) and is in affect for all drivers loaded during installation/deployment.

  9. During the PE stage of Win7 install, after the install.wim has been extracted to the target drive, the OS is still in an "offline" state, so dpinst wouldn't be effective.

    I wonder if the first boot phase can be interrupted before the setupcomplete.cmd phase for driver injection into the now "online" OS?

    I'd be very interested to know how this can be achieved!

    *Edit

    This article has lots of driver-related info for both PE and OS loads.

    http://support.microsoft.com/kb/2686316

  10. I accomplish this same goal by adding the call to my SAD2 script to the sources\$oem$\$$\Setup\scripts\setupcomplete.cmd

    @ECHO off & setlocal EnableDelayedExpansion
    SET "LOGFILE=%systemdrive%\install.log"
    for %%i in (C D E F G H I J K L M N O P Q R S T U V W X Y Z) do if exist %%i:\sources\install.wim set CDROM=%%i:
    ECHO>>"%LOGFILE%" 2>>&1 Found CD-Rom as drive %CDROM%

    REM :: Snip... ::


    :Drivers
    Start "" /max /separate %comspec% /c %CDROM%\SAD2\DP_Install_Tool.cmd /s

    ::all processing finished, delete used files, and EXIT::
    :CLEANUP
    IF EXIST %windir%\Setup\scripts RD /S /Q %windir%\Setup\scripts >nul
    endlocal
    DEL /F /Q %0% >nul
    :EOF

    This process takes place after the main install is complete but prior to the first login.

×
×
  • Create New...