Fórum Root.cz
Hlavní témata => Hardware => Téma založeno: marosh1976 28. 01. 2021, 11:13:30
-
Ahoj lidi,
potřebuji poradit. Mám raspberry pi 3 a provozuji ho jako domácí server pro všechno možné. Po té co mi odešla sd karta jsem podle zdejšího článku místo ní začal používat SSD disk v rámečku.
Všechno krásně funguje. Teď chci po několika letech vyměnit SSD disk za větší, ale nejsem z nového disku schopný dokončit boot.
Z původního disku jsem pomocí dd udělal image a ten jsem pak zapsal na nový disk.
Přepsal jsem na nové UUID pro mountování boot a root v konfiguračních souborech.
Boot zamrzne po 4 sekundách hláškou No Caching mode page found, Assuming drive cache: write through.
Zvláštní je, že pokud nový disk vyndám z rámečku a připojím ho přes adaptér SATA-USB který také mám, tak to nabootuje. Vrátím do rámečku a zamrzne to.
Původní SSD disk funguje v rámečku naprosto bez problému.
Nějaké nápady?
-
problemovej ramecek ;-) z lsusb zjisit vendorid:productid a treba se o tom nekde neco najde, pripadne kup lepsi ramecek :)
BTW: kdyz udelas image celeho disku pomoci DD, tak UUID oddilů v nem obsazenych maji stale totozne UUID jako zdrojovy disk, DD dela surovou/RAW kopii, 1:1...
-
A když ho připojiš do již spuštěného raspberrí? dmesg --follow nebo journalctl -f --- možná třeba má UASP režim, který jak prý v raspberry nejde a linux za to prý nemůže, (v výpisu se objeví něco jako UASP scatter gather not supported)
Já jsem se trápil (https://forum.root.cz/index.php?topic=23540.msg336705#msg336705)takhle s UASP diskem, proč mi nešel.
A nebo možná napětí ... neustálý napětí problém raspberí
-
Děkuji za odpovědi. Napětím by to opravdu mohlo být, mám k tomu RPI připojený přes usb můj arduinobastl (bez ext. napájení) který mu posílá hodnoty z čidel a modul pro bezdrátovou klávesnici. A ten SATA-USB adaptér má narozdíl od rámečku vlastní zdroj.
Ještě taky zkusím nabootovat z microSD karty a rámeček připojit později a zkouknout co na to dmesg.
Je možné že by ty SSD měly tak rozdílnou spotřebu? Možná pokud jsem s původním SSD na "hranici" tak stačí malý rozdíl...
To s tím UUID je záhada, souhlasím že by mělo zůstat stejné. Ale "lsblk -f" mi v Ubuntu na PC kde jsem to klonoval u disku opravdu ukázalo jiné UUID než to co na něm bylo v etc/fstab a boot/config.txt
Zjevně někde dělám chybu... Zkusím to přečíst i u původního SSD disku a porovnat.
-
Tak opravdu byl nakonec problém v napájení.
-
Aj ked to bolo vyriesene tak pridam svoju skusenost s A-Data USB-SSD. Ak je nastartovane z SD karty a pripojeny len ako externy disk tak vsetko funguje fajn a rychlo. Ale akonahle ho mam pripojeny ako bootovaci tak sa zasekne. Pomohlo az pridanie
"usb-storage.quirks=125f:a88a:u" do cmdline.txt
-
"usb-storage.quirks=125f:a88a:u" do cmdline.txt
Jen dodám, že tohle v mém případě pomohlo vyřešit problémy s UAS (USB Attached SCSI). Mám M.2 SSD v USB3 boxu a zatímco na dekstopu mi to s UAS šlape suprově, tak RPi nefungovalo - nepamatuju si, jestli nebootovalo vůbec nebo bylo extrémně pomalé nebo nestabilní... prostě nepoužitelný stav. Přidání zmíněného pomohlo problém zcela eliminovat.
Teoreticky pak ale přijdete o nějaké low-level věci. Ve výsledku to je tuším (zjednodušeně) rychlost SSD a možná i větší opotřebení. Ale když to jinak nejde...
Teda asi by šlo - vyhodit z kernelu UAS. Ale kdo se pustí do kompilace vlastního kernelu...? Teda kromě mě, když na RPi4 provozuju Gentoo ;D
-
Teda asi by šlo - vyhodit z kernelu UAS. Ale kdo se pustí do kompilace vlastního kernelu...? Teda kromě mě, když na RPi4 provozuju Gentoo ;D
Jiste ze by to slo i jinak ,)
Otazka natazeni UAS je podminene volani ... takze by stacilo kernel rozbalit / prepsat kousek na nop-y / zabalit zpet :-)
(treba - kdyz je clovek linej dohledat z ceho a jak je onen kernel kompilovan)
/* If uas is enabled and this device can do uas then ignore it. */
#if IS_ENABLED(CONFIG_USB_UAS)
if (uas_use_uas_driver(intf, id, NULL))
return -ENXIO;
#endif