No, postupoval jsem podle toho. Mám teď sda2 ale stejně mi to nějak nejede
Mám tam teď
:Device Boot Start End Sectors Size Id Type
/dev/sda2 2048 234441647 234439600 111.8G 83 Linux.
Bylo by možné rozdělit disk tak abych používl část jako paměť emc a část pro síťový disk ? Nějak se opět ztrácím…
Končím zatím tady:
/mnt/ssd/@ # tar -xzvf /mnt/flash/omnia-medkit-.tar.gz
tar: can’t open '/mnt/flash/omnia-medkit-.tar.gz’: No such file or directory
TAk jsem se dostal sem:
Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 78147215 78145168 37.3G 83 Linux
/dev/sda2 78147216 234441647 156294432 74.5G 5 Extended.
Dále postupuji podle návodu až do bodu :
mount /dev/sdb1 /mnt/flash
kde je podle mě chyba a má být sda1.
Pokud opravím skončím tady:
/mnt/ssd/@ # tar -xzvf /mnt/flash/omnia-medkit-.tar.gz
tar: can’t open '/mnt/flash/omnia-medkit-.tar.gz’: No such file or directory
Prijde mi, ze ten navod je psany pro pripad, ze vam jeste Omnie funguje a prikazy provadite v ni. Pokud je provadite na jinem pocitaci, bude to trochu jinak. Kazdopadne /dev/sdb1 bylo spravne - to je USB flashka, na ktere mate ten medkit. V pripade, ze to delate na nejakem jinem linux stroji, tak to neni potreba, a staci misto /mnt/flash/omnia... zadat cestu, kam jste stahl medkit. A mount /mnt/flash uplne vynechat.
Jinak rozdelit disk a pouzit /dev/sda1 na system a /dev/sda2 na data je uplne v poradku, postupujete spravne.
No tak už fakt nevím. Dělám to na PC s win10 přes putty dle návodu. Router zatím nějak žije , podle toho spustí to rescue . Mám k tomu připojit flešku a nějaké soubory? Mám to jen přes tu seriovou linku. Díky
Jasne, jedte podle navodu:
V obou případech potřebujete sériový kabel a flash disk s medkitem.
Flashka s medkitem je tedy potreba (to bude to /dev/sdb). Je mozne, ze rescueboot nebude umet NTFS, ale treba jenom FAT a btrfs flashky.
Takže díky peci1 ! Konečně se podařilo. Ten návod není psaný pro lamy jako já. Chtěl by trošku " vylepšit ".
Router už běží, jen se mi nepodařilo naformátovat a zprovnit ten zbylý oddíl disku pro používání. Piše to něco o malé velikosti. No, nevadí, třeba vyjde boot z USB, nebo dám do USM 3.0 flasku a budu používt=at jako úložistě ji.
Ještě jednou díky peci1 za ochotu a pomoc. Jirka
Super 
S naformatovanim druheho oddilu by to nemelo byt tezke, a 74 GB mu urcite musi stacit… V fdisku by melo stacit sda2 smazat (pokud tam nemate data), a pak vytvorit novy oddil - ten by pak mel automaticky vzniknout se spravnou velikosti.
Pokud mate konkretni veci, ktere by se daly v navodu upravit, aby byl pratelstejsi, tak by bylo super je sepsat a poslat na tech support email, at to do dokumentace pridaji.
A kdyz uz jste na Turris OS 5, muzete si overit “zdravi” interni emmc pameti:
eMMC on its own does not track write cycles like standard drives and does not have mechanism like smart. You can use
mmc extcsd read /dev/mmcblk0from packagemmc-utilsto take a peak in to amount of used reserved blocks. That is fieldEXT_CSD_DEVICE_LIFE_TIME_EST. Value is in range of percents so0x01is from 0%-10% blocks used,0x02is from 10%-20% and so on. When amount of reserved block used is close to 100% then NAND is pretty much EOL.
Melo by stacit:
opkg update && opkg install mmc-utils && mmc extcsd read /dev/mmcblk0 | grep EXT_CSD_
Z toho LIFE_TIME_EST se ma dat vykoukat, “na kolik % je znicena”, ale nevim, u mne to moc nefungovalo. _A a _B jsou jen ruzne typy bunek (jednobitove vs. vicebitove) - staci, kdyz je spatne jedno z toho a je spatna cela pamet. Vic u mne ale fungovalo EXT_CSD_PRE_EOL_INFO, ale ted z hlavy nevim, ktere hodnoty co znamenaji. Ale myslim, ze je to neco jako 0x01 - ok, 0x02 - zacina byt zle, 0x03 rozlucte se.
I’d like to know status of my eMMc
Succesfully instaled mmc utilities on TO 3.11.21. Unfortunately
mmc extcsd read /dev/mmcblk0 | grep EXT_CSD_DEVICE_LIFE_TIME_EST
and
*mc extcsd read /dev/mmcblk0 | grep EXT_CSD_PRE_EOL_INFO
didn;t produce any output, and
mmc extcsd read /dev/mmcblk0 | grep EXT_CSD_
gave
Device supports writing EXT_CSD_WR_REL_SET
which is at no help 
unfortunately…
Even
mmc extcsd read /dev/mmcblk0 | grep LIFE_TIME_EST
didn’t produce any output
So what?
Update to Turris OS 5. Unfortunately, there’s no way to get it with 3.x. However, you can use the “schnapps import medkit” method of 5.x installation, which is pretty harmless to your 3.x system, boot into the 5.x, do some quick “first run” config, read the values, and then rollback to 3.x. I did that a few times and no problem.
Thanks, this is surely possible way, but I’m not about to do this exercise, even though I was curious as to health of eMMC of my Turris router I’ll wait till I could safely switch to TOS v 5 and stay there… Hopefully it’ll be soon.
Na mé Omnii mám spolu s NASem povolený a spuštěný mediaserver miniDLNA. Může se tím nadměrně opotřebovávat eMMC?
Edit:
Po přečtení příspěvku od peci1, který je o několik příspěvků níže a ve kterém vysvětluje kam se co ukládá, jsem se juknul v LuCI do nastavení miniDLNA a všechno je tam nastavené na zápis do /var a tedy v RAM paměti. Mediaserver miniDLNA by tedy eMMC paměť neměl nadměrně opotřebovávat.
To si nemyslím, ale pro větší jistotu, aby nebylo moc zapisováno do eMMC můžete v LuCI v položce miniDLNA v pokročilém nastavení zadat, kam má ukládat databázi, log atd. Také se snažím vše co jde, nastavit na interní SSD a samozřejmě mám také pro delší výdrž eMMC zapojen flashdisk.
Aktuálně jsem po instalaci na 3.11.21. To se mi tam nainstalovalo z toho medkit. Mám ještě otázku, můžu povolit automatické aktualizace ? Popř. přejít na Turris OS 5? Nestane se že že při aktualizaci změní to spouštění U Boot ?
Díky
TOS 3.x ma o neco mensi pravdepodobnost aktualizace U-Boot, takze z tohohle hlediska budete na 3.x asi bezpecnejsi. Pokud chcete mit jistotu, ze se neco nepokazi bez vaseho vedomi, tak doporucuju nastavit updaty s potvrzenim (tj. updater vas upozorni na novou verzi, ale jeji instalace se provede az kdyz ji odklepnete ve Forisu). Pokud vas to neobtezuje, tak na foru sledujte diskuzni vlakna ke kazde nove verzi - tam se jednak dozvite, pokud by doslo k aktualizaci U-Boot, a take, jestli tam byly nejake dalsi problemy, ktere potkaly ostatni. Pokud se o to nechcete starat, muzete si nastavit opozdene updaty, tj. update se provede automaticky, ale s nejakym zpozdenim (myslim, ze je to v radu ± tyden). Pak mi ale prijde zasadni zprovoznit si zasilani notifikaci emailem, abyste vedel, ze se update chysta, a mohl ho vcas zatrhnout, kdyby se chystal update U-Boot.
@turris-admin Muzeme dostat nejake “zavazne” vyjadreni ohledne toho, jestli bude update U-Boot patricne a vyrazne zmineny v release notes a notifikaci, kterou router posila? Uplne idealni by mi prislo, kdyby router sam poznal, ze ma nedafaultni boot konfiguraci, a upozornil uzivatele, ze se mu po update rozbije boot.
Jinak pokud by vas zajimalo, co vlastne ta eMMC je, tak vsechno krom /tmp a /var . Pokud mate zapnuty Storage plugin, tak /srv je storage disk (defaultne je to ale eMMC).
/tmp a /var jsou tmpfs, tedy v zasade ulozene v RAM.
Pak jsou samozrejme dalsi specialni adresare, ktere nejsou ulozene na disku - /dev, /proc apod., ale ty vas asi nemusi zajimat.
Tj. pokud chcete predejit opotrebeni eMMC, tak vsechno ukladat do /tmp nebo /var (oboje znamena, ze data pri restartu zmizi), a nebo zapnout storage plugin a ukladat do /srv (to restart prezije).