SD kaart net iets te klein voor image

[geertbruijnes]

Mijn vraag
Ik heb gebruik een microSD kaart van 16 GB in een Raspberry Pi. (Raspbian + max2play). Nu is kaart gesneuveld, maar gelukkig heb ik een backup.img. Als ik deze echter wil schrijven naar een andere microSD van 16 GB kom ik ruimte te kort.

Relevante software en hardware die ik gebruik
Ik maak gebruik van Ubuntu, schrijf met dd of met Etcher.

Wat ik al gevonden of geprobeerd heb
Etcher: Insufficient space, another 9.44 MB required.
dd eindigt met een foutmelding met dezelfde strekking.

Als ik de image naar een 32 GB kaartje schrijf, krijg ik een werkende kaart..
Vervolgens heb ik de grootste partitie verkleind (met gparted) zodat er minder dan 15 GB van de kaart gebruikt is. Hiervan heb ik weer een nieuwe image gemaakt. Deze is echter 32 GB groot.

Wat kan ik doen om alles weer op een 16 GB kaart te krijgen, als ik nu 32 GB ga gebruiken is de volgende stap wellicht 64 GB

[Possible]

Rasbian zelf kan je volgens mij prima op een 4 of 8 GB SD kaart plaatsen. Als je dan een image maakt met de benodigde tools dan is het toch klaar? Dan heb je altijd een 4 of 8 gb clean image file.

[SMSfreakie]

Dit heb ik ook al meermaals gehad.. komt denk ik omdat je image een 1:1 sector kopie is, en dan heb je in elk geval net zo veel sectors ( of meer ) nodig op je target media..

ik zou ook graag enkele van mijn backup images (usb / sdcards) welke nu 8,16 of 32GB innemen terwijl er duidelijk minder data in de image zit kleiner zien..

het liefst gewoon image's maken die net zo groot zijn als de data die er in zit.
de "overgebleven" ruimte na het terug schrijven kan ik zelf wel weer uitbreiden...

[Batavia]

Backup mounten en alleen data copieren? klinkt alsof je ook lege sectoren meegebackupt heb?

[SMSfreakie]

peltco schreef op vrijdag 25 januari 2019 @ 21:52:
Backup mounten en alleen data copieren? klinkt alsof je ook lege sectoren meegebackupt heb?

Dat is mij met bootable images nooit gelukt om ze dan nog te laten werken..

[pentode]

Dit script al geprobeerd?
https://github.com/Drewsif/PiShrink

[Room42]

@geertbruijnes Hier, wat Google-fu: zoeken bij google naar 'raspberry pi image shrink windows' --> YouTube: How to Shrink Retropie SD Images Zelf nooit getest

edit:
@pentode linkt naar exact dat script!

Wat je kan doen om te grote images te voorkomen is de partitie niet 100% van de SD-card te maken maar bijvoorbeeld 500MB kleiner. Dan hou je wat marge.

Een andere manier is enkel de userdata (dus alles wat niet bij het OS hoort) backuppen en dat terugzetten op een nieuwe installatie. Je zou eens kunnen kijken naar https://rsnapshot.org/ voor het automatiseren van die backups.

[ Voor 3% gewijzigd door Room42 op 25-01-2019 22:02 ]

[Wim-Bart]

Je zou ook een andere SD kaart kunnen proberen. Zelf meegemaakt met 8GB SD kaartjes van de zelfde fabrikant (ik geloof Kingston maar weet het niet meer zeker). Exact zelfde partnummer en omschrijving. Alleen zat het verschil in land van productie waarbij kaartjes uit Taiwan net ietsje groter waren dan de kaartjes gefabriceerd in Maleisië.

[GlowMouse]

geertbruijnes schreef op vrijdag 25 januari 2019 @ 21:44:
Als ik de image naar een 32 GB kaartje schrijf, krijg ik een werkende kaart..
Vervolgens heb ik de grootste partitie verkleind (met gparted) zodat er minder dan 15 GB van de kaart gebruikt is. Hiervan heb ik weer een nieuwe image gemaakt. Deze is echter 32 GB groot.

Als je daarmee de 16 GB kaart beschrijft tot hij vol zit (bv. met dd), zou dat moeten werken.

SMSfreakie schreef op vrijdag 25 januari 2019 @ 21:54:
[...]


Dat is mij met bootable images nooit gelukt om ze dan nog te laten werken..

