maggreg

Co zrobić z windowsami XP w firmie do czasu zanim je wymienię?

Jest jakaś aktualizacja ? Xp angielski udało mi się zainstalować aktualizację ale na XP z polskim językiem nie mogę...

Proszę o pomoc

Jakbyś troszkę poszukał to na tym forum znalazłbyś całkiem prężny wątek temu poświęcony:

https://www.fixitpc.pl/topic/32110-zabezpieczanie-windows-xp/

pzdr

Spróbuj bez uruchamiania modułu graficznego lub tylko jeden z nich:

insmod efi_gop
insmod efi_uga

Spróbuj kombinacji pośrednika:

grub > efishell > bootmgrfw

albo

efishell > grub > bootmgr

efishell może uruchomić przy starcie z automatu wybraną pozycję, wystarczy w katalogu root wrzucić skrypt "startup.nsh":

echo Botowanie Grub
blk0:\efi\boot\bootx64.efi

Zrób listing pełny tego bcd:

boot.sdi musi być dostąpny dla winpe natomiast jego konkretne położenie również możemy zmienić (patrz "sdi file" w edytorze).

Natomiast ta sieczka wskazuje na problem z ustawieniem graficznym, albo sterownik podawany przez grub jest nieprawidłowy albo tryb graficzny, spróbuj zostawić tryb auto w grub.cfg i ew. odpal bez odwołania się do tematu graficznego (themes).

pzdr

Dlatego, że bootmgr.efi nie posiada odpowiedniego stuba dla gruba .

bootmg.efi nie jest właściwym plikiem do chainu, właściwy jest bootmgrfw.efi (może mieć nazwę bootx64.efi ale to ten sam plik).

Pamiętaj też, że nawet jeżeli przeniesiesz plik w niestandardową lokację to bcd i tak musi się znaleźć w /efi/microsoft/boot inaczej bootloader go nie znajdzie. Najlepiej całość (bootmgrfw.efi, bootmgr.efi i bcd) trzymać w tej lokacji, pamiętaj że bez znaczenia ile będziesz chciał odpalić różnych pe to powinny one korzystać z jednego zestawu. Obejściem jest wimboot ale jak pisałem nie działa w grub efi (wersja efi działa tylko z ipxe).

Podsumowując - układ powinien być taki:

/boot/boot.sdi
/efi/microsoft/boot/bootmgr.efi
/efi/microsoft/boot/bootmgrfw.efi
/efi/microsoft/boot/bcd
/sources/winpe1.wim
/sources/winpe3.wim
/sources/winpe2.wim

menuentry "Windows 10 64 bit" --class win{ echo "Proszę czekać..." chainloader /efi/microsoft/boot/bootmgrfw.efi }

Wg. mojego pobieżnego spojrzenia nie wszystkie odpalą, choćby popularny mint nie ruszy z tak podanego loopback, poprawny wpis to np:

menuentry "Linux Mint 18.1 Cinnamon LTS RC (x64)" {
    set iso=/boot/iso/linuxmint-18.1-cinnamon-64bit.iso
    loopback loop $iso
    linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$iso noeject noprompt 
    initrd (loop)/casper/initrd.lz
}

Dobrym miejscem z przykładami jest strona arch-a:

https://wiki.archlinux.org/index.php/Multiboot_USB_drive

Pozwolę sobie też wkleić poradę z naszej prywatnej konwersacji, może się komuś przyda.

Wystarczą pliki z windowsa:

C:\Windows\Boot\EFI >> \efi\microsoft\boot

pakiety językowe możesz sobie darować, wystarczą pliki boomgr.efi i bootmgrfw.efi (ten plik jest w 100% tym samym co bootx64.efi w wersji windowsowej)

bcd na początek możesz spróbować

domyślny układ to plik \sourcess\boot.wim

oczywiście trzeba też wrzucić ramdysk (plik boot.sdi) do katalogu \boot

 

Odpowiednie pliki też zawsze znajdziesz w samym winpe, jak otworzysz plik winpe.wim (np. boot.wim z płyty windowsa) w 7zip to w katalogu \windows\boot masz wszystko co potrzebne, w katalogu efi masz to co powyżej, w dvd przykładowe efi dla obu architektur i ramdisk, w pcat bootmgr dla trybu legacy.

 

Nie wiem czy to dobry pomysł z moim bcd, używa specyficznego układu katalogów proponuję raczej ułożyć sobie własne wpisy, np bootice daje opcję bardzo szybkiego ułożenia własnego menu. W trybie easy wystarczy ze dasz add > wim i ustawisz ścieżkę do swojego obrazu.

Przykład na szybko

pzdr

Nie bardzo rozumiem z czym sobie nie radzisz, nie wiszę w ogóle w załączonym pliku odniesienia do loadera efi.

Może na początek mój plik dla efi na dysku (raczej testowy, częściej sięgam po boot z sieci)

set default="0"
if loadfont $prefix/unicode.pf2; then
	set gfxmode=auto
	insmod efi_gop
	insmod efi_uga
	insmod gfxterm
	insmod font
	export firmware_found
	insmod regexp
	insmod probe
	terminal_output gfxterm
	terminal gfxterm
	insmod part_msdos
	insmod part_gpt
fi

  set hidden_timeout_quiet=false
  load_video
  set gfxpayload=keep

insmod gzio
insmod png
use_bg=true

if background_image $prefix/Gsplash.png; then
  set color_normal=white/black
  set color_highlight=white/blue
fi

menuentry "WDS"{
  search --no-floppy --fs-uuid --set=root 01D22F1BB30D9540
  chainloader "/efi/microsoft/boot/bootmgfw.efi"
}

menuentry "Syslinux"{
  search --no-floppy --fs-uuid --set=root 7921-5E88
  chainloader "/EFI/syslinux/syslinux.efi"
}

menuentry "memtest"{
  search --no-floppy --fs-uuid --set=root 7921-5E88
  chainloader "/EFI/memtest/memtest.efi"
}

