Fórum Root.cz
Hlavní témata => Software => Téma založeno: Ħαℓ₸℮ℵ ␏⫢ ⦚ » 25. 03. 2020, 08:27:35
-
Je nějaká možnost, jak opravit linux? V bootovacím procesu se ukáže žlutě DEPENDENCY něco jako failed to reach target filesystems.mount (po úpravě filesystému a přidání do /etc/fstab, nejde o existující oddíl, ale přidal jsem tam nový další)
Tlačítko Enter nefunguje (Press enter to enter recovery console)
Unable to login. Root account is locked. For help, see sulogin(8).
Je nějaká možnost, jak se "přenést" do živé konzole bootu a něco tam poštrachat?
Běžně se dá použít druhý bootovací záznam v boot manageru, ale to zde nejde, zde není.
-
Nějaký live distro z flashky a opravit ten fstab?
-
Ano, nabootuj zive distro, zedituj /etc/fstab (minimalne vyhod automaticke mountovani dotycneho svazku) a melo by to byt OK. Zdanlive banalni problem, ale potrapi.
-
mimochodem, neexistuje nějaký parametr pro cmdline který by řekl něco "ignorovat fstab" nebo zakázal mountnout konkrétní jednotku z fstab?
console=tty1 root=PARTUUID=ff2b7cf1-02 rootfstype=ext4 elevator=deadline rootwait
Momentálně jsem v nouzovém stavu, OS X nepodporuje ext4 (kde je fstab) a M$ windows nedokáže jednotku (ta nová partition, kterou jsem vytvořil) ani "vybrat" (je tam nějaká kolize identifikátorů, ), takže asi snad se budu muset připojit přers otg redukci do smartphonu , kde se s tím snad poradí (+ hubu na připojení klávesnice)
Stalo se to tak, že jsem vytvořil nový oddíl, ale nenaformátoval. Prostě nešel naformátovat (asi se nějak nerefreshly údaje v kernelu), ale zapomněl jsem zakomentovat záznam v fstab.
-
Obvykle by to mělo jít napravit i bez live distra, pouze kernelu poslat parametry:
root=/dev/xxx init=/bin/sh
následně v shellu přemountovat filesystem na read-write a pak už tradá editovat
mount / -o remount,rw
a toto funguje, dokud je v pořádku initrd. Pokud je initrd nakopnutý, obvykle se to dá řešit natažením starší verze (co jsem se setkal, tak distribuce uchovávaly starší jádra a jejich initrd).
-
Díky, tohle mě zrovna teď nenapadlo. ačkoli to mám připravené , že mám v souboru /boot/cmdline.txt-init právě připsáno init=/bin/bash, aby stačilo jen přejmenovat soubor)
Jen by mě zajímalo, zda opravdu systemd (nebo obecně bootovací proces linuxu) nemá nějaký mechanismus (například klávesovou zkratku), aby se šlo dostat do boot procesu přímo na tom počítači, když ho spustím, abych nemusel vůbec "přesedlávat" na jiný počítač a ručně na jiném PC editovat grub.cfg, cmdline.txt, atd. nebo rovnou opravovat?
co to tedy znamenalo, že mi to psalo že mě to chtělo dát do recovery console (opakuji, nejde o jiný bootovací record, je tam jen jeden). Ale nějak to selhalo na přihlášení jako root, jestli to chápu dobře.
-
Jen by mě zajímalo, zda opravdu systemd (nebo obecně bootovací proces linuxu) nemá nějaký mechanismus (například klávesovou zkratku), aby se šlo dostat do boot procesu přímo na tom počítači, když ho spustím, abych nemusel vůbec "přesedlávat" na jiný počítač a ručně na jiném PC editovat grub.cfg, cmdline.txt, atd. nebo rovnou opravovat?
Grub zeditujete přímo v jeho menu, pomocí klávesy `e` a po zeditování jen spustíte pomocí C-x.
Druhý počítač ani live distro není potřeba.
-
Jen by mě zajímalo, zda opravdu systemd (nebo obecně bootovací proces linuxu) nemá nějaký mechanismus (například klávesovou zkratku), aby se šlo dostat do boot procesu přímo na tom počítači
Nemá a taky mě to strašně krká -- zejména pokud se čeká na službu s dlouhým timeoutem (síť má defaultně 5 minut!) nebo dokonce s no limit.
Podle cmdline.txt předpokládám, že jde o Raspberry Pi. To bohužel řeší nějaký jednoduchý bootloader, který toto neumí. Plnotučné bootloadery (na PC třeba GRUB, na jiných embedded deskách uboot) to umí.
-
Je to Raspberry π,ale některé provokatéry to popuzují a mají pak potřebu kvůli tomu vlákno zaštěkat.
Plnotučné bootloadery (na PC třeba GRUB, na jiných embedded deskách uboot) to umí.
To sice jo, ale já myslel něco, co nezávisí na bootloaderu (separátní recovery záznam v grubu nebo prostě možnost ručně zadat boot parametry ), prostě něco, čím půjde vstoupit do procesu bootování v této fázi.
-
Live distra netřeba. Stačí zadat kernelu parametr init=/bin/bash, boot skočí do shellu. Pak remountnout /
mount -o remount,rw /
a dá se upravovat. Pak sync, remountnount ro a restartnout.
-
Taky je resenim nepouzivat distribuce se systemd :-)
-
1. u emergency hlaska "Root account is locked" znamena ze je root ucet zamceny, coz je vychozi stav, pokud uzivateli root ty nenastavis heslo (v regulernim Debian instalatoru zalezi zda zvolis heslo pro root, pak je odemcen, nebo jen heslo pro uzivatel, pak je uzivatel pridan do sudo skupiny ale root ucet je zamcen
BTW: v *buntu i kdyz nechas roota deaktivovaneho se do emergency normalne dostanes...
=> tedy pro priste, v Raspbianu odemknes roota nastavenim mu hesla: sudo passwd root
2. polozky v fstab lze jadernym parametrem docasne zakazat, syntaxt parametru je: systemd.mask=adresar-kam-se-mel-pripojit.mount
tedy pokud si do fstab pridal pripojeni neceho do /mnt/neco, tak: systemd.mask=mnt-neco.mount
-
Taky je resenim nepouzivat distribuce se systemd :-)
A komu tím prospějete? Má snad ta jiná distribuce možnost vstoupit do boot procesu, který již začal s určitými boot parametry? Ty parametre totiž nejdou změnit (když nepočítám úpravu v jiném PC), jelikož zde není GRUB.
systemd.mask=adresar-kam-se-mel-pripojit.mount
Tohle je dost dobrá věc, a ukazuje to sílu systemd. Ale stejně by mi to nepomohlo , protože ,bych tak jako tak musel v jiném PC změnit obsah souboru cmdline.txt (akorát místo init=bash napsat toto).
Já jsem si říkal, jestli neexistuje nějaký parametr bootu, který by dokázal mount point nějak zakázat, když jsem viděl v tom výpisu failed to mount filesystemsněco.mount, jak jsem psal v první příspěvku.
-
Taky je resenim nepouzivat distribuce se systemd :-)
A komu tím prospějete?
Prospějeme tím tak, že ostatní init systémy kompletně nezablokují boot když se nepodaří namountovat nějakou položku z fstab. Buď pokračují dál, nebo nabídnou spuštění shellu.
Jinak tohle chování se dá v systemd emulovat parametry nofail,x-systemd.device-timeout=8 ve fstabu. Z nějakého důvodu není default, ale prý je fstab stejně zastaralý a máme používat mountovací unity…
-
Prospějeme tím tak, že ostatní init systémy kompletně nezablokují boot když se nepodaří namountovat nějakou položku z fstab. Buď pokračují dál, nebo nabídnou spuštění shellu.
To je asi otázka názoru, co je správné chování, hlavně názoru na bezpečnost. V mnoha situacích chcete mít od boot loaderu až do spuštění systému proces nenarušitelný i za cenu horších nouzových operací. Je na rozhodnutí uživatele, jestli má grub nebo primitivnější loader, je na rozhodnutí uživatele. Je na rozhodnutí uživatele, jestli systemd nastaví, aby ignoroval chyby a pokračoval. Je i na uživateli, jestli root má heslo (a tedy lze jej využít pro emergency), nebo jestli je zablokovaný. Z mého pohledu "bezpečnost ve výchozím stavu" je správný postup.
Jinak tohle chování se dá v systemd emulovat parametry nofail,x-systemd.device-timeout=8 ve fstabu. Z nějakého důvodu není default, ale prý je fstab stejně zastaralý a máme používat mountovací unity…
Mountovací unity dávají smysl, ostatní pak vědí, jestli na nich mohou stavět závislosti.
Základní OS klidně může být ve fstabu, ale když to selže, měl by se bootovací proces zastavit. To se tazateli stalo. Dále má bootloader, kde nic nezmění při provádění; nic mu nebrání (asi) vyměnit. A na konec, jestli správně chápu, má zablokovaného roota - což musel udělat taky vědomě.
-
twl, Mirecku, prestan radeji psat o vecech ktere znas jen vzdalene, teoreticky, nebo ti nedochazi vyznam toho co si sam psal....
V mnoha situacích chcete mít od boot loaderu až do spuštění systému proces nenarušitelný i za cenu horších nouzových operací.
nejde o "lepsi bezpecnost":
1. staci recene init=/bin/sh a system nastartuje s root uctem i kdyz ten je lock/nema_heslo
2. kdyz systemd zobrazi "error nelze pripojit xy" a NEdovoli to ignorovat
3. kdyz koukam Xminut na timeout, misto abych mohl zmackout klavesu pro zruseni cekani
jestli správně chápu, má zablokovaného roota - což musel udělat taky vědomě.
nikoliv, v Raspbianu o kterem je rec, NEni root ucet by default aktivni (to same v Debianu pokud nezadas pri install pro root heslo, to same v *ubuntu)
-
Jeste je otazka jak se systemd chova kdyz je ta partisna oznacena jako "noauto", to by uz selhavat boot nemel.
Jen by si to pak uzivatel musel skriptem v /etc/local.d/ pridelavat sam.
-
kdyz je ta partisna oznacena jako "noauto", to by uz selhavat boot nemel.
jj, aspon na centos7 to tak je.
čistě hypoteticky by pak mount /mnt/mountpoint šel napsat až k service která ho používá, a to do ExecStartPre=.
Pokud to failne, tak se ExecStart nevykoná a např. nedojde k nějakým masivním zápisům někam, kam by nemělo..
-
1. staci recene init=/bin/sh a system nastartuje s root uctem i kdyz ten je lock/nema_heslo
Ale tady má pravdu, protože bootloader může být zaheslovaný a pak tam toto jaksi nedopíšeš. A já jsem si naběhl že jsem si nepřečetl že to rescue shell chtělo spustit, ale neměl roota, takže v tomto případě se systemd zachoval podle mých představ a chyba je napůl v distribuci (že nemá roota i když ho její init vyžaduje při rescue) a napůl v uživateli (že si heslo roota nenastavil).
-
1. staci recene init=/bin/sh a system nastartuje s root uctem i kdyz ten je lock/nema_heslo
Ale tady má pravdu, protože bootloader může být zaheslovaný a pak tam toto jaksi nedopíšeš. A já jsem si naběhl že jsem si nepřečetl že to rescue shell chtělo spustit, ale neměl roota, takže v tomto případě se systemd zachoval podle mých představ a chyba je napůl v distribuci (že nemá roota i když ho její init vyžaduje při rescue) a napůl v uživateli (že si heslo roota nenastavil).
nema(+š) protoze:
- zaheslovany bootloader rozhodne neni vychozi situace
- ve vychozi situaci bez zaheslovaneho bootloader, plati co sem psal, systemd s lock root nedovoli sice nic, ale pridani init=/bin/sh pusti root shell
- chyba uzivatele neni ze se nedozvi z instalatoru ze pokud nenastavi heslo roota pri instalaci protoze ho nechce ale chce svuj user ucet do sudo, tak ze se nedostane v pripade potreby do emergency, stejne tak neni chyba uzivatele ze systemd kterej zjisti ze neni aktivni root ucet, se nezepta na heslo uzivatele pro ktereho by root emergency shell pustil pri spravne zadanem heslu uzivatele pokud on je v skupine sudo
- neni ani bezpecne opatreni ze systemd emergency se nepusti kdyz je lock root, ale pusti se BEZ zadani root hesla kdyz je root unlocklej...
-
nema(+š) protoze:
- zaheslovany bootloader rozhodne neni vychozi situace
Tak on je hlavně předpoklad, že opravovat takové věci bude někdo, kdo má heslo i k bootloaderu a pak je to stejné, jako by tam heslo nebylo, akorát je to omezené jen na ty, kdo heslo znají.
Tohle heslo brání v manipulaci s bootloaderem pouze neautorizovaným osobám, v tom je ta bezpečnost. Myslet si, že zvyšuji bezpečnost tím, že je žádoucí, aby do emergency režimu nešlo normálně vstoupit ("i za cenu horších nouzových operací"), jak psal Šilhavý je kravina.
-
Myslet si, že zvyšuji bezpečnost tím, že je žádoucí, aby do emergency režimu nešlo normálně vstoupit ("i za cenu horších nouzových operací")
Např. v síťových startech, na kioscích, ... je to žádoucí chování. Nemáte zařízení fyzicky pod kontrolou, často má už v určitém bodě přístup k síťovým prostředkům a stejně opravu provádíte na dálku. Tam má naprosto smysl jakýkoliv fail stav vyústit v uříznutí přístupů.
-
Např. v síťových startech, na kioscích, ... je to žádoucí chování. Nemáte zařízení fyzicky pod kontrolou, často má už v určitém bodě přístup k síťovým prostředkům a stejně opravu provádíte na dálku. Tam má naprosto smysl jakýkoliv fail stav vyústit v uříznutí přístupů.
zas ty tvoje mimonsko-nesmyslne argumentace :-) to je zlomek zarizeni, ktere navic VZDY admin upravuje tak aby bylo vse omezene, jak pri ootu, tak v nabehlem, takze by navic (k tem hromade) jen udelal zmenu aby blokoval emergency, proc tim ale argumentujes ze je to v poradku pro beznej desktop co vlastni/pouziva/ma_pod_rukama majitel/admin/root?
navic, myslis ze pro kiosek kterej spravujes na dalku je idealni stav aby pri fail datoveho disku byl stopnut boot a neslo se vzdalene pripojit? (narazim na nemoznost aby emergency sla (snadno) nastavit aby nahodilo ssh)
-
pardon, že ruším akademickou debatu o filozofickém významu bezpečnosti by default a nesmrtelnosti fstab,ale mám raspberrypi a tam si grub asi nedám nebo nějaký jiný bootloader umožňující volnost.
-
pardon, že ruším akademickou debatu o filozofickém významu bezpečnosti by default a nesmrtelnosti fstab,ale mám raspberrypi a tam si grub asi nedám nebo nějaký jiný bootloader umožňující volnost.
https://raspberrytips.com/raspberry-pi-dual-boot/
https://elinux.org/RPi_U-Boot
https://www.berryterminal.com/doku.php/berryboot
https://berryboot.alexgoldcheidt.com/images
https://www.cnx-software.com/2020/02/18/raspberry-pi-4-uefiacpi-firmware-aims-to-make-the-board-sbbr-compliant/
-
Např. v síťových startech, na kioscích, ... je to žádoucí chování. (...)
(...) to je zlomek zarizeni, ktere navic VZDY admin upravuje tak aby bylo vse omezene, jak pri ootu, tak v nabehlem, takze by navic (k tem hromade) jen udelal zmenu aby blokoval emergency, proc tim ale argumentujes ze je to v poradku pro beznej desktop co vlastni/pouziva/ma_pod_rukama majitel/admin/root?
Já si myslím, že by měl nastávat absolutní zlomek situací, kdy potřebujete takto nouzově opravovat. Naopak by si admini měli nad sebe sami dobrovolně plést bič a zabezpečení hrotit maximálně a nejlépe i implicitně. Oslabit bezpečnost, aby se pohodlně pracovalo, to dovede každý.
proc tim ale argumentujes ze je to v poradku pro beznej desktop co vlastni/pouziva/ma_pod_rukama majitel/admin/root?
Protože distribuce nemůže vědět, jak bude použita. Proto má být zabezpečna raději víc, a ať si to oslabí každý, kdo k takovému závěru dojde.
navic, myslis ze pro kiosek kterej spravujes na dalku je idealni stav aby pri fail datoveho disku byl stopnut boot a neslo se vzdalene pripojit?
Kiosky se většinou mění kus za kus, když jsou daleko, tak přepravní službou. Základem je mít to nastavené tak, aby se to stávalo opravdu výjimečně.
To, co tady razíte, je klasický postup povyšování chyb na standard. V 80 % situacích to vyhovuje, tak to rovnou povýšíme na univerzální pravdu..?
-
To, co tady razíte, je klasický postup povyšování chyb na standard. V 80 % situacích to vyhovuje, tak to rovnou povýšíme na univerzální pravdu..?
se pletes, ty razis "povysovani absence moznosti na status bezpecnosti", uvedom si ze si zacal obhajovat bezpecnost toho ze nelze s lock rootem prejit do systemd emergency, kdy ale zaroven lze ve stejne situaci pouzit init=/bash/sh, to vse ve vychozim stavu a navic to co si sam radil na zacatku (https://forum.root.cz/index.php?topic=22735.msg327249#msg327249), navic opet opakuju systemd kdyb by s lock rootem pri snaze o emergency zobrazil dotaz na heslo sudo uzivatele, tak by se tim zadna bezpecnost nesnizila ale zvysila by se pouzitelnost, to same plati pro ten timeout, proc koukat 5minut ze ceka na sit a nemit zobrazne moznosti "S-Skip Waiting, E-RunEmergency" a u nedostupneho disku "C-ContinueBootingWithoutMountThis, E-RunEmergency"