OS via DD naar EMMC verplaatst - boot niet

[HTT-Thalan]

Elke keer als ik denk dat ik wat nieuws geleerd heb, loop ik tegen een nieuw struikelblok aan...

Na mijn vorige issue met geluid, besloot ik een gefixte versie van het OS naar de interne EMMC te verplaatsen. Ik heb via PartEd achterhaald welke device ID's ik heb (want de EMMC en de SD controller zitten blijkbaar op één device bij dit apparaat).

Eerst via Etcher het OS naar de SD kaart gezet en succesvol geboot / installatie afgemaakt (username/pw en locale) en daarna via DD naar de EMMC verplaatst:

code:

sudo dd if=/dev/mmcblk0 of=/dev/mmcblk2

omdat hij boot vanaf de SD ziet hij de SD als een 'later' device (hogere ID) blijkbaar.
Dat duurde eventjes (modifier bs=4M vergeten, zo bleek) maar hij begon daarna zonder de SD te booten.
So far so good, maar dat was van korte duur:



Ik kom in een 'emergency shell' terecht. Ik weet dat bij een DD de target device hetzelfde of groter moet zijn dan de source, beide zijn in mijn geval 16GB maar het scheelt een tiende in het voordeel van de SD kaart, helaas. Kan dat de oorzaak zijn? Kan ik het van hieruit nog redden?

Er bestaat ook een custom script om deze klus te klaren:

https://gitlab.manjaro.or...ons/manjaro-arm-installer

maar die vertrouwt op twee dependencies die niet in AUR te krijgen zijn (binfmt-qemu-static en debian-whois-mkpasswd). Dat heb ik de schrijver van het script laten weten in een mailtje maar die schreef simpelweg dat ik het niet goed doe en bleef daarna stil.

Iets nieuws leren is lastig als de hoeveelheid informatie zo groot en tegelijkertijd zo onvindbaar is, en een hoop mensen doen de aanname dat omdat je _iets_ weet, je hun cryptische instructies dan ook maar moet begrijpen .

[Candymirror]

Je hebt met dd ook de huisige fstab file meege 'dd't
Daarin staat een harde verwijzing naar uuid van de disk die hij moet mounten. Je kunt twee dingen doen of de UUID van de nieuwe disk wijzigen en gelijk maken aan de oude of handmatig de fstab file aanpassen met de nieuwe UUID.

[0xDEADBEEF]

Candymirror schreef op woensdag 12 juni 2019 @ 15:14:
Je hebt met dd ook de huisige fstab file meege 'dd't
Daarin staat een harde verwijzing naar uuid van de disk die hij moet mounten. Je kunt twee dingen doen of de UUID van de nieuwe disk wijzigen en gelijk maken aan de oude of handmatig de fstab file aanpassen met de nieuwe UUID.

UUIDs kan je, behalve met PartEd, tonen met blkid.

[Candymirror]

Ik zie net dat je een pinebook hebt, ik weet niet of die net als bij bv een RPI een vfat partite gebruikt om te booten /boot net een bootparameter file. (ik denk het niet, maar aangezien je de hele mmcblk devices hebt ge 'dd't kan ik ook niet uitsluiten dat het meerdere partities zijn)

Het kan dus zijn dat je in die vfat partitie in een config file de bootparameter voor de root partitie moet wijzigen en in /etc/fstab.

Ik stel voor dat je met je oude sdcard gaat booten, vervolgens de rootpartitie op mmcblk2 gaat mounten en dan handmatig /etc/fstab aanpast met het juiste uuid.

[HTT-Thalan]

Candymirror schreef op woensdag 12 juni 2019 @ 15:34:
Ik zie net dat je een pinebook hebt, ik weet niet of die net als bij bv een RPI een vfat partite gebruikt om te booten /boot net een bootparameter file. (ik denk het niet, maar aangezien je de hele mmcblk devices hebt ge 'dd't kan ik ook niet uitsluiten dat het meerdere partities zijn)

Het kan dus zijn dat je in die vfat partitie in een config file de bootparameter voor de root partitie moet wijzigen en in /etc/fstab.

Ik stel voor dat je met je oude sdcard gaat booten, vervolgens de rootpartitie op mmcblk2 gaat mounten en dan handmatig /etc/fstab aanpast met het juiste uuid.

Tot zover begrijp ik nog waar jullie het over hebben. Ik kan inderdaad nog de 'oude' installatie booten vanaf de SD kaart (staat nu te snorren) en dan moet ik van daaruit de FSTAB zien aan te passen.

Kunnen jullie me ook vertellen hoe? Ik weet dat iets met "mnt /dev/whatever" zal moeten doen en waarschijnlijk komt er ergens nano of (goed verhoede) Vi aan te pas?