menuentry "konboot"{
  search --no-floppy --fs-uuid --set=root 7921-5E88
  chainloader "/EFI/boot/konboot.efi"
}

menuentry "rufus"{
  search --no-floppy --fs-uuid --set=root 7921-5E88
  chainloader "/EFI/boot/rufus.efi"
}

menuentry "shell edk2"{
  search --no-floppy --fs-uuid --set=root 7921-5E88
  chainloader "/EFI/boot/edk2/shell_x64.efi"
}

menuentry "shell udk2014"{
  search --no-floppy --fs-uuid --set=root 7921-5E88
  chainloader "/EFI/boot/udk2014/shell_x64.efi"
}

menuentry "clover"{
  search --no-floppy --fs-uuid --set=root 7921-5E88
  chainloader "/EFI/boot/CLOVERX64.efi"
}

menuentry "ipxe"{
  search --no-floppy --fs-uuid --set=root 7921-5E88
  chainloader "/EFI/boot/ipxe.efi"
}

menuentry "ipxe clean"{
  search --no-floppy --fs-uuid --set=root 7921-5E88
  chainloader "/EFI/boot/ipxe-clean.efi"
}

menuentry "ipxe asix"{
  search --no-floppy --fs-uuid --set=root 7921-5E88
  chainloader "/EFI/boot/axge.efi"
}

menuentry "Manjaro Cinnamon"  {
  search --no-floppy --fs-uuid --set=root 01D22F1BB30D9540
    set isofile="/live/manjaro-cinnamon-16.10.3-stable-x86_64.iso"
    set mlabel="MJRO1610"
    set archi="x86_64"
    set dri="nonfree"
    search --no-floppy -f --set=root $isofile
    loopback loop $isofile
    linux (loop)/manjaro/boot/$archi/manjaro earlymodules=loop img_dev=/dev/disk/by-uuid/01D22F1BB30D9540 img_loop=$isofile misobasedir=manjaro misolabel=$mlabel i915.modeset=1 logo.nologo overlay=$dri $dri=yes 
    initrd (loop)/manjaro/boot/intel_ucode.img (loop)/manjaro/boot/$archi/manjaro.img
}

menuentry "Clonezilla 64"{
  search --no-floppy --fs-uuid --set=root 01D22F1BB30D9540
  linux /live/clonezilla/64b/vmlinuz boot=live live-media-path=/live/clonezilla/64b toram=filesystem.squashfs union=overlay username=user config components quiet noswap edd=on nomodeset noeject locales=pl_PL.UTF-8 keyboard-layouts=pl ocs_live_run="ocs-live-general" ocs_live_extra_param="" ocs_live_batch="no" vga=788 ip= net.ifnames=0  nosplash i915.blacklist=yes radeonhd.blacklist=yes nouveau.blacklist=yes vmwgfx.enable_fbdev=1
  initrd /live/clonezilla/64b/initrd.img
}

menuentry "Clonezilla 32"{
  search --no-floppy --fs-uuid --set=root 01D22F1BB30D9540
  linux /live/clonezilla/32b/vmlinuz boot=live live-media-path=/live/clonezilla/32b toram=filesystem.squashfs union=overlay username=user config components quiet noswap edd=on nomodeset noeject locales=pl_PL.UTF-8 keyboard-layouts=pl ocs_live_run="ocs-live-general" ocs_live_extra_param="" ocs_live_batch="no" vga=788 ip= net.ifnames=0  nosplash i915.blacklist=yes radeonhd.blacklist=yes nouveau.blacklist=yes vmwgfx.enable_fbdev=1
  initrd /live/clonezilla/32b/initrd.img
}

menuentry "instalki" {
  search --no-floppy --fs-uuid --set=root 01D22F1BB30D9540
    linux16 /boot/wimboot rawbcd index=1 gui
    initrd16 \
	    newc:bcd:/efi/microsoft/boot/bcd_uefi \
        newc:boot.sdi:/boot/boot.sdi \
        newc:boot.wim:/instalki/winpe.wim 
}

menuentry "test disk"{
    for dev in (*); do
	regexp -s device '\((.*)\)' $dev
		if [ ! -z "${device}" ]; then
		if strcontains "$device" "," ; then
			probe -s fstype -f $dev 
			probe -s uuid -u $dev 
			probe -s label -l $dev 
			echo $dev  -  $fstype  -  $uuid  -  $label
		fi
		fi
	set fstype=
	set device=
	set uuid=
	set label=
	done
sleep -v -i 90
}

function strcontains {
	set str="$1"
	set pattern="$2"
	if regexp ".*${pattern}.*" "$str"; then
		return 0;
	else
		return 1;
	fi
}

submenu "Super grub" {
menuentry "SG" {
    configfile "${prefix}/sg/main.cfg"
}
menuentry "return" {
    configfile "${prefix}/grub.cfg"
}
}

function efi_detect {
        submenu --class=find.efi --hotkey=f "Loadery EFI" {
            for efi in (*,gpt*)/efi/*/*.efi (*,gpt*)/efi/*/*/*.efi (*,gpt*)/*.efi (*,gpt*)/*/*.efi (*,msdos*)/efi/*/*.efi (*,msdos*)/efi/*/*/*.efi (*,msdos*)/*.efi (*,msdos*)/*/*.efi; do
                regexp --set=1:efi_device '^\((.*)\)/' "${efi}"
                if [ -e "${efi}" ]; then
                    menuentry --class=efi "${efi}" "${efi_device}" {
                        root="${2}"
                        chainloader "${1}"
                    }
                fi
            done
		menuentry --hotkey=q  "return" {
			configfile "${prefix}/grub.cfg"
		}
        }
}

efi_detect

menuentry "Reboot" {
   reboot
}
 
menuentry "Shutdown" {
   halt
}

Staram się trzymać oddzielnie konfiguracje dla grub2 efi i grub2 legacy, i tak musimy mieć oddzielne loadery wiec można rozdzielić pliki.

