Nelze nabootovat po obnově systému (dd)

[Trubicoid2]

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.

[Reklama]

[trubicoid2]

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

[Martin]

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. (?)

[trubicoid2]

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?

[Martin]

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).

[Reklama]

[trubicoid2]

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

[nobody(ten pravej)]

no a nebo pouzit partclone ktere preskakuje prazdne i smazane casti, kdyz uz pouziti clonezilla co ho pouziva je moc nobl ;-)

[Vít Šesták (v6ak)]

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á).

[drzubr]

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?

[JardaP .]

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.

[j]

...
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.

[ByCzech]

To jako vazne? Tak to si honem pobezim koupit.

Ubunťákům nemůžeš všechno věřit. Často píšou dost blbostí.

[JardaP .]

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.

[trubicoid2]

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

[Skid]

Ubunťákům nemůžeš všechno věřit. Často píšou dost blbostí.

V pripade HP bych jim i veril.