Fórum Root.cz
Hlavní témata => Software => Téma založeno: drzubr 01. 03. 2018, 08:47:26
-
Ahoj,
mám notebook HP ProBook s 256GB SSD a na něm nainstalovaný Debian9
Partitions na /dev/sda:
1 - /boot/efi
2 - /
3 - swap
=======
Př. 1. Pokud pomocí dd a gzip vytvořím image z LIVE distribuce a následně ho na disk obnovím vše funguje.
Př. 2. Pokd však mezi zálohou a obnovou disk přepíšu nulama (/dev/zero) a pak přes LIVE distribuci obnovím tu samou zálohu jako z příkladu 1. notebook nenabootuje a hlásí že nemá system disk.
Předem díky za nápady
-
odpoved je takova, ze delas neco spatne. ale jelikoz jsi nenapsal prikazy, tak ti asi tezko nekdo rekne kde je problem.
zkus poslat prikazy jak delas backup a restore a pak uz ti snad nekdo i pomuze...
-
no pokial mas grub cez UUID tak predpokladam ze tam bude problem....
-
Takhle "z vlaku" bez vstupnich informaci bych rekl, ze problem bude s UEFI ...
-
no pokial mas grub cez UUID tak predpokladam ze tam bude problem....
Jak vzniká UUID? Já měl za to, že je to jednorázově generované a poté uložené v info o oddílu (ale nic jsem o tom nečetl/nehledal, jen můj pocit). Protože pokud by dělal dd celého disku (tedy /dev/sda) a ne jednotlivých oddílů, mělo by podle mé myšlenky být UUID stejné...
Jak už ale bylo řečeno - bez příkazů se nehneme.
-
no pokial mas grub cez UUID tak predpokladam ze tam bude problem....
Jak vzniká UUID? Já měl za to, že je to jednorázově generované a poté uložené v info o oddílu (ale nic jsem o tom nečetl/nehledal, jen můj pocit). Protože pokud by dělal dd celého disku (tedy /dev/sda) a ne jednotlivých oddílů, mělo by podle mé myšlenky být UUID stejné...
Jak už ale bylo řečeno - bez příkazů se nehneme.
Přesně tak. V UUID problém není.
-
Příliš málo informací, problém může být na tolika místech, že se bez dalšího infa nehneme a můžeme leda tak střílet poslepu...
-
backup:
dd if=/dev/sda conv=sync,noerror status=progress | gzip -c > /mnt/extdisc/xxx.img.gzzero:
dd if=/dev/zero of=/dev/sdarestore:
gunzip -c /mnt/extdisc/xxx.img.gz | dd of=/dev/sda conv=sync,noerror status=progress
Pokud neprovedu ten přepis nulama, tak to funguje.. pro oba příklady používám úplně totožné příkazy
-
no je to jaksi zvlášní, jako by se něco navíc přepsalo
píše ten dd při nulování a při zápisu stejný počet sektorů?
-
Je to způsobené HP biosem - pokud to provedu jako instalaci v legacy mode, tak to pak funguje i po přepsání nulama.
Když to provedu tak jako na začátku v EFI mode tak to po přepsání nulama nefunguje ikdyž je v BIOSU vypnutý Secure Boot. Vypadá to že když vypnu SecureBoot dovolí mi bootovat jen z LegacyMode ale ne z UEFI.
Přitom KALI linux z usb flash v UEFI mode nabootuje, ale interní disk ne, tam jak kdyby to vyžadovalo WINDOWS.
-
Mel bych pribuzny dotaz. Nez se dela zaloha disku (dd + gzip), je dobre vynulovat nevyuzity prostor na FS kvuli lepsi kompresi. Pokud pouzivam SSD, neni lepsi vyplnit nevyuzity prostor 0xFF. Zkoumal jste to nekdo?
-
Je to způsobené HP biosem - pokud to provedu jako instalaci v legacy mode, tak to pak funguje i po přepsání nulama.
Když to provedu tak jako na začátku v EFI mode tak to po přepsání nulama nefunguje ikdyž je v BIOSU vypnutý Secure Boot. Vypadá to že když vypnu SecureBoot dovolí mi bootovat jen z LegacyMode ale ne z UEFI.
Přitom KALI linux z usb flash v UEFI mode nabootuje, ale interní disk ne, tam jak kdyby to vyžadovalo WINDOWS.
Mrkněte na utilitu efibootmgr (co to píše před a po), případně do efivars...
-
Mel bych pribuzny dotaz. Nez se dela zaloha disku (dd + gzip), je dobre vynulovat nevyuzity prostor na FS kvuli lepsi kompresi. Pokud pouzivam SSD, neni lepsi vyplnit nevyuzity prostor 0xFF. Zkoumal jste to nekdo?
a jakej presne by melo mit naplneni ff vliv?
-
a jakej presne by melo mit naplneni ff vliv?
je jedno jestli se nepouzite misto zaplni ff nebo 00, jde o to ze pujde o totozne znaky, takze pri komprimaci nebudou zabirat misto...
bez tohoto "naplneni" by se zbytecne do gz(nebo jineho) archivu ukladala/komprimovala data nachazejici se na volnem prostoru ktera zbyla po jejich predchozich smazani...
-
a jakej presne by melo mit naplneni ff vliv?
je jedno jestli se nepouzite misto zaplni ff nebo 00, jde o to ze pujde o totozne znaky, takze pri komprimaci nebudou zabirat misto...
bez tohoto "naplneni" by se zbytecne do gz(nebo jineho) archivu ukladala/komprimovala data nachazejici se na volnem prostoru ktera zbyla po jejich predchozich smazani...
Co se tyce komprese ano, je to jedno. Myslel jsem na to SSD, ze by ho prepis 0xFF mene zatezoval, bunky by vlastne byly jen smazane.(?)
-
No na hdd se data kódují RS kódem kvůli opravě chyb a kvůli tomu, aby nebylo moc jedniček vedle sebe. Pak 00 a ff je jedno, maj podobnou reprezentaci. Badblocks používá ff, 55, aa a 00, asi v tom nějaká logika je.
U ssd nevím, jestli se data kódují, asi jo, kvůli chybám. Navíc ssd umí trim, a řadič z trimovaného místa vrací většinou 00. Tak mi ff nedává moc smysl.
-
teda bych si myslel, že přepisovat SSD je blbost vždy, jakýmkoli patternem, to už radši celej označit trimem, jako smazaný, to se do buněk nic zbytečně nezapíše a disk je kompletně prázdný a trimovaný:
https://www.thomas-krenn.com/en/wiki/SSD_Secure_Erase
-
teda bych si myslel, že přepisovat SSD je blbost vždy...
Me se nejedna o prepis celeho SSD, ale jen volneho mista na FS konstantnim vzorem pro lepsi kompresi. Pokud FS/OS umi trim, co vrati cteni ze zatrimovane bunky?
Navic nektere flash pameti neumi trim (typicky flash disk). Pokud lowlevel zapisuju same FF do flash, vlastne do ni nepisu. Samozrejme nasledny zapis asi nezkouma, ze je bunka plna FF a tedy ze by ji nemusel mazat, ale mozna ze mazani jiz smazane bunky mene ublizuje. (?)
-
Me se nejedna o prepis celeho SSD, ale jen volneho mista na FS konstantnim vzorem pro lepsi kompresi.
tak to by slo udelat pak i jen na image souboru a netrapit SSD, ne? mount -o loop ...
Pokud FS/OS umi trim, co vrati cteni ze zatrimovane bunky?
melo by vracet 0x00, ale nektery to nedelaji
Navic nektere flash pameti neumi trim (typicky flash disk). Pokud lowlevel zapisuju same FF do flash, vlastne do ni nepisu. Samozrejme nasledny zapis asi nezkouma, ze je bunka plna FF a tedy ze by ji nemusel mazat, ale mozna ze mazani jiz smazane bunky mene ublizuje. (?)
toto nejak nechapu, bunky se musi smazat stejne, ne? to mazani podle me je to co skodi
a smazana bunka je teda podle tebe nastavena na FF?
-
tak to by slo udelat pak i jen na image souboru a netrapit SSD, ne? mount -o loop ...
melo by vracet 0x00, ale nektery to nedelaji
toto nejak nechapu, bunky se musi smazat stejne, ne? to mazani podle me je to co skodi
a smazana bunka je teda podle tebe nastavena na FF?
Jo, slo by pomci dd zkpirovat SSD na HDD (co do souboru na HD), tam vycistit volne misto na FS, ale to hodne prace navic.
Pokud by kazdy chapal otrimovanu bunku jako bunkou plnou stejnych bajtu, pak by se cistit nemuselo.
Jo, flash cipy mazou sektory (treba 4KB) na FF, pak lze zapisovat nuly celkem libovolne (nekdy i s bitovou granularitou, napr flash v STM32F4, lze zapsat hodnotu a pak prepsat jinou hodnotou ale bity lze pouze nulovat a nebo nemenit).
-
tak to zkus, já myslím stačí na SSD pustit před zálohou trim a to volné místo bude vynulováno, pokud nemáš fakt divný SSD
-
no a nebo pouzit partclone (https://partclone.org) ktere preskakuje prazdne i smazane casti, kdyz uz pouziti clonezilla (https://clonezilla.org) co ho pouziva je moc nobl ;-)
-
Co vím, tak obecně po TRIMu není chování vyTRIMovaného místa definováno, ale SSD může mít nějaké flagu - DRAT (deterministic read after TRIM, tedy přečtete tam něco nedefinovaného, ale pokaždé to bude totéž) a DZAT (deterministic zero after trim, tedy budou tam nuly).
Jestli přepisovat nulama, 0xff, nebo něčím jiným - to bude asi dost HW-specific, s trochou smůly se to může lišit i u různých kusů modelu se stejným označením. Jestli je firmware dostatečně chytrý, aby při nějakém specifickém patternu udělal interně TRIM, můžeme spekulovat, případně se to můžeme pokusit odhadnout side channelem. Já bych to takto neřešil a prostě TRIMoval, zvlášť pokud to zařízení má DZAT. A i v případě DRAT bez DZAT se dá čekat nějaký dobře komprimovatelný pattern.
BTW, pokud to SSD bude automaticky TRIMovat při nějakém patternu a má DRAT, mělo by to jít celkem snadno zjistit. Vzhledem k DZAT trochu hádám, že to obvykle budou samé nuly (pokud je ta fíčura implementovaná).
-
Je to způsobené HP biosem - pokud to provedu jako instalaci v legacy mode, tak to pak funguje i po přepsání nulama.
Když to provedu tak jako na začátku v EFI mode tak to po přepsání nulama nefunguje ikdyž je v BIOSU vypnutý Secure Boot. Vypadá to že když vypnu SecureBoot dovolí mi bootovat jen z LegacyMode ale ne z UEFI.
Přitom KALI linux z usb flash v UEFI mode nabootuje, ale interní disk ne, tam jak kdyby to vyžadovalo WINDOWS.
Mrkněte na utilitu efibootmgr (co to píše před a po), případně do efivars...
Nakonec jsem to vyřešil pomocí tohoto návodu https://ubuntuforums.org/showthread.php?t=2238714 = celkově pro mě děsivá zkušenost s UEFI (pouze jsem tam přepsal UBUNTU na DEBIAN).
Je použití debianu v EFI modu něčím přínosne pokud nepotřebuji bootovat z disku > 2TB?
-
Nakonec jsem to vyřešil pomocí tohoto návodu https://ubuntuforums.org/showthread.php?t=2238714
To je dobre, tohleto:
"HP and Sony only boot Windows. So we have many work arounds, some work better than others.
Since you do not have any Windows you can just create the Windows efi boot file with the Windows name. Then the UEFI will think it is booting Windows but really boots grub."
To jako vazne? Tak to si honem pobezim koupit.
-
...
To jako vazne? Tak to si honem pobezim koupit.
Jo, to jako fakt, sem na HPcku instaloval veracrypt, a samozrejme to nenabootovalo. Kdyz sem pak hledal proc, tak proste protoze je to HP, takze rucni editace souboru v efi partysne ... lol.
-
To jako vazne? Tak to si honem pobezim koupit.
Ubunťákům nemůžeš všechno věřit. Často píšou dost blbostí. ;)
-
Ubunťákům nemůžeš všechno věřit. Často píšou dost blbostí. ;)
Mozna. Mas lepsi vysvetleni? HP BIOS tu zminil uz i nekdo predtim.
-
Je použití debianu v EFI modu něčím přínosne pokud nepotřebuji bootovat z disku > 2TB?
asi ne, mohlo by to bejt rychlejsi? a moh bys pouzivat podepsany jadra? nic z toho za ten uefi oprusk imho nestoji
taky mam hp stanici a taky se muselo cachrovat a prepisovat na widlous, ted mam legacy a hotovo
-
Ubunťákům nemůžeš všechno věřit. Často píšou dost blbostí. ;)
V pripade HP bych jim i veril.
-
Ubunťákům nemůžeš všechno věřit. Často píšou dost blbostí. ;)
Mozna. Mas lepsi vysvetleni? HP BIOS tu zminil uz i nekdo predtim.
Obě ruce levé? ;-)
S těmi HP BIOSy/UEFI firmwary, které bootují jen Windows je to taková urban story, kdy uživatelé nechápou jak UEFI funguje a pak říkají takové nesmysly. Zatím pokaždé, když mi to někdo tvrdil, tak jsem mu předvedl, že to je blbost. Různého HW mi prochází rukama dost a ještě jsem takový nezažil (ne že by na druhou stranu nebyly často roztodivně zabugované a co kus to unikát, který je schopen dělat věci "naokolo je to blíž"). Prostě to jen neumějí nastavit a používat - neznalost.
-
Ubunťákům nemůžeš všechno věřit. Často píšou dost blbostí. ;)
V pripade HP bych jim i veril.
Ale jo, já jim věřím, že se na tom zasekli, ale nevěřím, že to je tím co říkají a jak to řeší :)
-
Ale jo, já jim věřím, že se na tom zasekli, ale nevěřím, že to je tím co říkají a jak to řeší :)
Nerozporuju, pokud u toho clovek fyzicky nesedi, nema moc sanci krome dobreho tipu prijit na to, cim to je. Ale zrovna u HP bych se fakt nedivil vubec nicemu vcetne strasidel. ;D ;D ;D