Jeżeli nie chcesz dublować katalogów to można np. rozbić je z pomocą takiego zabiegu jaki masz przy ładowaniu modułów:

grub.cfg:

    if [ "${grub_platform}" = "efi" ]; then
    configfile "${prefix}/menuefi.cfg"
    fi
    if [ "${grub_platform}" == "pc" ]; then
    configfile "${prefix}/menulegacy.cfg"
    fi

menuentry "Instalacja Windows " --class winusb {
if [ "${grub_platform}" == "pc" ]; then
insmod ntldr
ntldr /boot/bootmgr
fi
if [ "${grub_platform}" == "efi" ]; then
chainloader /EFI/MICROSOFT/BOOT/bootmgfw.efi
fi
}
if [ "${grub_platform}" == "pc" ]; then
menuentry "Windows 10 Live Rescue Disk" --class win{
echo "Proszę czekać..."
set iso="/iso/Win10PESE.iso"
linux16 /boot/grub/memdisk iso 
initrd16 (hd0,1)$iso
}
fi

Można sięgnąć po wimboot (choć ten znów jest bardzo kapryśny w efi):

menuentry "wimboot DaRT8.1.iso" {
    insmod udf
	set isofile="/iso/DaRT8.1.iso"
    loopback loop $isofile
    linux /syslinux/wimboot
    initrd \
        newc:bcd:(loop)/efi/microsoft/boot/bcd \
        newc:boot.sdi:(loop)/boot/boot.sdi \
        newc:boot.wim:(loop)/sources/boot.wim
}

Ja mam np. taki zestaw:

Jeżeli natomiast chcesz uniknąć podwójnego menu to sięgasz po wimboot:

menuentry "instalki" {
    linux /syslinux/wimboot rawbcd index=1 gui
    initrd \
	newc:bcd:/wp/bcd_uefi \
        newc:boot.sdi:/boot/boot.sdi \
        newc:boot.wim:/instalki/winpe.wim 
}

Jak widzisz mam na liście 10pe-se z http://theoven.org/ ale uruchamiany bezpośrednio z wim a nie iso.

Trudno mi coś napisać o memtestach z grub2, memtest.efi działa jako normalna aplikacja efi natomiast z wersjami legacy zawsze był kłopot.

Ja prawdę mówiąc w trybie legacy korzystam raczej z grub4dos niż z grub2 i wygląda to tak:

title memtest+
kernel /boot/memtestp.bin

title memtest
kernel /boot/memtest

Ok sprawdziłem i nie widzę problemu z botem memtest w grub2 legacy, zarówno z obrazów dyskietek jak i binarki, działają obie gałęzie (86 i 86+):

menuentry "Memtest86+" {
 linux16 /wp/memtestp.bin
 } 

menuentry "Memtest" {
 linux16 /wp/memtest
} 

menuentry "Memtest86+ floppy image" {
      linux16 /syslinux/memdisk
      initrd16 /wp/memtestp.img
}

menuentry "Memtest floppy image" {
      linux16 /syslinux/memdisk
      initrd16 /wp/memtest86-floppy.img
}

Proponuję w ramach eksperymentu z czystym systemem skupić się raczej na tej części muzycznej i zobaczyć efekt.

Pisałem o stainbergu z własnej praktyki, mam pod opieką w gronie rodzinnym bardzo podobną konfigurację (różnica, że dac działa po firewire) i troszkę walczyłem ze stabilnością systemu, zdaje się pomogły któreś sterowniki do gwizdka zabezpieczającego (zainstalowały się wraz z odświeżaniem certyfikatu).

Spróbuj może czysty system z podstawowymi sterownikami i właśnie uTorrent, żeby go intensywnie pomęczyć zapnij w pętli jakiś zestaw linuxów, co da gwarancję że będą pery które dociążą sieć.

Oczywiście odwrócony eksperyment jest też jak najbardziej w porządku, jak już wcześniej pisałem jeżli upatrujesz ducha sprawczego w utorrent to pozbycie się go będzie jak najbardziej ok, zamiennie można sięgnąć choćby po popularny na innych platformach transmission:

https://transmissionbt.com/download/

czy choćby bitspirrit:

http://www.bitspirit.cc/en/

dawno nie aktualizowany ale ma wszystko co potrzebne i działa stabilnie.

pzdr

Tez miałem taki problem przez kilka dni (używam vivaldi), z tego co zaobserwowałem pojawiał się na stronach które przekierowywały z http na https, ustąpił samoczynnie więc problem po pewnie stronie serwerów dns lub ew. certyfikatów (może któryś certyfikat w ścieżce wygasł i wymagał odświeżenia).

Gwoli uściślenia - mój dostawca to Vectra.

pzdr

Nie chciałbym wchodzić w buty specjalistów od analizy logów ale na moje oko nie widać nic co można by nazwać malwarem czy wirusem, na pewno w kontekście uTorrent nie widać nic złego.

Na pierwszy rzut oka ciekawy wpis to "virususb.sys" ale to sterownik zdaje się do pluginów midi vst czy vsti.

W ogóle widać, że system mocno nastawiony na obróbkę dźwięku i tutaj można by się dopatrywać jakiś kłopotów, część z softu korzysta zw sprzętowych zabezpieczeń (choćby stainberg) które instalują w systemie swoje sterowniki do dongli zabezpieczających - osobiście miałem już kłopoty w takiej konfiguracji z niestabilną pracą systemu.

Również sterowniki towarzyszące pluginom vst bywają zawodne - choćby w kontekście wymienionego "virususb.sys" można spotkać w sieci wpisy dotyczące problemów.

Czy "alternatywny" komputer również ma system przygotowany do obsługi sprzętu DAC i oprogramowania muzycznego?

pzdr

Wpis jest jak najbardziej prawidłowy w legacy, taki po prostu format ma grub2 również dla bootmgr (choć bodajże chainloader --raw też zadziała).

Natomiast nie jest to właściwy loader ani komenda dla trybu uefi.

W tym trybie należy przygotować oddzielny zestaw startowy również oddzielne BCD.

