maggreg

Hm. Po pierwsze - oddzielny katalog z zestawem dla 2008 nie ma sensu bo samo menu nie przewiduje możliwości skorzystania z takowego, należy używać zestawu wspólnego dla siódemki i R2. Sam wim oczywiście można umieścić w dowolnym miejscu pod warunkiem podania prawidłowej ścieżki i nazwy w minipliku odpowiedzi. Skoro doszedłeś do tego momentu: to zestaw działa, problemem są tylko pliki licencji EULA, właśnie ich brak generuje taki komunikat jak podany powyżej. Pliki znajdują się w katalogu sources\license i w przypadku płyty wystarczy ten katalog przerzucić, ponieważ jego zawartość pomiędzy klientami a serwerami się różni to trzeba przekopiować oba zestawy. pzdr

Spróbuj aktualizacji offline: http://www.eset.pl/Pomoc,f,260,act,show/Aktualizacja_program_oacute_w_ESET_bez_podlaczenia_do_Internetu_off_line_ pzdr

Na początek proponuję spróbować ustawić partycję "LENOVO_PART" jako botującą czyli wg. nomenklatury programu którego używasz nadać jej status "System". Uwaga, przygotuj jakieś narzędzie live czy choćby płytę instalacyjną z windowsem bo po powyższej czynności utracisz możliwość wystartowania systemu. Próba ta pokaże czy konfiguracja startowa na tej partycji jest prawidłowa i czy uruchamia się odpowiedni WinPE (w tym przypadku LRS.wim o ile mnie pamięć nie myli). pzdr

Proponuję przeczytać krok po kroku temat do którego się odnosisz i sformułować ewentualne pytania uzupełniające do zagadnień tam omówionych oczywiście w kontekście występującego problemu. pzdr

Hm - jeżeli nie jesteś w stanie przeskoczyć podstaw tak prostego środowiska jakim jest Syslinux to zastanawiam się do czego Ci potrzebna multipłyta a już w szczególności środowiska naprawczo diagnostyczne typu Parted Magic czy GParted Live. W ich przypadku brak wiedzy połączony z pewnego rodzaju ignorancją może mieć destrukcyjne następstwa dla systemu użytkownika. Zastanów się czy są to zestawy dla Ciebie. pzdr

Ponieważ /boot/syslinux/syslinux.cfg jest głównym konfigiem ładowanym przez loader więc ponowne odwołanie się do niego z niego jest klasyczną pętlą. Generalnie struktura dla aktualnych wersji syslinuxa w przypadku dołączania kolejnych dystrybucji live może wyglądać następująco: Na czerwono katalogi na niebiesko pliki: /boot/syslinux/ -- syslinux.cfg -- vesamenu.c32 -- tlo.jpg /livenr1 -- live1.cfg -- kernel -- initrd /livenr2 -- live2.cfg -- kernel -- initrd /livenr3 -- live3.cfg -- kernel -- initrd /livenrx -- livex.cfg -- kernel -- linitrd dla takiego układu przykładowe menu główne miało by postać: default /BOOT/SYSLINUX/VESAMENU.C32 MENU BACKGROUND /BOOT/SYSLINUX/tlo.jpg LABEL Live1 KERNEL /BOOT/SYSLINUX/VESAMENU.C32 APPEND /livenr1/live1.cfg LABEL Live2 KERNEL /BOOT/SYSLINUX/VESAMENU.C32 APPEND /livenr2/live2.cfg LABEL Live3 KERNEL /BOOT/SYSLINUX/VESAMENU.C32 APPEND /livenr3/live3.cfg LABEL Livex KERNEL /BOOT/SYSLINUX/VESAMENU.C32 APPEND /livenrx/livex.cfg I tak live1.cfg do livex.cfg mogą mieć dowolne inne nazwy zgodne z systemem plików, mogą to być domyślne syslinux.cfg które w tym przypadku nie kolidują z plikiem w katalogu boot. Katalog boot dla syslinuxa nie wymaga innych "zawartości", mogą one być potrzebne jeżeli nasza płyta zawiera inne środowiska botujące (np dla instalatrorów windowsów, gruba itp). nazwy kernela i initrd są zależne od konkretnego środowiska live i np dla PM są to: bzImage dla kernela i initramfs dla initrd. przykładowy livex.cfg mógłby mieć zawartość: LABEL pmagic KERNEL /livenrx/kernel APPEND /livenrx/initrd Oczywiście można poszczególne konfigi live linuxów trzymać na upartego wewnątrz katalogu boot czy nawet w samym głównym menu syslinux.cfg (choćby z użyciem zmiennej submenu) ale z doświadczenia wiem, że to się nie sprawdza. Bardzo utrudnia to wprowadzenie zmian związanych np z pojawieniem się nowej wersji danego środowiska. Myślę, że w tym momencie jest to już dostatecznie przejrzyste. pzdr

