Skocz do zawartości

maggreg

Użytkownicy
  • Postów

    649
  • Dołączył

  • Ostatnia wizyta

Treść opublikowana przez maggreg

  1. Nie ma się co spinać bo w przypadku win7 i "dużego" brandu klucz z naklejki i tak nie ma nic wspólnego z tym na którym system był postawiony fabrycznie. W związku z powyższym: 1. Cała zabawa w odzyskiwanie da nam klucz SLP który i tak jest publicznie dostępny, klucza z naklejki który "się wytarł" na dysku nie znajdziemy (no chyba, że ktoś wcześniej reinstalował czysty system właśnie z tym kluczem). 2. Nie potrzebujemy klucza z naklejki bo możemy system zainstalować z kluczem SLP (dowolnym ale przyjmijmy, że oryginalny ASUS będzie najlepszy ze względów licencyjnych) i odpowiednim certyfikatem. Jak pisałem klucze są dostępne w sieci a i certyfikat się znajdzie (odpowiedni SLIC mamy przecież w biosie): http://forums.mydigitallife.info/threads/10370-Windows-7-OEM-SLP-Key-Collection http://forums.mydigitallife.info/threads/5952-OA-2-x-SLIC-amp-OEMCERT-Collection pzdr
  2. maggreg

    Bios. Bootowanie z LAN

    Być może producent nie przewidział dla tego modelu mozliwości wyłączenia takiej opcji. Przeszukaj jeszcze inne zakładki pod kątem PXE, dla botowania w uefi może to być IP4 (i IP6). Jeżeli system jest postawiony na dysku GPT to można też spróbować wyłączyć botowanie w trybie legacy, co prawda nie odetnie to opcji uruchomienia z sieci całokowicie ale większość serwerów nie jest skonfigurowana dla trybu efi lub jest on nieprawidłowy i komputer nie dostanie prawidłowego loadera a więc się nie uruchomi, to obejście zadziałą też z usb, większość gwizdków narzędziowych jest skonfigurowana do botowania w trybie mbr więc bardzo to ograniczy (choć nie uniemożliwi) zastarotowanie z pena. pzdr
  3. maggreg

    Bios. Bootowanie z LAN

    Szukaj w "advance" opcji opisanej jako pxe lub netboot. pzdr
  4. Być może miałeś błędy w tablicy alokacji które zostały naprawione przed operacją (obligatoryjny checkdisk) powodujące, że pusta przestrzeń była alokowana jako zajęta. pzdr
  5. W takim razie klucz jest traktowany jako jednorazowy i nie ma potrzeby jego zapamiętania/zapisania, ale to dyskusja akademicka bo w przypadku kiedy mamy naklejkę COA możemy mieć system zainstalowany z kluczem z naklejki bądź SLP, inne byłyby naruszeniem licencji. Ponadto @piespawlowa nie pisał, że odczytuje mu BBBBB (wynik kodowania base24), pisał tylko że odczytuje nieprawidłowe dane (patrz moje wcześniejsze sugestie), przydałoby się też dowiedzieć jaki to brand laptopa i edycja systemu, wtedy można by skonsultować czy jest to znany SLP. pzdr
  6. Klucz z dremsparka powinien się zapisać w rejestrze standardowo (bo istnieje fizycznie), natomiast w przypadku licencji - nazwijmy je ogólnie - wielostanowiskowych które aktywują się poprzez serwer KMS klucz dla pojedynczej maszyny nie istnieje, po prostu identyfikator sprzętu zdejmuje jednostkę z ogólnej puli a fizyczny klucz przypisany jest do KMS. Oczywiście w przypadku jakiś instalacji instytucjonalnych istnieją rożne wariacje powodujące rozbieżność między licencją a kluczem, od ponad dziesięciu lat pracuję przy produkcji komputerów i widziałem już nawet sytuację w której z licencją home był instalowany win pro (nomen omen dla policji, oczywiście na wszystko była umowa z MS). Generalnie jeżeli klucz nie jest zapisany w rejestrze to nie da się go odczytać czyli albo nie istnieje albo jest jednorazowy (czyli licencja nie uwzględnia reinstalacji) więc jego zapamiętanie jest zbędne. Tutaj natomiast obstawiam, że część naklejki która daje się odczytać nie zgadza się z tym co podają programy (bo SLP) i pewnie stąd cały temat. pzdr
  7. W kwestii formalnej, skrypt odpalałeś z uprawnieniami administracyjnymi? Jeżeli nie to może nie odczytać odpowiedniej gałęzi rejestru (brak uprawnień). Skrypt w instancji administratora można odpalić przez cscript lub wscript z poziomu konsoli odpalonej w trybie administratora, można też sam skrypt troszkę poprawić aby wymuszał odpowiednie uprawnienia: 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 Set WshShell = CreateObject("WScript.Shell") strFile = "key.txt" Set objFSO = CreateObject("Scripting.FileSystemObject") If Not objFSO.FileExists(strFile) Then objFSO.CreateTextFile(strFile) End If Set objFile = objFSO.OpenTextFile(strFile, 2) MsgBox ConvertToKey(WshShell.RegRead("HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DigitalProductId")) objFile.writeline ConvertToKey(WshShell.RegRead("HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DigitalProductId")) objFile.Close Function ConvertToKey(Key) Const KeyOffset = 52 ' Offset of the first byte of key in DigitalProductId - helps in loops isWin8 = (Key(66) \ 9) And 1 ' Check if it's Windows 8 here... Key(66) = (Key(66) And &HF7) Or ((isWin8 And 2) * 4) ' Replace 66 byte with logical result Chars = "BCDFGHJKMPQRTVWXY2346789" ' Characters used in Windows key ' Standard Base24 decoding... For i = 24 To 0 Step -1 Cur = 0 For X = 14 To 0 Step -1 Cur = Cur * 256 Cur = Key(X + KeyOffset) + Cur Key(X + KeyOffset) = (Cur \ 24) Cur = Cur Mod 24 Next KeyOutput = Mid(Chars, Cur + 1, 1) & KeyOutput Last = Cur Next ' If it's Windows 8, put "N" in the right place If (isWin8 = 1) Then keypart1 = Mid(KeyOutput, 2, Cur) insert = "N" KeyOutput = keypart1 & insert & Mid(KeyOutput, Cur + 2) End If ' Divide keys to 5-character parts a = Mid(KeyOutput, 1, 5) b = Mid(KeyOutput, 6, 5) c = Mid(KeyOutput, 11, 5) d = Mid(KeyOutput, 16, 5) e = Mid(KeyOutput, 21, 5) ' And join them again adding dashes ConvertToKey = a & "-" & b & "-" & c & "-" & d & "-" & e ' The result of this function is now the actual product key End Function End If WScript.quit Jeżeli skrypt nadal nie zadziała to w edytorze rejestru przejdź do właściwego klucza:"HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" i sprawdź czy istnieje wartość binarna DigitalProductId i czy możesz ją odczytać i (masz uprawnienia i nie jest uszkodzona). edit. Jeszcze jedno, napisałeś: Co to oznacza? Pamiętaj, ze programy odczytają klucz na którym system został zainstalowany ale ten w przypadku producentów OEM nigdy nie pokryje się z tym co masz na naklejce ponieważ - jak już wcześniej pisałem - producenci stosowali w przypadku systemów z linii XP do 7 jeden wspólny klucz dla wszystkich produkowanych w ramach jednego brandu komputerów, ułatwiało to produkcję i umożliwiało automatyczną aktywację. Tak więc wracając do cytatu, programy nie odczytują nic czy też to co odczytuję nie pokrywa się z naklejką (prawidłowo)? pzdr
  8. Jest jeszcze ProduKey od nirsoftu: http://www.nirsoft.net/utils/product_cd_key_viewer.html Klucze SLP powinny się odczytać bez problemu ponieważ są zapisane w rejestrze, jeżeli nie to na tej stronie: http://forums.mydigitallife.info/threads/10370-Windows-7-OEM-SLP-Key-Collection wyszukaj klucz właściwy dla twojego brandu (klucze są jednakowe dla wszystkich egzemplarzy wyprodukowanych przez danego producenta o ile stosuje mechanizm SLP). ps. odświeżony skrypt VBS z dodaną obsługą win8 wygląda tak: Set WshShell = CreateObject("WScript.Shell") strFile = "key.txt" Set objFSO = CreateObject("Scripting.FileSystemObject") If Not objFSO.FileExists(strFile) Then objFSO.CreateTextFile(strFile) End If Set objFile = objFSO.OpenTextFile(strFile, 2) MsgBox ConvertToKey(WshShell.RegRead("HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DigitalProductId")) objFile.writeline ConvertToKey(WshShell.RegRead("HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DigitalProductId")) objFile.Close Function ConvertToKey(Key) Const KeyOffset = 52 ' Offset of the first byte of key in DigitalProductId - helps in loops isWin8 = (Key(66) \ 9) And 1 ' Check if it's Windows 8 here... Key(66) = (Key(66) And &HF7) Or ((isWin8 And 2) * 4) ' Replace 66 byte with logical result Chars = "BCDFGHJKMPQRTVWXY2346789" ' Characters used in Windows key ' Standard Base24 decoding... For i = 24 To 0 Step -1 Cur = 0 For X = 14 To 0 Step -1 Cur = Cur * 256 Cur = Key(X + KeyOffset) + Cur Key(X + KeyOffset) = (Cur \ 24) Cur = Cur Mod 24 Next KeyOutput = Mid(Chars, Cur + 1, 1) & KeyOutput Last = Cur Next ' If it's Windows 8, put "N" in the right place If (isWin8 = 1) Then keypart1 = Mid(KeyOutput, 2, Cur) insert = "N" KeyOutput = keypart1 & insert & Mid(KeyOutput, Cur + 2) End If ' Divide keys to 5-character parts a = Mid(KeyOutput, 1, 5) b = Mid(KeyOutput, 6, 5) c = Mid(KeyOutput, 11, 5) d = Mid(KeyOutput, 16, 5) e = Mid(KeyOutput, 21, 5) ' And join them again adding dashes ConvertToKey = a & "-" & b & "-" & c & "-" & d & "-" & e ' The result of this function is now the actual product key End Function pzdr
  9. maggreg

    SQL 2005 standard

    Proponuję zapytać na http://wss.geekclub.pl/forum-board/sql-server. pzdr
  10. Kontakt z http://niebezpiecznik.pl/. Konsultacja z prawnikiem. Zgłoszenie do swojego dostawcy usług internetowych, powinien pomóc w ustaleniu i blokadzie ip sprawcy, potem kontakt z dostawcą sprawcy i blokada po jego stronie. pzdr
  11. Płyta powinna sobie poradzić z haswell refresh ale możesz spróbować obsadzić wcześniejszą wersją. Dobry test, polecam wszystkim, jeżeli płyta wstaje a zawiesza się na post teście to mimo wszystko reaguje na przycisk power, powinna się wyłaczyć, jeżeli się nie wyłącza > prawdopodobnie nie startuje procesor. warto zajrzeć w podstawkę, może ma uszkodzony, wygięty pin, czasami procesor nie dostaje zasilanie (wtedy będzie zimny nawet po kilku minutach pracy), wtedy albo zasilacz albo wada płyty. Na początek warto też spróbować reset cmosu a najlepiej fizycznie usunąć baterię na parę minut przy wyłączonym zasilaniu. pzdr
  12. W plopie upewnij się , że setup->bootmanager->force usb1.1 jest ustawione na no, jeżeli jest dostępna zakładka usb mode to powinna być na 2 (w nowych wersja plop chyba jej nie ma). Zabootuj, sprawdź prędkość, odpal usb hosts i sprawdź zakładkę ehci, czy adres fizyczny wskazuje na cokolwiek innego niż zera, zgaduję że również w idx powinno się coś pojawić. Z dysku jak wyżej, ew mozna powtórzyć test po wyłączeniu w biosie usb mass stor (o ile tego typu opcja jest dostępna). ps transfer wystarcza na pewno jeżeli usb będzie pracować w trybie 2 (ehci) inaczej może być różnie nawet pod windowsem, biorąc pod uwagę lepsze buforowanie to 12 i tak jest teorią - w praktyce ok 30% ucieka na operacje do tego pamiętajmy, że jest to prędkość całej linii (huba) i zalezy od tego ile urządzeń hub obsługuje, byłby do osiągnięcia tylko jeżeli każdy port usb byłby podpięty bezpośrednio do szyny procesora (kontrolera). pzdr
  13. Najpierw odniosę się do linuxa bo twoja niechęć jest o tyle ciekawa, że jest to właśnie rozwiązanie o które walczysz. Otóż jeżeli przyjmiemy, że zależy ci na programowym odłączeniu napędu usb a następnie załadowaniu właściwego sterownika to jest to właśnie to co robi linux przechodząc w tryb chroniony (tak naprawdę robi to każdy 32 i więcej bitowy system), jeżeli to nie działa i z jakiegoś powodu urządzenie nadal tkwi w trybie ohci do czasu fizycznego odłączenia to znaczy, że nie da się tego zrealizować programowo (choć nadal pozostaje plop do sprawdzenia), gdyby nie fakt, że najwyraźniej fizyczny replug pomaga zastanawiałbym się czy w ogóle chip pracuje w trybie ehci (czy chociażby nie jest on fizycznie wyłączony). Upieram się, że nie sterownik massstorage jest problemem ale sama konstrukcja biosu a najprawdopodobniej chipsetu. Sam problem jest zresztą opisany w linku który podałem (rozdział 3 punk 1) z adnotacją, że nie wiadomo skąd się bierze, jest tam też opisane dlaczego tak mało z teoretycznego transferu usb pozostaje w dosie (czyli teoretyczne 12 może być mniej niż praktyczne 4). Można łatwo zweryfikować czy to sterownik sam w sobie stanowi problem, wystarczy go nie wystartować, choć to trudne bez napędu to zweryfikowało by wątpliwości. Podejrzewam, ze start z płyty w momencie kiedy pen byłby podpięty i tak skutkowałby by tym samym problemem do czasu replugu pomimo, że starownik massstorage (hddusb) nie byłby aktywny. Osobiście spotkałem już się z podobną sytuacją na chipie via, nie można było zainstalować windowsa bez całkowitego dezaktywowania usb na ten czas bo instalator wieszał się w momencie przejścia w tryb chroniony, usb można było uaktywnić dopiero po zainstalowaniu sterowników od via. pzdr
  14. 4Mbps czy 4MB/s? 4Mbps to troszkę lepiej niż vhs czyli rozdziałka jakieś 320x240? Nic nie musi wyłączać sterowników biosowych bo one (napiszę to po raz kolejny choć już tracę cierpliwość) służą tylko do rozpoznania i wystartowania sprzętu w przeciwnym razie coś takiego jak usbaspi nie byłoby potrzebne - prawda? Reszta - przeczytaj jeszcze raz uważnie o różnicy między ohci a ehci. pzdr
  15. Jeżeli nie masz napędu to i tu jest sposób, po prostu uruchom plopa z pena (wersja flopkowa zmapuje się tak samo jak to co wcześniej przerabialiśmy a i wersję iso się da zmapować) następnie już z poziomu plop wybierz ponownie start z usb, plop w przeciwieństwie do dosa powinien sobie dać radę. Pisząc o trybach miałem na myśli to, czy da się użyć trybu usb 2 co powinno poskutkować aktywowaniem sterownika ehci. Generalnie można uprościć ohci <> usb 1.1 <> prędkość 12Mbit, ehci <> usb 2 <> prędkość 480Mbit, jest to uproszczenie bo w teorii tryby mogą pracować niezależnie od poziomu usb ale w praktyce to się sprowadza do tego poziomu. Teraz kwestia sterownika biosowego, on generalnie odpowiada za rozpoznanie i wystartowanie urządzeń, później już system korzysta z własnego sterownika choć może użyć warstwy bios w trybie rzeczywistym. Problemem nie jest sterownik jako taki a fakt, że serownik startuje w trybie ohci (pewnie tak było w czasie świetności tego chipu właściwie ze względu na kompatybilność) a sterownik dosowy nie potrafi się przełączyć w tryb ehci puki urządzenie jest fizycznie podłączone. To że nie potrafi tego dos nie znaczy, że nie zrobi tego linux a jeżeli nawet nie zrobi tego w momencie botu to powinien w momencie przejścia w tryb chroniony (czyli kiedy właściwy linux przejmie kontrolę nad sprzętem), różnica prędkości portu czterdziestokrotna w praktyce mało który pen osiągnie taki odczyt (w praktyce około 30MB). Podsumowując linux nie korzysta ze sterownika biosu i na pewno nie jest nim ograniczony po przejściu w tryb chroniony. Ale najpierw spróbuj plop. ps. dość kompleksowy opis usb w dosie właśnie znalazłem pod linkiem: http://www.xaver.me/drdoswiki/index.php?n=Main.USB choć nie jest najświeższy to w przypadku dosa raczej niewiele poszło do przodu (choc limitu plopa z 2007 r. można pominąć) pzdr
  16. Jedyne co się na tych fotkach rzuca w oczy to fakt, że kontroler ehci jest nieaktywny (pusty adres) a więc usb pracuje w trybie pierwszym. Już o tym wspomniałem mimo chodem ale powtórzę - spróbuj odpalić pena z pomocą plop (z płyty) i zobacz czy kontroler też będzie blokowany (i w jakim trybie wystartuje. Jeżeli się uda coś osiągnąć to będzie przyczynek do dalszych pomysłów. pzdr
  17. Błąd logiczny. Linuxowy umount odmontuje tylko to co wcześniej zamontował linuxowy mount. Czyli to samo co wcześniej napisałem, mógłbyś próbować wyrzucić sterownik który zamontował dos ale takiego nie ma w tym przypadku. pzdr
  18. W takim razie to nie jest problem dosa, i nic z jego poziomu nie zdziałasz, oznacza to, że port usb pozostaje zablokowany aż do fizycznego odłączenia. Dos nie ma dostępu do tego poziomu sterownika więc nie ma czego programowo usuwać. Nie wiem natomiast czy nie da się czegoś takiego zrobić z poziomu grub4dos, trzeba by poszukać, jeżeli nawet nie ma takiej komendy to grub4dos ma możliwość dokonywania na gorąco zmian w pamięci komputera ale obawiam się, że zidentyfikowanie obszaru w którym siedzi "blokada" i jej wyłączenie to wyższa matematyka. Poszperaj w tych tutorialach: http://www.rmprepusb.com/tutorials/grub4dos może znajdziesz podobne zagadnienie, ew. zadaj pytanie autorowi tej strony. Jeszcze jedno, czyli jak rozumiem kiedy mapujesz freedos to pen się nie montuje jako c:? ps. Powyższe zachowanie, żeby nie było nieporozumień, jest charakterystyczne dla twojego sprzętu, nie jest to problem dos+usb czy dos+g4d+usb ale problem powyższych w koniunkcji z twoim zestawem. pzdr
  19. Aspi powinno być ładowane do pamięci wysokiej czyli: devload /h usbaspi.exe /w /v /e parametr /e powoduje wymuszenie trybu ehci czyl de facto trybu usb2, pozostałe dwa włączają tryb verbose i potwierdzenia. Kiedyś był loader do sterowników podobny do devloaad który posiadał również funkcję odinstalowania wcześniej zamontowanego sterownika, jakoś to działało ale nie pomnę nazwy. Czym próbujesz ugryźć ten film? Może wrzuć gdzieś pliki to będzie można spróbować jak to działa i wykluczyć problemy. pzdr
  20. System sam z niego korzysta, jest on wbudowany w kernel.sys i odpala się podczas startu systemu, nie da się go wywołać ponownie. Jeszcze jedna sprawa wyjaśnienia, bo napisałeś wcześniej, że sytuacja jest analogiczna do wcześniejszych doświadczeń czyli dos na A: i pen na C:, ale skoro bootowałeś bezpośrednio z pena w trybie usbhdd to raczej napęd A: nie występował. Jest jeszcze jedna opcja odseparowania części pena z danymi ale wymaga to pena który to obsługuje (a raczej chipu dla którego istnieje odpowiedni soft), można część pena zamienić w usncdrom i wtedy będzie traktowany przez bios jako dwa oddzielne urządzenia, wtedy część z danymi zamontujesz jako cd (albo odwrotnie chociaż tutaj trzeba będzie zastosować pewne triki aby dos startował z iso). pzdr
  21. Jak pisałem, freedos ma wbudowany własny sterownik, dlatego pojawia się c:, ale nic nie stoi na przeszkodzie żeby użyć sterownika i wtedy uzyskasz napęd d:, tylko nie wiem czy szybszy od tego z freedosa. I żeby była jasność - freedos nie montuje napędu odziedziczonego po boocie, jeżeli w czasie startu będziesz miał wpięte inne urządzenia to też je przypisze. Można oczywiście użyć innego dosa, wtedy pen się nie przypisze ale pojawią się inne problemy (jak np fat32 itp), jak byś miał szukać alternatywy to polecam calderę. Można też zamiast obrazu dyskietki użyć obraz dysku i mapować jako hd0 wtedy pen zostanie zablokowany a dos pojawi się jako C:. Oczywiście jeżeli prędkość jest kluczowa to wypadałoby jeszcze dodać sterowniki buforujący, coś typu SMARTDRV. Może jednak linux, jeżeli nawet nie zapewni akceleracji na tym sprzęcie to już sama architektura 32bit da dużego kopa wydajnściowego. pzdr
  22. grub4dos ma własną obsługę usb, oczywiście bazuje ona na dosie ale wnosi wiele poprawek które mają spowodować takie samo działanie niezależnie od sprzętu. I właśnie o to chodzi, że napęd mapowany działa niezależnie od źródła na którym znajdował się obraz który mapujemy. Nic nie musimy odłączać programowo ponieważ napęd usb nie jest dla takiego systemu zamontowany (z małym wyjątkiem ale o tym za chwilę). Przykład który podałeś jest prawidłowy z tym, że grub4dos obsługuje prostszą składnię niż podana na większości forów. Wystarczy coś takiego: map --mem /aa.img (fd) cały kod dla obrazu dyskietki mapowanego w ram wygląda np tak: title dos map --mem /opendos.ima (fd0) map --hook chainloader (fd0)+1 rootnoverify (fd0) Spreparowałem małą paczkę z tego co znalazłem na dysku + aktualny freedos: https://www.sendspace.com/file/thnvac W paczce jest przykładowe menu dla gruba i obraz do mapowania, w obrazie wrzuciłem kilka serowników do wyboru ale jeżeli nie zadziała panasonic (w paczce zarówno ostatni oficjalny 2.27 jak i mod 2.28) to marne szanse, że zadziałają inne, dodatkowo USBEXFAT.COM który zamontuje wszystkie odmiany fat. Na moim sprzęcie np żaden dosowy usb nie zadziała (choć działają na maszynie wirtualnej), dlatego ew mogę zbudować coś takiego: title dos map --mem /opendos.ima (fd0) map /hdimage.ima (hd0) map --hook chainloader (fd0)+1 rootnoverify (fd0) To z poziomu uruchomionego dosa będzie widoczny także dodatkowy napęd zamontowany jako hd0. Taki napęd możemy oczywiście dla bezpieczeństwa mapować do ram ale to chwilę potrwa (zależnie od wielkości). Mała uwaga, jeżeli chcemy aby fizyczny napęd był także widziany to musimy pamiętać aby nie montować nic jako hd0 (jak wysoko zamontować zależy od ilości fizycznych dysków), chyba że montujemy obraz dysku który ma zostać zabotowany wtedy musimy zamienić kolejność np.: map (hd0) (hd1) map (hd1) (hd0) map -- hook #lub rehook jeżeli hook był już wcześniej) Nie będę pisał jak zainstalować grub4dos bo na sieci jest tego na pęczki, podam tylko (bo tą informację trudno znaleźć) że aktualne wersje znajdują się pod adresem: http://grub4dos.chenall.net/categories/downloads/#year_2014 Stronka trochę zagmatwana więc dopiszę, że ściągamy to co mamy w linijce zaczynającej się od "File:". ps. Jeżeli upierdliwy bios ma problem z botowaniem usb (nawet jeżeli w ogóle nie obsługuje takiej opcji, np. w vmware) możemy wystartować z pakietu plop który emuluje odpowiednie opcje: http://www.plop.at/en/bootmanagers.html Pora wrócić do "małego wyjątku" - otóż freedos obsługuje napęd usb out-of-box bez dodatkowych sterowników ale nie musimy go odłączać, po prostu sterownik aspi założy nam napęd dodatkowy. pzdr
  23. Tu masz tutka kolegi @mgrzeg: https://www.fixitpc.pl/topic/11092-analiza-dlugiego-startu-systemu/ możesz przeanalizować wg niego start systemu i poszukać ew. "mułków". Dysk, pomijając prędkość jako taką, ma dość zrównoważony odczyt, nie widać zacięć czy dołów więc sprzętowo raczej ok. pzdr
  24. Grub4dos używa własnego sterownika który rozwiązuje wiele problemów kompatybilnosciowych, ponadto z poziomu dosa uruchomionego z napędu mapowanego możesz sobie zamontować pena (bo nie był wcześniej zamontowany). Napęd zmapowany jest napędem tymczasowym więc zapis na nim nie ingeruje w strukturę oryginalnego obrazu, dla mnie to zaleta choć to zależy oczywiście czy dane mają zostać zapamiętane. Ogólnie wg mnie warto zmapowac sobie nie tylko czysty dos ale całą zawartość i uniezależnić się od operacji odczytu zapisu na usb, niestety przy ogólnej stabilności dosu której nie poprawia jakość sterowników usb takie dosowe napędy bardzo łatwo i często tracą dane i/lub dostęp do napędu. Drzewiej dość często używałem dosa zarówno przy produkcji komputerów (operacje konfiguracyjne, updaty firmwaru) jak i np. systemy sprzedaży (POS-y dosowe odpalane na terminalach bezdyskowych) i bywało z tym różnie, dużo płyt głównych np miało tendencje do odpalania usb w trybie zgodności z usb1. Dziś używam dosa tylko z obrazów i choć na co dzień raczej mapowanych z sieci to i na usb trochę narzędzi się znajdzie i będę się upierał, że to dużo wygodniejsze rozwiązanie niż bootowanie dosa bezpośrednio z napędu. pzdr
  25. Dyski SSD samsunga mają tendencję do degradacji transferu w czasie użytkowania, co prawda głośno było o tym w kontekście dysków serii EVO ale dotyczy to także serii PRO, niestety w przeciwieństwie do EVO producent nie opublikował poprawki na tą przypadłość dla dysków pro (nawet chyba nie odniósł się do problemu), można polecić upgrade fw jeżeli nie był robiony. pzdr
×
×
  • Dodaj nową pozycję...