Przykładowy wpis dla efi może wyglądać nastepująco:

menuentry "WDS"{
  search --no-floppy --fs-uuid --set=root 1472ccef1472ccef
  chainloader "/efi/microsoft/boot/bootmgfw.efi"
}

Pamiętajmy, że dla konfiguracji efi również w ścieżce "/efi/microsoft/boot/" musi się również znaleźć bootmgr.efi oraz BCD.

W zależności jakie w-kompilowaliśmy moduły w grub2 może też zaistnieć potrzeba załadowania niektórych z nich przed powyższym wpisem, np.:

  insmod efi_gop
  insmod efi_uga
  insmod part_msdos
  insmod part_gpt

Nadmienię tutaj, że grub2 pozwala na pewną automatyzację za pomocą skryptów i np. wyszukanie wszystkich loaderów które mogą się nadawać do chainloadu, przykład wpisu który robi coś takiego:

function efi_detect {
        submenu --class=find.efi --hotkey=f "Loadery EFI" {
            for efi in (*,gpt*)/efi/*/*.efi (*,gpt*)/efi/*/*/*.efi (*,gpt*)/*.efi (*,gpt*)/*/*.efi (*,msdos*)/efi/*/*.efi (*,msdos*)/efi/*/*/*.efi (*,msdos*)/*.efi (*,msdos*)/*/*.efi; do
                regexp --set=1:efi_device '^\((.*)\)/' "${efi}"
                if [ -e "${efi}" ]; then
                    menuentry --class=efi "${efi}" "${efi_device}" {
                        root="${2}"
                        chainloader "${1}"
                    }
                fi
            done
		menuentry --hotkey=q  --class=cancel "return" {
			configfile "${prefix}/grub.cfg"
		}
        }
}

  export firmware_found
  insmod regexp
  insmod probe
  export loaded
efi_detect

edit.

Powyższy skrypt jest lekko przerobioną wersją skryptu znalezionego na iso manjaro, jego wersja dla trybu legacy to coś na ksztalt:

function win_detect {
        submenu --class=find.win --hotkey=f "Loadery Windows" {
            for win in (*,msdos*)/boot/bootmgr (*,msdos*)/bootmgr ; do
                regexp --set=1:win_device '^\((.*)\)/' "${win}"
				if [ -e "($win_device)/boot/bcd" ]; then
                    menuentry --class=efi "${win}" "${win_device}" {
                        root="${2}"
                        ntldr "${1}"
                    }
                fi
            done
		menuentry --hotkey=q  "return" {
			configfile "${prefix}/grub.cfg"
		}
        }
}

	insmod regexp
	insmod probe
win_detect

Tytułem uzupełnienia - podstawowa różnica w bcd:

efi:

Windows Boot Manager
--------------------
identifier              {bootmgr}
description             Windows Boot Manager
locale                  pl-PL
default                 {default}
displayorder            {default}
timeout                 30

Windows Boot Loader
-------------------
identifier              {default}
device                  ramdisk=[boot]\instalki\winpe.wim,{ramdiskoptions}
path                    \Windows\system32\boot\winload.efi
description             Instalki
locale                  pl-PL
osdevice                ramdisk=[boot]\instalki\winpe.wim,{ramdiskoptions}
systemroot              \Windows
bootmenupolicy          Legacy
detecthal               Yes
winpe                   Yes

Setup Ramdisk Options
---------------------
identifier              {ramdiskoptions}
ramdisksdidevice        boot
ramdisksdipath          \boot\boot.sdi

Windows Boot Manager
--------------------
identifier              {bootmgr}
description             Windows Boot Manager
locale                  pl-PL
default                 {default}
displayorder            {default}
timeout                 30

Windows Boot Loader
-------------------
identifier              {default}
device                  ramdisk=[boot]\instalki\winpe.wim,{ramdiskoptions}
path                    \windows\system32\boot\winload.exe
description             Instalki
locale                  pl-PL
inherit                 {bootloadersettings}
osdevice                ramdisk=[boot]\instalki\winpe.wim,{ramdiskoptions}
systemroot              \windows
bootmenupolicy          Standard
detecthal               Yes
winpe                   Yes
ems                     No

Device options
--------------
identifier              {ramdiskoptions}
ramdisksdidevice        boot
ramdisksdipath          \boot\boot.sdi

pzdr

Co to znaczy "zrób logi FRST"?

https://www.fixitpc.pl/topic/61-diagnostyka-ogolne-raporty-systemowe/

pzdr

Jeżeli spiritus movens sprowadza się do programu uTorrent to logicznym wydaje się rezygnacja z tego softu na rzecz innego lub zmiana wersji.

Tym bardziej, że zdaje się ten klient ma wbudowany malware:

https://www.extremetech.com/computing/200602-utorrent-accused-of-bundling-cryptocurrency-malware-with-popular-bittorrent-client

Być może te dodatkowe funkcjonalności generują problem. Nie znam tego softu ale na podstawie innych klientów torrent wiem, że można w nich ustawiać obciążenie pamięci i systemu plików.

pzdr

Jeżeli podejrzewasz, że problem wywołuje oprogramowanie to proponuję wykonać raporty wg. instrukcji z działu pomocy doraźnej.

ps.

Z opisu nie wynikało, że inny komputer nie jest dell-em czy też ma odmienną konfigurację, w takim przypadku należy rozważyć również czynniki zewnętrzne, jakość zasilania - czy na linii nie pojawiają się przepięcia czy też spadki których zasilacz nie jest w stanie skompensować.

Druga rzecz - czynniki środowiskowe, temperatura (zwłaszcza duże wahania) czy wilgotność.

I trzecia rzecz skrajnie nieprawdopodobna (chyba, że wejdziemy w kompetencje ministra Antoniego), zakłócenia elektromagnetyczne (silne źródło promieniowania).

pzdr