Door bovenstaande tip is dit niet meer nodig, maar om een disk weer bootable te maken kun je van een tweede kaartje (of usb-stick) booten en grub in de mbr van het eerste kaartje zetten. Daarnaast moet je even kijken of er uuid's zijn gewijzigd voor /etc/fstab.

[ Voor 4% gewijzigd door GlowMouse op 25-01-2019 23:07 ]

[TomsDiner]

Ik leg SD kaarten altijd even een kwartiertje in de oven op 70 graden, en pers daarna -als hij nog goed heet is- het image erop. Ze kunnen daar een klein beetje bol van gaan staan...

Maar het kan ook wel simpeler: er bestaan image shrink tools. Let op, image (in de zin van afbeelding) kent ook shrink mogelijkheden, maar disk images kunnen ook geshrinked worden.

[Mijzelf]

SMSfreakie schreef op vrijdag 25 januari 2019 @ 21:54:
[...]
Dat is mij met bootable images nooit gelukt om ze dan nog te laten werken..

Er is niets magisch aan een 'bootable image' voor een RPi. Het tricky part is dat de partitie UUID's moeten kloppen op 2 plekken, vfat:/cmdline.txt en ext:/etc/fstab.

Je kunt de partitie UUID zien met blikid:

blkid /dev/mmcblk1*

(Afhankelijk van je kaartlezer en/of distro moet dit misschien /dev/sd* zijn.)

Dit geeft je (onder andere) de PARTUUID's van de twee partities. Bijvoorbeeld

/dev/mmcblk1: PTUUID="be37afe3" PTTYPE="dos"
/dev/mmcblk1p1: SEC_TYPE="msdos" UUID="21FC-1235" TYPE="vfat" PARTUUID="be37afe3-01"
/dev/mmcblk1p2: UUID="bdba7355-4721-4f7b-8292-4fb96361bfa8" TYPE="ext4" PARTUUID="be37afe3-02"

Nu moet in de FAT partitie in de file cmdline.txt de 'root=PARTUUID=' aangepast naar de PARTUUID van de ext partitie. Op de ext partitie moet in /etc/fstab ook de beide PARTUUID's aangepast.

[Thralas]

GlowMouse schreef op vrijdag 25 januari 2019 @ 22:51:
Door bovenstaande tip is dit niet meer nodig, maar om een disk weer bootable te maken kun je van een tweede kaartje (of usb-stick) booten en grub in de mbr van het eerste kaartje zetten.

Alleen op ARM heb je niet zoveel aan grub

Mijzelf schreef op zaterdag 26 januari 2019 @ 09:59:
Er is niets magisch aan een 'bootable image' voor een RPi. Het tricky part is dat de partitie UUID's moeten kloppen op 2 plekken, vfat:/cmdline.txt en ext:/etc/fstab.

Je kunt dit flexibeler maken door op de door jouw aangegeven locaties (kernel command line en fstab) de partities te mounten op basis van fsuuid (UUID=) of filesystem label (LABEL=) icm. een label op het filesystem.

Let wel dat die laatste weer nadelen heeft als je labels niet uniek zijn en je media wisselt tussen systemen (zoals een SD-kaartje in een Raspberry Pi).

[geertbruijnes]

pentode schreef op vrijdag 25 januari 2019 @ 22:01:
Dit script al geprobeerd?
https://github.com/Drewsif/PiShrink

Prima methode.
Een meer 'controleerbare' manier wordt beschreven op https://softwarebakery.com//shrinking-images-on-linux
(image mounten, met gparted partitie verkleinen en daarna met truncate de image verkleinen.

Probleem is echter dat er aan het einde nog ergens een kleine partitie /dev/loop0p3 staat:

(hier heb ik de tweede partitie /dev/loop0p2 al verkleind)
Deze is niet te verplaatsen en als ik 'm verwijder werkt de installatie niet meer. (Het is de SD-kaart voor een m2p audio speler op een Raspberry Pi)

[ Voor 4% gewijzigd door geertbruijnes op 29-01-2019 22:01 ]

[Thralas]

geertbruijnes schreef op dinsdag 29 januari 2019 @ 21:57:
Deze is niet te verplaatsen en als ik 'm verwijder werkt de installatie niet meer. (Het is de SD-kaart voor een m2p audio speler op een Raspberry Pi)

Wat zegt fdisk -l /dev/loop0? En file -s /dev/loop0p3?