Portál AbcLinuxu, 26. dubna 2024 23:22
Zdravím,
rád bych zkusil btrfs. Navzdory subvolumes bych určitě chtěl 500 GB SSD rozdělit na / a /data. /data bude zvlášť oddíl, na kterém budou data a nejedná se o oddělené /home. Oboje by mělo být šifrováno pomocí luks. Něco jsem o tom načetl, ale pořád mám pár nejasností:
Díky za nasměrování
Řešení dotazu:
Díky, podívám se na to.
Tak jsem si dal openSUSE do virtuálu a docela mě překvapilo, kolik subvolumes instalátor vytvořil. Také vytvořil zvlášť oddíl pro swap. To jsem právě předpokládal, že udělá jako subvolume, ale vytvořil pro něj oddělený oddíl. Pokud bych tedy chtěl používat swap a mít /rootfs i swap šifrované, tak abych nemusel heslo zadávat 2x, musel bých mezi LUKS a btrfs dát ještě LVM, že?
Díky za odpověď.
Já to teď mám podle tohoto. Jak už jsem psal výše, používám ext4 a mám vytvořeno více oddílů. Díky LVM zadám heslo jen jednou. Myslím, že kdybych neměl LVM, tak bych musel každý oddíl odemykat zvlášť. Rozhodl jsem se, že swap dělat nebudu, takže LVM potřeba nebude. Instalátor v / defaultně vytvoří @ a @home. Já asi ještě nějaké pododdíly taky vytvořím viz. instalace openSUSE, ale vše bude na jednom fyzickém oddílu, takže heslo pro odemčení LUKS budu zadávat jen jednou a hotovo.
Ještě bych potřeboval nasměrovat:
Musím prosím tě všechny pododdíly a kvóty pořešit při instalaci, nebo stačí základní instalace s @ a @home a zbytek dodělat až v nainstalovaném systému?
Nevadí, i tak díky :)
Já teď řeším, jestli vůbec btrfs budu moci použít. Hrál jsem si dnes s Qubes(em) a uvažuji o tom, že na něj přejdu. Instalátor mi ale btrfs vůbec nenabídl, tak nevím, jestli to půjde předpřipravit. Zatím jsem se na netu nedíval.
Ještě jednou díky. Ať se ti daří.
10.1.2020 20:25
btrfs-convert. Samozřejmě když disk není připojen. Pak musíte ještě pohlídat to, aby jádro podporovalo btrfs (nebo se zprovoznil aspoň už v initramfs).
Použil jsem to u ext4 oddílu pod LVM, ale raději jsem si předem udělal LVM snapshot (abych nepřišel o data kdyby se náhodou něco stalo – nebyl to jen čerstvý systém). Po připojení oddílu (teď už btrfs) se ale něco zbláznilo a neukazovalo to žádné soubory. Pomohl restart, funguje.
No k tomu převodu jsem právě trochu skeptický. k3dAR tu psal, že s tím moc dobrou zkušenost nemá. Spíše to předem připravit, ne?
13.1.2020 19:52
13.1.2020 20:24
btrfs-convert. Je lepší si nechat na začátku disku nealokované místo, kde po instalaci vytvoříš ten správný filesystém. Původní oddíl pak můžeš odstranit a nový zvětšit na celý disk (proto to místo na začátku).
install_items+=" /.root.key " add_dracutmodules+="resume" add_devices+=" /dev/mapper/by-label/SWAP "Pripadne swap partitionu popisat podla /dev/disk/by-uuid/... alebo hocijak inak.
Díky, podívám se na to.
To odemykání by bylo možná lepší pořešit podle Andreje.
/dev/urandom. (Takhle to má ve „výchozím“ nastavení Gentoo.)
Já osobně kdybych dělal swap, tak jen kvůli uspávání na disk. Kvůli ničemu jinému.
Toto je cca 10. iterace téhož / podobného dotazu, že jo. Odpověď je pořád stejná:
Nedělit, nedělit, nedělit. Dělení je vždycky špatně. Když si uživatel myslí, že chce dělit, pak je na návrhu celého „úložiště“ něco špatně.
Kdyžtak násobit (Btrfs RAID a spol.), ale rozhodně nedělit.
Jak to zašifrovat a neoddělovat /boot? To už se tu přece řešilo nekonečno-krát: GRUB umí bootovat z LUKS bez problému už asi 5+ let.
LUKS má víc slotů na klíče nebo hesla. Tím se dá zařídit, že se heslo zadá jenom jednou — pro GRUB — a pak už se vše odemkne automaticky, když bootuje kernel a chce šifrovaný root připojit. Stačí mít v initramfs / initcpio soubor s klíčem pro ten LUKS a patřičně nastavit /etc/crypttab. To je celé. Protože initramfs je na šifrovaném /boot, klíč je v něm v bezpečí a načte ho společně s initramfs GRUB — na základě uživatelova hesla (jiný key slot).
Pro každé distro je na tohle^^^ několik howto.
Když jsem tento dotaz pokládal, tak jsem chtěl na jeho konec napsat:
@Andrej:
Já vím, nedělit, nedělit, nedělit!
Řeknu ti, co mě k dělení vede a třeba mi to vyvrátíš. Chci disk rozdělit proto, protože chci dát data na sólo oddíl, abych při přeinstalaci systému nemusel znovu překopírovávat všecha svoje data na ten disk. Prostě by tam byl šifrovaný oddíl, kterého bych se ani nedotkl a jen bych na volné místo znovu nainstaloval systém (LUKS+btrfs).
Včera jsem zkoušel Qubes. Zkoušel jsem jej na plotnovém disku. Bylo to hrozně pomalé. Na webu Qubes důrazně doporučují použít SSD. To sice mám, ale co se týká rychlostí, tak asi jen ~ 540/520 MB/s. To na klasické distro bohatě stačí, ale pro ten Qubes uvažuji o 256 GB NVMe disku ~ 3500/1300 MB/s. Tam by se data nevešla, ale mohl bych je dát na ten SSD a pak je připojovat do /data. Takže by nešlo o oddělené /home. No a teď mi vysvětli, co je na tom špatného?
Uvažoval jsem totiž tak, že kdybych ten SSD měl jako subvolume pro /home (@home), tak bych nevěděl co si počít při přeinstalaci? Nevěděl bych (pokud to lze), jak pak k systému @home přiřadit a taky by v @home byla data programů, které by ještě ani nebyly nainstalovány a nejsem si jist, jestli bych to uměl nějak solidně pořešit?
Jak to zašifrovat a neoddělovat /boot? To už se tu přece řešilo nekonečno-krát: GRUB umí bootovat z LUKS bez problému už asi 5+ let.Tu sa skôr natíska otázka, ako pohodlne zabezpečiť že ten GRUB nebude kompromitovaný, a neodchytí prvé heslo. Už sú hotové nástroje ktoré vygenerujú kľúč, napchajú ho do TPM, podpíšu ním GRUB, zapnú SecureBoot a vyhodia cudzie kľúče ktoré tam nemajú čo hľadať? Rád by som si také hotové nástroje pozrel.
Myslíš tohel? Akorát nevím, zda je to "pohodlné".
Jsem zapomněl, že to vyžaduje oddělený /boot. Pokud to ale lze obejít pouhým nadzvednutím baterie na desce, tak je to z mého pohledu na nic.
Jo, a nebo bych mohl komp zazdít neznámo kam a husím krkem jen přivést kabely k napájení, netu a monitoru, ne? A kdyby to doma po příchodu vypadalo jako na staveništi, tak by bylo jasné, že komp někdo zkompromitoval 
vim ze to asi pred rokem nekdo pripravil pro Debian ci Ubuntu, ted to nemuzu najit...Ahoj Aleši,
jen se tě chci zeptat. Když bych měl systém v pc i nb na ext4 a data bych měl na jiných oddílech naformátovaných na Btrfs, takže by ta data nebyla v /home na ext4 a zálohy těch dat bych měl na dalších discích, které by taky byly naformátovány na Btrfs. Bylo by to tak pro ta data OK? Jde mi teď pouze o cow. Vyhnul bych se tak silent data corruption?
Díky oběma
Díky
15.1.2020 13:38
/dev/disk/by-partlabel.
Takže jsem se rozhodl, že zatím na Btrfs naformátuji pouze disky a oddíly s daty a systémové ponechám na ext4, protože zatím je pro mne nedosažitelné nainstalovat systém s neodděleným /boot nad LUKS+Btrfs. Budu s tím zatím experimentovat a až se to vystříbří, tak pak, pokud budu s Btrfs spokojen, jej použiju i pro OS's.
Takže vyřešeno/nevyřešeno.
EFI oddíl dělám. Respektive ten skript, co pro mě laskavě napsal k3dAR. Ale funguje mi právě jen s ext4. Když jsem v něm změnil ext4 na btrfs, tak po instalaci, právě při samostatné instalaci GRUBu to vytuhlo. Budu si s tím teď prostě "hrát" a až to poladím, tak pak přijde na řadu Sicherboot. Chce to postupně, no.
No s tím jsem tě právě nechtěl obtěžovat. Ale kdybys to udělal, tak to bys byl borec :) A úplně nejlepší by bylo, kdybys tam udělal volitelné LVM.
BTW: na nějakém fóru Mintu jsem taky našel nějaký skript, ale ten byl mnohem delší než ten tvůj a vůbec jsem se v něm neorientoval. Když jej najdu, odkážu.
A ještě jedna věc. Pokud se tedy do toho opravdu pustíš, tak by bylo asi dobré tam zakomponovat vytváření subvolumes a nastavení quotas. Když jsem si informativně nainstaloval to openSUSE, tak to instalátor vytvořil takto:
Akorát jsem se nepodíval na nastavení quotas. Pokud bys ale chtěl, tak to znovu nainstaluji na 100 GiB oddíl, protože takový bych v reálu použil a můžu ti sem hodnoty quotas dát??
Ještě mě napadlo:
Instaluji si Mint i na flešku, která má kapacitu 32 GB, USB 3.0. Nic bych nedělil. Udělal bych pouze EFI 256 MB(?) a zbytek místa by byl pro systém. Je vhodné použít Btrfs? Ptám se kvůli snapshotům.
To jsem si myslel. Dík
As another example, the widely used USB flash or SD cards use a translation layer between the logical and physical view of the device. The data lifetime may be affected by frequent plugging. The memory cells could get damaged, hopefully not destroying both copies of particular data in case of DUP.
A pokud vím, tak každá buňka má pouze omezený počet přepsání, kdežto pouhé čtení je v pohodě.
To má i SSD.
No to mám právě já, flešku s MLC :)
... ale v pripade USB donglu se prepisujou porad stejny bunky ...
Tady Aleš píše:
... jelikož neustále převaluje datové bloky z jedné strany na druhou.
Nebylo by tedy řešením použít právě Btrfs?
In practice, flash file systems are used only for Memory Technology Devices (MTDs), which are embedded flash memories that do not have a controller. Removable flash memory cards and USB flash drives have built-in controllers to manage MTD with dedicated algorithms, like wear leveling, bad block recovery, power loss recovery, garbage collection and error correction, so use of a flash file system has limited benefit.
A další věc je, že když už by sis chtěl nějaký ten Flash file system zkusit, tak tvůj hw jej nemusí plně podporovat. Což mě v souvislosti s tím, co jsem uvedl výše (citace v angličtině) vede k tomu, že lze klidně na takovouto flešku použít ext4.
~$ sudo mkfs.f2fs -f -l WEDOS /dev/sdb F2FS-tools: mkfs.f2fs Ver: 1.11.0 (2018-07-10) Info: Disable heap-based policy Info: Debug level = 0 Info: Label = WEDOS Info: Trim is enabled Info: [/dev/sdb] Disk Model: DISK 1.001.00?? Info: Segments per section = 1 Info: Sections per zone = 1 Info: sector size = 512 Info: total sectors = 30752848 (15016 MB) Info: zone aligned segment0 blkaddr: 512 Info: format version with "Linux version 5.3.0-26-generic (buildd@lgw01-amd64-039) (gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1)) #28~18.04.1-Ubuntu SMP Wed Dec 18 16:40:14 UTC 2019" Info: [/dev/sdb] Discarding device Info: This device doesn't support BLKSECDISCARD Info: This device doesn't support BLKDISCARD Info: Overprovision ratio = 1.640% Info: Overprovision segments = 249 (GC reserved = 129) Info: format successful
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.