Dość specyficzna konfiguracja, myślę że producent takiej stacji roboczej ma pewną wąską grupę "certyfikowanego" sprzętu który w takiej konfiguracji funkcjonuje prawidłowo, wszystkie modyfikacje mogą sprawiać kłopot. Oczywiście sprzęt zawiera generyczny zestaw kontrolerów ale z dużym prawdopodobieństwem jest on skonfigurowany inaczej niż w sprzęcie do samodzielnego złożenia.

Postulowałbym skorzystanie ze strony supportu i aktualizację biosu a następnie firmwaru kontrolera sata/sas:

http://www.dell.com/support/home/pl/pl/rc1078552/product-support/product/precision-t5500/drivers

Następnie dobranie odpowiedniej wersji sterownika (niekoniecznie najnowszej dostępnej), myślę że i tu dobrym pomysłem będzie sterownik podany na stronie supportu.

Na stronie są również dostępne pliki firmware dla poszczególnych dysków zalecanych do tej konfiguracji.

W tym temacie można znaleźć opis która wersja sterownika najlepiej współgra z danym kontrolerem w zależności od wersji firmwaru:

http://www.win-raid.com/t25f23-Which-are-the-quot-best-quot-Intel-AHCI-RAID-drivers.html

Osobiście miałem podobny problem na jednej z konfiguracji pojawiający się przy zapisie plików o dużej objętości (kilka GB), generował to program pocztowy (the bat) i/lub bittorrent, problem ustąpił wraz z którąś wersją firmwaru i/lub sterowników, był całkiem losowy - nie można było ustalić warunków w jakich dokładnie wystapi, dane nie ulegały uszkodzeniu (dało się odzyskać tablicę partycji) ale traciła ona system plików. W moim przypadku dotyczyło to konfiguracji RAID.

Mogę poradzić przestawienie kontrolera w inny tryb - jeżeli używasz trybu ahci to przestawić go w raid (nie wymaga to tworzenia macieży, z kontrolerem raid może współpracować również pojedynczy dysk).

Można też spróbować wyłączyć dla konkretnego dysku w menedżerze urządzeń bufor zapisu:

https://www.sevenforums.com/tutorials/10392-write-caching-enable-disable.html

Niektóre kontrolery (choć nie intel) mają również globalną opcję dla takiej funkcjonalności.

Możesz też troszkę zoptymalizować systemowe ustawienia ntfs, przede wszystkim wyłączyć indeksowanie dla rzeczonej partycji, dodatkowo można wyłączyć mniej istotne a obciążające dysk funkcje systemu ntfs takie jak "Last Access Time" czy "8.3 filename":

fsutil behavior set disable8dot3 1
fsutil behavior set disablelastaccess 1

Przy okazji dobry opis wykonania recovery z użyciem mechanizmu "provisioning packages".

https://msdn.microsoft.com/windows/hardware/commercialize/manufacture/desktop/deploy-push-button-reset-features

Jest to taki system który pozwala nam utworzyć plik ze wszystkimi zmianami utworzonymi w systemie po instalacji i późniejsze jego wykorzystanie podczas resetu do stanu początkowego, można też plik zintegrować z przywracanym obrazem.

pzdr

Program:

https://www.heidoc.net/joomla/technology-science/microsoft/67-microsoft-windows-and-office-iso-download-tool

Strona z dynamicznie tworzonymi linkami:

https://tb.rg-adguard.net/

pzdr

To by wskazywało na problem z zapisanie/zapamiętaniem ciastek, tak jakby edge stracił fokus na użytkownika - wg. opisów ciastka są wspólne z ie więc problem nie z zapisem (skoro ie działa) a z tym gdzie zapisać.

zawsze możesz spróbować odświeżyć edge:

pzdr

Standardowa procedura na początek w takiej sytuacji to pozbycie się ciastek.

pzdr

Reaent możesz pominąć, to jest systemowy mechanizm recowery, komendą ustawia się parametry uruchomienia dla winre.wim, można ustawić ścieżkę do winre, ścieżkę do obrazu systemu używanego w przywracaniu, parametry oem itp.

Tutaj się nie wykonuje bo mamy środowisko pe z dziesiątki i odwołujemy się do reagenta z siódemki. Wydaje mi się, że nie warto się bawić tym na siłę, jeżeli potrzebujesz tej dodatkowej funkcji można ją wymusić z systemu, składnia dla siódemki będzie troszkę inna.

Obrazki sugerują, że system rozruchowy nie może znaleźć odpowiednich plików więc albo nie ma do nich dostępu (odpowiednia partycja nie istnieje) albo nie ma na niej plików.

Tutaj wymagane jest małe wyjaśnienie, jak pisałem na wstępie zestaw oczekuje pewnej konwencji - w tym przypadku są to trzy partycje, pierwsza rozruchowa, startowa (czy jak się upiera MS systemowa) z kontenerem bcd, bootmgr itp., druga to oczywiście windows i trzecia to recowery, ine partycje - o ile istnieją - nie biorą udziału w zabawie. Partycje muszą zostać nazwane zgodnie z konwencją co gwarantuje, że mechanizm zastosowany w skryptach je rozpozna.

I teraz - wszystkie pliki odpowiedzialne za recovery muszą się znaleźć na partycji recovery, jeżeli umieścisz je na partycji boot to skrypt nie przypisze odpowiednio ścieżek.

sugeruje wprost, ze create.wim nie znajduje się na partycji przypisanej jako r: w ścieżce recovery.

Na tej partycji oprócz plików create.wim i restore.wim musi się też znaleźć plik ram dysku boot.sdi.

Wszystkie pliki powinien tam umieścić skrypt z postu

https://www.fixitpc.pl/topic/32342-tworzenie-własnego-recovery/#entry193666

o ile konwencja się zgadza (s:>boot, r:>recovery i w:>windows).

Brak plików w tej ścieżce powoduje, że wpisy bcd się nie wykonują.

Jeżeli pracujemy w trybie audytu to żadnym kontem się nie przejmujemy, pracujemy na wbudowanym koncie administratora które zostanie wyłączone po zapieczetowaniu, konta tymczasowego nie tworzymy i nie usuwamy.