I z tego pewnie będzie pętla: APPEND /BOOT/SYSLINUX/SYSLINUX.CFG Jeżeli chcesz (tak jak poleciłem) trzymać podmenu PM-a w osobnym pliku to albo należy mu nadać inną nazwę albo trzymać w innej ścieżce. pzdr

Obecna wersja stabilna to 4.04, są również wersje beta 4.05 oraz 4.10 rozwijane równolegle. vesamenu.c32 jest graficznym menu syslinuxa obsługującym troszkę wyższe rozdzielczości oraz dającym możliwość używania podkładu graficznego, dlatego jest w tej chwili raczej domyślnym, oczywiście można też użyć uproszczonego menu.c32 które interpretuje ten sam konfig pomijając odwołania do "upiększaczy". Syslinux w zasadzie nie narzuca sztywno ścieżek, można je ustawić poprzez edycję loadera (lub wręcz podczas instalacji jeżeli działamy z napędem USB) mamy tylko do czynienia ze ścieżkami domyślnymi przy czym w wersji obecnej memy większą elastyczność ich wyboru, kiedyś dla płyt używaliśmy isolinux a dla dysków (i usb) syslinux, w tej chwili możemy je stosować wymiennie a zaleceniem jest (ze względu na przenośność) używanie nazwy syslinux (oraz takiej ścieżki). syslinux.cfg domyślnie powinien znajdować się w ścieżce /boot/syslinux, /syslinux lub w katalogu root płyty, konfigi wywoływane wewnętrznie mogą znajdować się w dowolnej ścieżce (ogranicza nas tu standard iso co do nazewnictwa i zagęszczenia ścieżek), ponieważ same dystrybucje live nakładają pewne ograniczenia (a i ich obchodzenie bywa kłopotliwe) więc jesteśmy troszkę ograniczeni w tej dowolności i np. partition magic szuka ścieżki /pmagic toteż i ten katalog (ze względu na zachowanie porządku) dobrze wybrać na plik konfiguracji i ewentualne pliki pomocnicze (np helpy itp.). Należy pamiętać o prawidłowych ścieżkach zarówno do konfigów i wywoływanych plików jak i plików samego syslinuxa takich jak przytaczany vesamenu.c32 (często dodatkowo występują reboot.c32, chain.c32), syslinux interpretuje zarówno ścieżki względne jak i bezwzględne czyli następna rzecz o której trzeba pamiętać. I ostatnia rzecz związana z samym leaderem isolinux który w wersji czwartej wymaga prawidłowego "Boot Information Table" co stanowi nie lada wyzwanie dla programów windowsowych, chyba tylko imgburn potrafi sobie z tym poradzić (i to przej jakieś sztuczki bodajże). Płyta przygotowana bez prawidłowej powyższej tablicy nie będzie się botować wywalając błąd. pzdr