Bij mijn weten draait dit spul gewoon op EXT4. de ARM CPU is inderdaad geen X86 spul maar verder is het allemaal redelijk industrie standaard, alleen de kernel is anders.

Er zijn helaas beperkte keuzes: Of ik bouw zelf een Distro op basis van een ARM kernel (en daar ben ik bij lange na niet linux savvy genoeg voor) of ik pak een prebuilt distro voor ARM op de Pinebook (en die spoeling is dun).

[ Voor 15% gewijzigd door HTT-Thalan op 12-06-2019 15:42 ]

[Candymirror]

je zult eerst moeten kijken welke partities je op mmcblk2 hebt.
cfdisk /dev/mmcblk2
gevolgd door een "p" geeft je de partitie tabel
daar zal in ieder geval een linux partitie bij zijn en mogelijk een vfat16/32.
vervolgens mount je de linux partitie.
mount /dev/mmcblk2p* /mnt (op de plaats van het sterretje het partitie nr)
vervolgens gebruik je je favorite beschikbare text editor vi of nano om /mnt/etc/fstab te opnenen
zoek de regel waarin het foute UUID staat, zelfde regel waar ook /new-root als mountpoint vermeld staat. en wijzig de UUID die je hebt gevonden met het blkid.

Mocht er nu ook nog eeb vfat partitie zijn, dan bevat die mogelijk ook nog een config file ( waarsch. boot.cfg) waarin als boot parameter rootfs=uuid=.... meegegeven wordt of iets dergelijks. ook daar moet je dan het uuid aanpassen.

Als je ook een appart mountpoint voor /boot hebt moet je daar het uuid ook van aanpassen in de fstab file.

[ Voor 6% gewijzigd door Candymirror op 12-06-2019 15:56 ]

[HTT-Thalan]

Zoals verwacht heb ik twee devices, ik twijfel alleen nog steeds naar welke hij nu refereert omdat ze beide 16GB zijn en alleen verschillen op het laatste nummer. Maar, cfdisk geeft slechts bij eentje (waarschijnlijk de SD kaart waarvan hij nu is opgestart) de volledige partitie-info weer, inclusief UUID.

de blk2 drive:



de blk0 drive:



de hotkey 'p' werkt overigens niet en word ook niet als optie genoemd in de help.

Ik wil nu natuurlijk de UUID vinden van die blk2 schijf, die hij nu net niet weergeeft.

[0xDEADBEEF]

HTT-Thalan schreef op woensdag 12 juni 2019 @ 16:05:
Ik wil nu natuurlijk de UUID vinden van die blk2 schijf, die hij nu net niet weergeeft.

Wat vertelt 'cat /proc/cmdline'?

[HTT-Thalan]

0xDEADBEEF schreef op woensdag 12 juni 2019 @ 16:10:
[...]

Wat vertelt 'cat /proc/cmdline'?

code:

console=tty50,115200 console=tty0 root=PARTUUID=06daea98-01 rw rootwait

Dat lijkt inderdaad verdacht veel op een UUID maar het format wijkt behoorlijk af van de UUID die ik in cfdisk zag.

- edit -

of moet ik naar de identifier bovenin het scherm bij cfdisk kijken? Want die word wél voor beide disks genoemd, ik krijg echter maar voor één disk een 'file system identifier' te zien onderin.

[ Voor 22% gewijzigd door HTT-Thalan op 12-06-2019 16:15 ]

[Candymirror]

de hotkey 'p' werkt overigens niet en word ook niet als optie genoemd in de help.

dat komt omdat ik cfdisk verwar met fdisk of omdat er maar 1 partitie is?

Zoals 0xDEADBEEF al aangaf blkid.

blkid /dev/mmcblk0 en
blkid /dev/mmcblk2

[ Voor 6% gewijzigd door Candymirror op 12-06-2019 16:25 ]

[HTT-Thalan]

Met blkid kom ik tot dezelfde conclusie: De SD kaart waarvan ik momenteel boot heeft een PARTUUID, maar de interne EMMC drive niet. Ik kan die dus niet direct addresseren via zijn UUID?

Als ik uitga van de info bovenin cfdisk kom ik ook niet verder, want die geeft voor beide drives de exact zelfde PARTUUID aan .

Als ik gewoon via de GUI die drive probeer te addresseren (bekijken via Dolphin b.v.) krijg ik: error occurred. Error mounting, wrong fs type, bad option, bad superblock, missing codepage or helper, or other error.

- edit -