Jeszcze raz przypominam, że pieczętowanie usunie klucz produktu i aktywację windowsa.

autounattend.xml jest specyficzną wersją pliku unattend.xml która może się znaleźć w głównym katalogu dowolnej partycji widzianej przez setup (może to być też płyta dvd, można go nawet wrzucić na partycję windowsa choć nie ma to sensu).

Setup wykona sekcję winpe z tego pliku po czym skopiuje go do windows\panther i reszta pliku wykonuje się już po restarcie z tej lokalizacji, o ile nie wskazaliśmy później naszego usb jako źródła dla jakiś skryptów to można je już wyjąć (nawet wskazane na wielu sprzętach).

Ale tutaj ponownie - moje skrypty korzystają z konwencji opisanej i zastosowanej w artykule o instalacji z wim i z punktu widzenia setapu ms są raczej bezużyteczne.

I znów dzięki konwencji wg. której oprócz odpowiednich partycji S,W,R mam też źródło N mogę wszystkie pliki i skrypty przekopiować wg. wzoru ze skryptu:

https://www.fixitpc.pl/topic/32342-tworzenie-własnego-recovery/#entry193666

Wszystkie wcześniej przygotowane pliki, skrypty itd. znajdują się w ścieżce N a ta już wedle uznania na usb (penie czy dysku), płycie (mało wygodne) czy w sieci (najwygodniej i działa najszybciej).

pzdr

Mogę jeszcze polecić processexplorer od sysinternals

https://technet.microsoft.com/pl-pl/sysinternals/processexplorer

Opcja jest trochę ukryta ale pokazuje bardzo dokładne wykresy obciążenia, zajętości pamięci itp.

pzdr

A co ma detekcja do tego po prostu karta ma takie a nie inne czujniki i tyle.

Właściwie to takie czujniki obsługuje bios bo chip może ich mieć więcej.

A np taki czujnik wentylatora jest wspólny (dla cpu) - w laptopach mamy (z regóły) jeden wiatrak dla kilku układów nawet jeżeli mamy oddzielną grafikę.

Jeżeli chodzi o pamięć to ta też jest wspólna i karta używa jej dynamicznie, normalnie można ustawić w biosach minimalne i maksymalne przydziały ale laptopy są bardzo upośledzone w kwestii takich ustawień.

ps.

Jak chcesz zobaczyć więcej sensorów to polecam hwinfo:

https://www.hwinfo.com/

Posiada spory zestaw tego co można w systemie zmierzyć i wyliczyć, można go uruchamiać w trybie pokazywania sensorów.

pzdr

Obrazy win najwygodniej edytować niezależnym narzędziem wimlib-imagex wg. shematu który opisałem w tym poście:

https://www.fixitpc.pl/topic/31405-instalacja-systemu-z-plików-wim-zautomatyzowana/#entry189262

oczywiście z właściwym skryptem, np.:

wstawi nam do pliku winpe.wim skrypty restore.cmd i wywołujący go winpheshl.ini (oczywiście możemy pierwszy skrypt wstawić jako starnet.cmd i pominąć ten drugi ale taka wersja jest bardziej elastyczna, przydatne na przyszłość), żeby dopełnić całości winphesl wygląda tak:

@del /S /F /A /Q w:\Users\Public\Desktop\sp.xml >nul

@del /S /F /A /Q w:\Users\Public\Desktop\zap.cmd >nul

 

Co to za pliki są? sp.xml i zap.cmd? Co ma się w nich znajdować?

To tajemnica!

No dobra niech będzie - to pliki do pieczętowania.

Pierwszy to prosta komenda która uwalnia nas od ręcznego wpisywania długiej komendy (pieszczenia lenia):

Druga to plik odpowiedzi użyty podczas pieczętowania, system po zapieczętowaniu ponownie wykonuje fazy instalacyjne i tak jak przy pierwotnej instalacji możemy ten proces zautomatyzować.

Jak już pisałem ja preferuję pracę nad systemem w trybie audytu i zapieczętowanie a więc taki plik np. może służyć do ustawienia konta użytkownika i pominięcia ekranu oobe, np.:

 
<?xml version="1.0" encoding="utf-8" ?> 
<unattend
	xmlns="urn:schemas-microsoft-com:unattend">
	<settings pass="specialize">
		<component name="Microsoft-Windows-International-Core" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS"
			xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"
			xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
			<InputLocale>0415:00001045</InputLocale>
			<SystemLocale>pl-PL</SystemLocale>
			<UILanguage>pl-PL</UILanguage>
			<UILanguageFallback>pl-PL</UILanguageFallback>
			<UserLocale>pl-PL</UserLocale>
		</component>
	</settings>
	<settings pass="generalize">
		<component name="Microsoft-Windows-Security-SPP" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS"
			xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"
			xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
			<SkipRearm>1</SkipRearm>
		</component>
	</settings>
	<settings pass="oobeSystem">
		<component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS"
			xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"
			xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
			<UserAccounts>
				<LocalAccounts>
					<LocalAccount wcm:action="add">
						<DisplayName>ktośtam</DisplayName>
						<Name>ktośtam</Name>
						<Group>Administrators</Group> 
						<Password>
							<Value>dwBpAGUAbABjAGUAdABhAGoAbgBlAGgAYQBzAEIBbwA=</Value>
								<PlainText>false</PlainText>
							</Password>
						</LocalAccount>
					</LocalAccounts>
				</UserAccounts>
				<AutoLogon>
					<Enabled>true</Enabled>
					<Username>ktośtam</Username> 

					<Password>
						<Value>dwBpAGUAbABjAGUAdABhAGoAbgBlAGgAYQBzAEIBbwA=</Value>
							<PlainText>false</PlainText>
						</Password>
					</AutoLogon>
					<FirstLogonCommands>
						<SynchronousCommand wcm:action="add">
							<Order>1</Order>
							<Description>antyeko</Description>
							<CommandLine>powercfg -setactive 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c</CommandLine>
						</SynchronousCommand>
						<SynchronousCommand wcm:action="add">
							<Order>2</Order>
							<Description>antyeko1</Description>
							<CommandLine>powercfg -x -monitor-timeout-ac 0</CommandLine>
						</SynchronousCommand>
						<SynchronousCommand wcm:action="add">
							<Order>3</Order>
							<Description>antyeko2</Description>
							<CommandLine>powercfg -x -disk-timeout-ac 0</CommandLine>
						</SynchronousCommand>
						<SynchronousCommand wcm:action="add">
							<Order>4</Order>
							<Description>antyeko3</Description>
							<CommandLine>powercfg -x -standby-timeout-ac 0</CommandLine>
						</SynchronousCommand>
						<SynchronousCommand wcm:action="add">
							<Order>5</Order>
							<Description>antyeko4</Description>
							<CommandLine>powercfg -h off</CommandLine>
						</SynchronousCommand>
					</FirstLogonCommands>
					<OOBE>
						<HideEULAPage>true</HideEULAPage>
						<ProtectYourPC>3</ProtectYourPC>
						<SkipUserOOBE>true</SkipUserOOBE>
						<SkipMachineOOBE>true</SkipMachineOOBE>
						<NetworkLocation>Other</NetworkLocation>
					</OOBE>
					<VisualEffects>
						<FontSmoothing>ClearType</FontSmoothing>
					</VisualEffects>
				</component>
			</settings>
		</unattend>