Da się - bez problemu, jeżeli chcesz użyć niestandardowej struktury katalogów to można użyć wersji PXE. Ja osobiście rozdzielam konfigi i z głównego menu wywołuję już właściwe podmenu dla konkretnej dystrybucji czyli w tym przypadku dla parted magic. Typowe wywołanie dla menu graficznego: label PMagic kernel /Syslinux/vesamenu.c32 append /pmagic/syslinux.cfg syslinux.cfg praktycznie bez zmian przerzucony z katalogu boot, minimalistycznie możemy sobie wstawić domyślny wpis jeżeli używamy zawsze jednej pozycji, np.: LINUX /pmagic/bzImage INITRD /pmagic/initramfs APPEND edd=off noapic load_ramdisk=1 prompt_ramdisk=0 rw vga=788 loglevel=0 max_loop=256 vmalloc=256MiB keymap=pl pl_PL W przypadku płyty multiboot zwłaszcza jeżeli budujemy ją już jakiś czas musimy pamiętać, że syslinux troszeczkę zmienił strukturę konfigu, nie wszystkie wpisy dla wersji czwartej są zgodne z trójką, np. wywołania kernel <> linux nie są już tak elastycznie zamienne (w trójce można było praktycznie używać tylko komendy kernel). pzdr

Sterowniki AMD dla chipsetu są zunifikowane, mimo że mamy np linki do wersji 6 do 8 to tak naprawdę prowadzą one do tych samych plików. Stawiam dolary przeciw orzechom, że dla chipsetu serii 9 będzie to samo. pzdr

Myślę, że dopóki ktoś z podobną konfiguracją nie udowodni czegoś innego możemy przyjąć, że ten kontroler AHCI nie obsługuje (nie przepuszcza) w systemie XP standardowej komunikacji z dyskami. Z mojego punktu widzenia (zresztą inni już o tym wspominali) to skórka nie warta wyprawki, stan dysku możesz w każdej chwili kontrolować ręcznie (choćby z poziomu Win7), błędy SMART i tak sugerują "dysk do wymiany" więc taka kontrola jest mało pomocna profilaktycznie a jeżeli wystąpią to na backup może i tak być za późno. I na koniec - jedyną przesłanką na dziś do używania dziadka XP jest przyzwyczajenie a to chyba nie za dobry powód, system ma już 10lat i coraz mniejsze wsparcie, trudno więc przypuszczać, że tego typu problemy zostaną jeszcze kiedyś wyeliminowane. pzdr

Na forum powinien być link do płyty LiveCD programu OTL - poszukaj - o ile pamiętam jest zbudowany w oparciu o WinPE 1.5. Odpal komputer z tej płyty (podczas odpalania prawdopodobnie będzie trzeba wczytać sterowniki z dyskietki tak jak przy instalacji) i w nim uruchom CrystalDiskInfo (np z pena, ta wersja nie wymaga instalacji: CDI Portable). Jeżeli również w ten sposób nie będzie dostępu do dysków wyeliminujemy ew. problem z zainstalowanym systemem i będzie to oznaczać ogólny problem systemów serii NT5 z twoim kontrolerem. pzdr

Utworzenie macierzy nie powinno wpływać na możliwość rozpoznania "fizycznych" dysków. Przytaczany przeze mnie Crystall nie ma z tym problemu (po włączeniu wspominanej już wcześniej opcji). @Oniryczny - czy masz dostęp do środowiska WinPE w wersji wcześniejszej niż 2.0? pzdr

Hm - program z włączoną tą opcją praktycznie pomija sterowniki dedykowane odwołując się bezpośrednio do napędów co by wskazywało, że twój problem leży głębiej niż w sterownikach kontrolera. pzdr

Żeby być precyzyjnym - rozumem, że niezależnie czy opcja "Funkcje > Advanced Feature > Zaawansowane szukanie dysku" jest włączona czy nie program nie wykrywa dysków? pzdr

Napisałeś, że CrystalDiskInfo nie działa - a czy próbowałeś ustawienia Funkcje > Advanced Feature > Zaawansowane szukanie dysku ? pzdr