Via het fdisk 'advanced menu' kan ik de disk identifier wél inzien en wijzigen. Ik heb om te beginnen de identifier (die hier wel word weergegeven, maar dus indentiek is aan die van de SD kaart) 'gewijzigd' naar hetzelfde, redenerende dat ik dan geen fstab hoef te wijzigen?

Uiteraard hielp dit niet, ding boot nog steeds niet, ik zit weer in een emergency shell... maar de interne EMMC heeft nu volgens blkid (vanaf de e-shell) wél een filesystem UUID...

[ Voor 55% gewijzigd door HTT-Thalan op 12-06-2019 19:54 ]

[0xDEADBEEF]

Helpt dit je verder: https://wiki.odroid.com/o...ng_boot_partition_sd_emmc? Gevonden via 'emmc partuuid'.

[HTT-Thalan]

0xDEADBEEF schreef op woensdag 12 juni 2019 @ 20:50:
Helpt dit je verder: https://wiki.odroid.com/o...ng_boot_partition_sd_emmc? Gevonden via 'emmc partuuid'.

Ziet er moeilijk uit, maar volgens mij staat hier, even platgeslagen, dat ik gewoon een andere uuid moet verzinnen voor de emmc en die in de fstab moet zetten omdat ze nu identiek zijn, maar dat is ook weer niet logisch want het booten mislukt met de SD kaart uit het systeem dus op dat moment is er niks dubbel.

Ze schrijven wel dat (maar dat zal wel zo zijn voor het geval van de odroid) dat de emmc altijd blk0 zou zijn?

- edit -

Ik probeer (gewoon doodnormaal via de package manager) gparted te installeren om wat meer inzicht te krijgen maar dan krijg ik een 404 not found bij het downloaden. Ik begin te denken dat dat hele Arch Linux / Manjaro gewoon een onstabiele bende is.

[ Voor 16% gewijzigd door HTT-Thalan op 12-06-2019 21:06 ]

[Hero of Time]

Debian heeft ook gewoon ARM builds. Idee om dat te installeren ipv met Manjaro door te gaan? Moet je wel weer je audio opnieuw aan de praat zien te krijgen, mocht je er tegenaan lopen, maar dat komt dan wel.

[HTT-Thalan]

Ja, daar zit ik nu naar te kijken inderdaad. Er zijn meerdere keuzes:

https://wiki.pine64.org/index.php/Pinebook_Software_Release

maar ze hebben allemaal wel issues. Ik geloof dat de Debian hoek inderdaad issues met audio heeft, en alhoewel ik geen GPU acceleration e.d. nodig heb is een beetje audio toch wel handig. Het ding hoeft niet veel te doen: Alleen af en toe een mailtje versturen en een simpele website bezoeken, maar als er een keer wat 'gehoord' moet worden...

Ik denk dat DietPI nog de minste kwaaie keuze is, moet ik inderdaad audio fixen en die afschuwelijke GUI vertimmeren. Ik snap niet waarom een simpele gui ook altijd hoeft te betekenen dat ze niet even de moeite nemen het lettertype fatsoenlijk te sizen en de boel even een beetje op te fleuren .

Misschien toch iets teveel afgebeten / iets te rooskleurig over de ondersteuning nagedacht, maar ik geef het nog niet op .

- edit -

PB image is currently being redone due to a previous update issue. We aim to have this image available again ASAP.

Daar liep ik inderdaad tegenaan. Update brak het systeem. Ik heb echt mijn tijd niet met dit ding .

[ Voor 19% gewijzigd door HTT-Thalan op 12-06-2019 21:43 ]

[BoAC]

Je disks kun je toch ook zien in de lijst uit:

code:

ls -l /dev/disk/by-uuid

Dan zie je in 1x alle uuid's voor de disks
Welke bootmanager wordt gebruikt?

[ Voor 11% gewijzigd door BoAC op 13-06-2019 06:55 ]

[HTT-Thalan]

BoAC schreef op donderdag 13 juni 2019 @ 06:48:
Je disks kun je toch ook zien in de lijst uit:

code:

ls -l /dev/disk/by-uuid

Dan zie je in 1x alle uuid's voor de disks
Welke bootmanager wordt gebruikt?

Geen idee, hoe kom ik daar achter? De UUID's zijn me ondertussen "duidelijk" - die zijn identiek voor beide schijven. Ik heb een Xenial Mate desktop klaarstaan om erop te flashen, kijken hoe dat verloopt. Is in ieder geval bekender terrein voor me, dat Arch is toch vrij hardcore.

[Candymirror]

Het is vreemd te noemen dat het rootfs nog niet gemount kan worden als de (part)uuid's van zowel de SD als het eMMC nu gelijk zijn. Geef ons eens de inhoud van je /etc/fstab /boot/boot.cmd en de output van blkid en mount.