Co ciekawe pliku nie trzeba wywoływać z sysprep-em ale można umieścić bezpośrednio w katalogu panther (czy to dla setup-u czy samego syspprep-a).

ps. Ciekawe czy ktoś zgadnie hasło .

@dism /Capture-Image /CaptureDir:w:\ /imagefile:r:\RecoveryImage\install.wim /name:"Recovery image"

przy tej komendzie wyskakuje mim że opcja capture-image jest nieznana

Po prostu niewłaściwa wersja, tak jak pisałem przy systemie instalacji tak i tutaj warto sięgać po najnowszy pakiet czyli winpe dla systemu 10 (dostępne w pakiecie adk), jeżeli chcesz korzystać z winpe dla siódemki to trzeba pamiętać że dism nie obsługiwał obrazów wim i trzeba dodać do zestawu imagex (bądź wspomniany wcześniej wimlib-imagex) z odpowiednimi wywołaniami.

pzdr

Na początek tytułem wyjaśnienia - bliżej mi do Chama niż do Pana.

Już nie pamiętam wszystkich szczegółów dotyczących tych starych skryptów - nieszczególnie z nich korzystałem (co myślę o recovery chyba jasno przedstawiłem) natomiast świta mi jedno - należało je wykonać w trybie audytu wtedy konto się nie powtarzało, ew. można było pracować na koncie "temp" i użyć pliku odpowiedzi który je kasował.

Nowe skrypty z założenia są dużo prostsze, przede wszystkim działają na czystym winpe (nie wymagają obsługi skryptów itp.), oczywiście są one uniwersalne w kontekście całego systemu instalacji (wymagają odpowiedniego nazewnictwa), jeżeli zachowamy konwencję którą opisałem w artykule to są one całkowicie bezpieczne dla innych partycji systemu.

W założeniu takie skrypty łapią obraz ad hoc. nie ingerują w niego więc to czy system wstanie z użytkownikiem czy bez zależy wyłącznie od sposobu zamknięcia systemu, możemy pieczętować, pieczętować z plikiem odpowiedzi, zamknąć na czysto.

To też zależy od tego na jakim koncie pracujemy, ja preferuję przygotowanie systemu w trybie audytu i późniejsze zapieczętowanie tylko trzeba pamiętać, że to zeruje aktywację i wyrzuca klucz produktu (nie problem jeżeli to aktywacja OA), z tym że ja przygotowuję obrazy do klonowania (deploing) a nie reco sensu stricte.

Skrypt instalacyjny nie przewiduje automatyzacji reco, przewiduje tylko utworzenie partycji o określonym rozmiarze (w szablonie jest to 15GB) ale oczywiscie możemy sobie i ten aspekt oskryptować, np. taki skrpyt wykonany po instalacji jeszcze w trybie winpe:

Przerzuci wszystkie niezbędne pliki na wcześniej przygotowaną partycję, mamy tutaj też kopiowanie pliku odpowiedzi dla trybu nienadzorowanego a capture.cmd to plik inicjujący który podałem wcześniej (znajdzie się na pulpicie).

pzdr

Troszkę mylisz pojęcia moim zdaniem, oddzieliłbym proces instalacji systemu od procesu tworzenia recovery. To podczas instalacji należy sobie zainstalować sterowniki i programy dedykowane dla danej maszyny a następnie złapać recovery. Z prywatnej wiadomości odniosłem wrażenie, że chcesz utworzyć obraz do przenoszenia między maszynami - nie do tego służy recovery, z zasady jest to obraz spersonalizowany dla danej maszyny, oczywiście można w pewnych warunkach uzyskać obraz uniwersalny pod warunkiem, że same maszyny nie różnią się zbytnio konfiguracją.
 
Odnośnie procesu instalacji proponuję sięgnąć po metodę opisaną w tym cyklu:
https://www.fixitpc.pl/topic/31405-instalacja-systemu-z-plików-wim-zautomatyzowana/
 
Jest ona na pewno wygodniejsza i szybsza od standardowego setupu od MS zwłaszcza jeżeli proces instalacji wykonujemy dość często, myślę że wygodny system instalacyjny może skutecznie zastąpić recovery.
Recovery ma jedną zasadniczą wadę, jego "aktualność" jest ściśle związana z momentem jego utworzenia, przywrócony system z reguły wymaga odświeżenia (windows update, sterowniki, również oprogramowanie), jeżeli natomiast zadbamy o nasze repozytorium instalacyjne to możemy mieć zawsze pod ręką świeży system, nie wymagający zbytniej atencji po postawieniu w przeciwieństwie do recovery.
Oczywiście dbanie o "świeżość" repozytorium jest zajmujące (i przy wielu wersjach systemu bardzo czasochłonne), wszystko zależy jak często musimy sięgać po reinstalację i jak wielu maszyn to dotyczy.
 