wygląda na to, że problemem jest kolejność partycji, oczywiście da się utworzyć recovery przy dowolnym ich układzie tym niemniej przykładowe skrypty zakładają konkretny układ: pierwsza partycja zawierająca pliki startowe systemu a więc ustawiona jako aktywna która jednocześnie stanie się partycją recovery, jej rozmiar zależy od rozmiaru przechwytywanego systemu, tak naprawdę dla czystego systemu ze sterownikami wystarczy ok 3GB. druga partycja z samym systemem. W twoim przypadku partycja dla recovery nie zawiera plików rozruchowych (pewnie są na partycji z systemem) a więc wpisy w kontenerze rozruchowym szukają pliku winpe.wim w niewłaściwym miejscu i środowisko służące do przechwycenia się nie uruchamia (stąd błąd który przytoczyłeś), system potem uruchamia się prawidłowo dlatego, że komenda startująca środowisko przechwytujące jest jednorazowa. pzdr edit Po dokładniejszym przyjrzeniu się plikom które zamieściłeś uważam, że nie tyle kolejność co właśnie złe przypisanie ról jest przyczyną dla której to u Ciebie nie zadziałało. Całość wywala się prawdopodobnie nie na samym winpe.wim (czy właściwie wintemp.wim) ale na ram dysku, układ szuka na partycji o znaczniku "boot" pliku boot.sdi w ścieżce \recovery i oczywiście w tym przypadku nie znajduje (bo szuka na c:\recovery czyli partycji drugiej zamiast na pierwszej). O ile nadal uważam, że pliki startowe (które MS określa jako systemowe) powinny znaleźć się raczej na partycji recovery ew. na zupełnie oddzielnej partycji to jednak i w opisywanym przypadku da się (powinno się dać) w miarę prosto uzyskać działający zestaw, należy tylko w skryptach zastąpić wpisy: objFile.WriteLine "@bcdedit /set {ramdiskoptions} ramdisksdidevice boot" następującą wersją: objFile.WriteLine "@bcdedit /set {ramdiskoptions} ramdisksdidevice partition=\device\harddisk0\partition1" pzdr

