Raspberry Pi 3 nebootuje z většího SSD

[marosh1976]

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?

[Reklama]

[k3dAR]

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

[Hamparle]

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 takhle s UASP diskem, proč mi nešel.

A nebo možná napětí ... neustálý napětí problém  raspberí

[marosh1976]

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.

[marosh1976]

Tak opravdu byl nakonec problém v napájení.

[Reklama]

[bmn]

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

[Pavouk106]

"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

[RDa]

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

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)

Kód: [Vybrat]

/* 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