Podsumowując:
recovery > przywiązujemy do komputera, sterowniki i programy instalujemy przed złapaniem recovery, prawidłowo przygotowane recovery nie "niszczy" się po przywróceniu.
Instalacja > jeżeli chcemy mieć system aktualny nie sięgamy po recovery ale po świeżą instalację a skupiamy się na dbaniu o aktualność repozytorium.
 
Trudno napisać jakąś uniwersalną receptę na instalację programów w sposób zautomatyzowany, niestety niezależnie od faktu czy nasz soft będzie bazował na zunifikowanych pakietach instalacyjnych (np. innosetup) niestety przełączniki dotyczące silent install będą się znacząco różniły, nie da się zagadnienia sprowadzić do "instalacji programów" jest to raczej zagadnienie "instalacji programu".
Niestety trzeba się skupić na konkretnych pakietach i szukać dokumentacji dla konkretnego programu.
 
Ze sterownikami jest troszkę łatwiej - mamy tu pewną standaryzację (oczywiście są wyjątki, ale dotyczą one nie tyle sterowników co pakietów im towarzyszących).
Same sterowniki możemy dodać w dwóch trybach które podzieliłbym na: sterowniki dodawane w fazie preinstalacji (zintegrowane z obrazem wim lub - lepiej - zintegrowane z obrazem offline) i druga faza postinstall (dodane z użyciem mechanizmów unattend i mechanizmów systemu - pnpinst lub dpinst).
Dpinst sprowadza się do wrzucenia na dysk lokalny repo sterowników i wywołaniu odpowiedniej komendy, reszta zrobi się sama (musimy tylko zadbać o to żeby repo nie zawierało pakietów konfliktujących ale z doświadczenia wiem, że to rzadko się zdarza).
Są to skomplikowane zagadnienia a ja nie czuję się na siłach (zwłaszcza w sposób zrozumiały dla laika) tego opisywać, myślę że trzeba by tu przygotować prezentację i skupić się w niej na konkretnym scenariuszu. Nie będę zahaczał o integrację sterowników w trybie "pre" dość napisać że mowa o integracji z użyciem dism i nie ma problemu ze znalezieniem dokumentacji w sieci natomiast w fazie post z użyciem unattend jest banalnie proste.
Po pierwsze w fazie winpe umieszczamy odpowiedni pakiet na partycji instalacyjnej a do pliku odpowiedzi dodajemy wpis (bodź dwa zakładając, że chcemy posprzątać), oba w fazie "obbe" albo (co ja preferuję) pierwszy w fazie "specialize":
 

- <component name="Microsoft-Windows-Deployment" 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">
- <RunSynchronous>
- <RunSynchronousCommand wcm:action="add">
  <Order>1</Order>
  <Path>%systemdrive%\tmpdrive\$WinPEDriver$\x86\dpinst.exe</Path>
  <Description>Instalacja sterowników</Description>
  </RunSynchronousCommand>
  </RunSynchronous>
  </component>

i sprzątanie:

- <SynchronousCommand wcm:action="add">
  <Order>10</Order> 
  <Description>Oczyszczanie</Description> 
  <RequiresUserInput>false</RequiresUserInput> 
  <CommandLine>cmd.exe /c rmdir /s /q %systemdrive%\tmpdrive</CommandLine> 
  </SynchronousCommand>

samemu dpinst towarzyszy bardzo prosta konfiguracja nakazująca przeszukać wszystkie podkatalogi w poszukiwaniu sterowników:

  <?xml version="1.0" ?> 
- <dpinst>
  <quietInstall /> 
  <enableNotListedLanguages /> 
  <legacyMode /> 
  <scanHardware /> 
  <suppressAddRemovePrograms /> 
- <search>
  <subDirectory>*</subDirectory> 
  </search>
  </dpinst>

To tyle.
Jeżeli po instalacji nadal interesuje nas recovery to można to zrobić dużo prościej niż to pisałem przed laty, bez uciekania się do vbs (który był dość kapryśny więc zawodny), dość napisać że całość sprowadza się do przygotowania dwóch obrazów pe (jeden jednorazowy dla łapania reco drugi dla przywracania) i prostego skryptu inicjującego, oczywiście do zagadnienia możemy jeszcze dołączyć kwestię czy pieczętujemy obraz (i problemy z kluczem instalacji i aktywacją które temu towarzyszą).
Nie chcę się rozpisywać na ten temat, to wymaga raczej artykułu (bądź uzupełnienia wcześniej przywołanego) zademonstruję tylko same przykładowe skrypty:
inicjacja procesu:

Jeżeli te klucze się opierają przejęciu wg powyższej recepty to można spróbować odpalić edytor rejestru z delegacją uprawnień do "system" albo TrustedInstaller np. z pomocą nsudo:

http://zh-cn.b0.upaiyun.com/NSudo/NSudo%204.0.zip

Zachowaj szczególną ostrożność, program w tym trybie może być bardzo destrukcyjny.

Najlepiej zrób kopię rejestru wg. instrukcji:

https://www.fixitpc.pl/topic/318-tworzenie-kopii-zapasowej-rejestru/

Zajrzyj też do katalogu:

%USERPROFILE%\AppData\Local\Packages\

pzdr

Nie ma co wymyślać koła od nowa

https://websetnet.com/pl/take-ownership-registry-keys-windows-10/

Przeszukaj rejestr pod kontem tego pakietu zwłaszcza jeżeli będzie koherentne ze sklep/store itp.

Katalogi usunąłeś?

Obawiam się, że więcej nie pomogę, nie odtworzę tego u siebie. zabezpieczenia komputera i sieci uniemożliwiają mi jakiekolwiek zabawy z modern apps UWP nawet w czystym systemie (maszyna wirtualna).

pzdr