Skrypt powinien działać prawidłowo. Dla pewności sprawdziłem dodatkowo po twoim poście całość na czystej instalacji Win7 Ultimate SP1 x86, zarówno przechwycenie jak i odzyskiwanie działa prawidłowo. Oczywiście testy robiłem na maszynie wirtualnej i fizyczny komputer może zachować się troszkę inaczej ale jeżeli sam skrypt wykonuje się prawidłowo to nie powinno mieć znaczenia jaka to maszyna. Mam pewne podejrzenia dlatego proszę o dodatkowe informacje. Czy komunikat występuje jednorazowo po pierwszym restarcie a po ponownym uruchamia się standardowy system? Proszę podać wynik działania komendy: diskpartlis vol Ew. proszę wykonać skrypt vbs: If WScript.Arguments.length =0 Then Set objShell = CreateObject("Shell.Application") objShell.ShellExecute "wscript.exe", Chr(34) & _ WScript.ScriptFullName & Chr(34) & " uac", "", "runas", 1 Else On Error Resume Next Set objShell = CreateObject("WScript.Shell") objShell.CurrentDirectory = objShell.ExpandEnvironmentStrings("%userprofile%") & "\desktop" objShell.Run ("%comspec% /c mklink /d c:\tmprecovery \\?\GLOBALROOT\device\harddisk0\partition1\"),0,true Set fso = CreateObject("Scripting.FileSystemObject") Set NewFile = fso.CreateTextFile("FileList.txt", True) Set folder = fso.GetFolder("c:\tmprecovery") For Each objSubfolder in Folder.Subfolders NewFile.WriteLine("\" & objSubfolder.name) next NewFile.WriteLine vbcrlf ShowSubFolders folder, "" NewFile.WriteLine vbcrlf For each folderIdx In folder.Files NewFile.WriteLine("\" & folderIdx.Name) Next NewFile.Close objShell.Run ("%comspec% /c bcdedit /store \\?\GLOBALROOT\device\harddisk0\partition1\boot\bcd /enum all >%userprofile%\desktop\bcd_part1.txt"),0,true objShell.Run ("%comspec% /c rmdir c:\tmprecovery"),0,true End If WScript.quit Sub ShowSubFolders(folder,nazwa) For Each Subfolder In Folder.SubFolders For Each file In SubFolder.Files NewFile.WriteLine(nazwa & "\" & subfolder.name & "\" & file.Name) Next NewFile.WriteLine vbcrlf ShowSubFolders Subfolder ,nazwa & "\" & Subfolder.name Next End Sub i wrzucić zawartość utworzonych na pulpicie plików. pzdr

Nie należy zapominać, że w tym przypadku kontroler pamięci siedzi w procesorze, problemy z obsadzeniem (stykami w slocie procesora) również może powodować problemy z ramem. Należy się też upewnić, że bios rozpoznaje prawidłowo parametry ramu (opóźnienia ale przede wszystkim napięcie). Sprawdź czy dla tego modelu płyty nie pojawił się nowy bios (nawet wersja beta, dla płyt serii 68 GigaByte wypuścił już sporo wersji od premiery), skoro odpala z jednym ramem to nie będzie problemu z przeflashowaniem. pzdr

Proponuję diagnostykę eliminacyjną. Wyjąć pamięć i wystartować (najlepiej wyjąć też grafikę) , jeżeli komputer wystartuje i zasygnalizuje błędy pamięci wiadomo gdzie był problem (przemyć styki pamięci odpowiednim preparatem, odwrócić kolejność w ostateczności wymienić) jeżeli nie wystartuje lub wystartuje bez komunikatów - problem z procesorem, sprawdzić jego obsadzenie a w szczególności stan pinów w podstawce (obejrzeć bardzo dokładnie), po wyeliminowaniu tej przyczyny jeżeli problem nie ustąpi sprawdzić napięcia w złączu zasilania procesora (również masy). Jeżeli problem nie ustąpi mamy do czynienia z uszkodzeniem procesora (rzadkość) lub płyty głównej (oczywiście może to być problem z biosem lub wykrywanymi ustawieniami), można spróbować wyjąć baterię na kilkanaście minut przy całkowitym odłączeniu zasilania, GigaByte powinien też pozwolić na wymuszenie startu z zapasowego biosu (proponuję przejrzeć instrukcję) na wypadek uszkodzenia zawartości głównej kości. pzdr

Dawno nic w temacie nie umieszczałem więc może żeby całkiem nie umarł mały skrypcik listujący dyski w systemie i przypisane im partycje. Wersja standardowa: Set objDictionary = CreateObject("Scripting.Dictionary") Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2") Set wmiDiskDrives = objWMIService.ExecQuery("Select * from Win32_DiskDrive") For Each wmiDiskDrive In wmiDiskDrives objDictionary.Add wmiDiskDrive.DeviceID, "Dysk fizyczny: " & wmiDiskDrive.Caption & " (" & wmiDiskDrive.DeviceId & ")" strEscapedDeviceID = Replace(wmiDiskDrive.DeviceID, "\", "\\", 1, -1, vbTextCompare) Set wmiDiskPartitions = objWMIService.ExecQuery("ASSOCIATORS OF {Win32_DiskDrive.DeviceID=""" & strEscapedDeviceID & """} WHERE " & "AssocClass = Win32_DiskDriveToDiskPartition") objDictionary.Add "partycje" & wmiDiskDrive.DeviceID, "Posiada partycji " & wmiDiskDrive.Partitions & " a oto one:" & vbCr For Each wmiDiskPartition In wmiDiskPartitions objDictionary.Add wmiDiskPartition.DeviceID, "Dysk " & wmiDiskPartition.DiskIndex & " Partycja " & wmiDiskPartition.Index + 1 Set wmiLogicalDisks = objWMIService.ExecQuery("ASSOCIATORS OF {Win32_DiskPartition.DeviceID=""" & wmiDiskPartition.DeviceID & """} WHERE " & "AssocClass = Win32_LogicalDiskToPartition") For Each wmiLogicalDisk In wmiLogicalDisks objDictionary.Add wmiLogicalDisk.DeviceID, "Partycja " & wmiDiskPartition.Index + 1 & " ma przypisaną literę - " & wmiLogicalDisk.DeviceID Next Next objDictionary.Add wmiDiskDrive.DeviceID & "koniec", vbCr & vbCr Next For Each wpis in objDictionary.items wpisy = wpisy & wpis & vbCrLf Next objDictionary.RemoveAll msgbox wpisy I wersja wykluczająca z listingu napędy USB: Set objDictionary = CreateObject("Scripting.Dictionary") Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2") Set wmiDiskDrives = objWMIService.ExecQuery("Select * from Win32_DiskDrive Where InterfaceType <> 'USB'") For Each wmiDiskDrive In wmiDiskDrives objDictionary.Add wmiDiskDrive.DeviceID, "Dysk fizyczny: " & wmiDiskDrive.Caption & " (" & wmiDiskDrive.DeviceId & ")" strEscapedDeviceID = Replace(wmiDiskDrive.DeviceID, "\", "\\", 1, -1, vbTextCompare) Set wmiDiskPartitions = objWMIService.ExecQuery("ASSOCIATORS OF {Win32_DiskDrive.DeviceID=""" & strEscapedDeviceID & """} WHERE " & "AssocClass = Win32_DiskDriveToDiskPartition") objDictionary.Add "partycje" & wmiDiskDrive.DeviceID, "Posiada partycji " & wmiDiskDrive.Partitions & " a oto one:" & vbCr For Each wmiDiskPartition In wmiDiskPartitions objDictionary.Add wmiDiskPartition.DeviceID, "Dysk " & wmiDiskPartition.DiskIndex & " Partycja " & wmiDiskPartition.Index + 1 Set wmiLogicalDisks = objWMIService.ExecQuery("ASSOCIATORS OF {Win32_DiskPartition.DeviceID=""" & wmiDiskPartition.DeviceID & """} WHERE " & "AssocClass = Win32_LogicalDiskToPartition") For Each wmiLogicalDisk In wmiLogicalDisks objDictionary.Add wmiLogicalDisk.DeviceID, "Partycja " & wmiDiskPartition.Index + 1 & " ma przypisaną literę - " & wmiLogicalDisk.DeviceID Next Next objDictionary.Add wmiDiskDrive.DeviceID & "koniec", vbCr & vbCr Next For Each wpis in objDictionary.items wpisy = wpisy & wpis & vbCrLf Next objDictionary.RemoveAll msgbox wpisy A takie dane skrypt produkuje wersja bez i z USB:

Od siebie dodam jeszcze - ze skryptu vbs, w zależności od tego co bat lub cmd robi można spróbować go przenieść w środowisko vbs albo po prostu odpalić samego bata z takiego poziomu. Aby vbs zapytał o uprawnienia należy w nim umieścić taką zawartość: If WScript.Arguments.length =0 Then Set objShell = CreateObject("Shell.Application") objShell.ShellExecute "wscript.exe", Chr(34) & WScript.ScriptFullName & Chr(34) & " uac", "", "runas", 1 Else `tutaj umieszczamy właściwy kod do odpalenia End If pzdr

Środowisko WinPE w moim rozwiązaniu jest 32 bitowe, takie rozwiązanie jest bardziej uniwersalne*, pozwala bez problemu zainstalować również systemy vista i nowsze w wersjach 64 bit ale cały zestaw instalacyjny musi być 32 bitowy. Jeżeli nie masz dostępu do płyty 32 bit (musie być siódemka, R2 istnieje tylko w wersji 64) ale posiadasz waika (w tym wypadku 3.0) to odpowiednie środowisko znajduje się w pliku: Windows AIK PLN\Tools\PETools\x86\WinPE_FPs\WINPE-SETUP.CAB, nie trzeba go integrować z winpe, wystarczy wypakować zawartość podkatalogu "x86_microsoft-windows-imagebasedsetup-media_31bf3856ad364e35_6.1.7601.17514_none_721540bbe51e7831" do odpowiedniego katalogu na penie, dodatkowo należy z płyt rozpakować pliki licencji, co prawda znajdują się w plikach WINPE-SETUP-CLIENT.CAB i WINPE-SETUP-SERVER.CAB ale są podzielone na podkatalogi poszczególnych edycji, byłoby z tym dużo zabawy, natomiast w jednego z tych plików (obojętnie który) należy przekopiować zawartość x86_microsoft-windows-i..dia-branding..... (to który plik wybierzemy wpłynie wyłącznie na kolory okienek setupu). Dodatkowo z płyty instalacyjnej kopiujemy plik lang.ini, możemy też utworzyć go od podstaw, typowa zawartość dla polskiej edycji windowsa to: [Available UI Languages] pl-PL = 3 [Fallback Languages] pl-PL = en-us W grę wchodzą jeszcze pliki "product.ini" i "ei.cfg" ale nie pamiętam czy są niezbędne, na pewno nie przeszkadzają. Kiedy mamy już środowisko instalacyjne wystarczy przerzucić pliki zawierające same systemy czyli niezależnie od wersji "install.wim", jeżeli chcemy mieszać edycje, łączyć siódemkę z serwerem należy wyeksportować obrazy do jednego install.wim albo użyć minimalistycznego pliku odpowiedzi wskazującego na wim o innej nazwie, ja np domyślnie używam pliku install_64.wim więc mini xml ma postać: <?xml version='1.0' encoding='utf-8'?> <unattend xmlns="urn:schemas-microsoft-com:unattend"> <settings pass="windowsPE"> <component name="Microsoft-Windows-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <ImageInstall> <OSImage> <InstallFrom> <Path>..\sources\install_seven64.wim</Path> </InstallFrom> <WillShowUI>OnError</WillShowUI> </OSImage> </ImageInstall> </component> </settings> </unattend> Jeszcze jedna uwaga dotycząca instalacji nienadzorowanych, w przypadku instalacji systemu 64 -bitowego z poziomu winpe 32 bit musimy pamiętać żeby wpisy w pliku odpowiedzi odnosiły do odpowiedniej dla danego momentu architektury, czyli przebieg "winpe" komponenty = x86 a reszta (czyli np specialize, oobe itp) komponenty = amd64. W niektórych przebiegach można też użyć architektury wow64 ale sam takiego pliku nie budowałem. mam nadzieję, że to jest zrozumiałe, jeżeli potrzeba coś doprecyzować pisz śmiało pzdr *środowisko winpe w wersji 64 bitowej w przeciwieństwie do samego systemu nie posiada mechanizmu wow (okna w oknach) i nie potrafi uruchomić plików 32 bitowych, ponieważ prawie wszystkie narzędzia 64 bit posiadają odpowiedniki 32 bit co nie jest oczywiste w drugą stronę dlatego środowisko 32 bit jest bardziej uniwersalne (choćby setup dla typowego xp, nie ruszy w środowisku 64 bit) dodatkowo środowisko 32 bit ruszy na starszych procesorach nie obsługujących rozkazów 64 bit oczywiście na penie można umieścić obie wersje choć skrypty wymagają wtedy kosmetycznych zmian

Ja wolę oryginalne paczki od producenta systemu niż odwoływanie się do zewnętrznych narzędzi (bez względu na "pracochłonność"). To oczywiście rzecz gustu, ale ufam że podany przez ciebie program przeprowadza konwersję w sposób maksymalnie przezroczysty i pewny. Czy i jak sobie radzi pkgmgr z pakietami msu tego akurat nie wiem, są różne doświadczenia, ja akurat mam złe doświadczenie z próbą integracji z pakietu exe (rozpakowanego), pakiet językowy zawarty wewnątrz tej paczki nie chciał się zintegrować (z zastrzeżeniem, że dotyczyło to wersji dla siódemki). Dajmy użytkownikowi możliwość wyboru. pzdr

IE9 można ściągnąć w wersji przeznaczonej do integracji narzędziami pkgmgr czy dism, są to pakiety msu, dla visty w zależności od architektury mamy: x86 x64 Ponieważ są to pakiety w wersji angielskiej dodatkowo należy zassać sobie i zintegrować pakiet językowy ze strony (wersja dla visty): IE9 MUI pzdr