Many thanks PrintedWeezl for your help!
1 Like
Logs looks like a good one. Delete the older logs. Should free up some space
Cheers
I promised the dd commands although we can see that /var/log had a lot in from the screenshots.
If you have mounted the card using a USB sd card reader the first thing we need to find are the devices:
type 'df' and you'll get a report of the disk file system usage.
You are looking for something like /dev/sdb1 in the first column and /media/username/boot in the last column - that's the boot partition - and there'll be another /dev/sdb2 with /media/username/rootfs - that's the root partition. N.B. username is whatever you are logged in as, if you are using a Pi it will be /media/pi/boot.
If you've mounted them in an mmc slot in a laptop as I have just done, the devices are /dev/mmcblk0p1 for the boot and /dev/mmcblk0p2 for the rootfs. Its outside this post to explain the difference as its deep into Linux devices and naming, but if you eject the card, the devices disappear.
So lets work with /dev/sdb1 and /dev/sdb2 as examples.
To unmount the partitions without ejecting the card type 'sudo umount /dev/sdb1' then 'sudo umount /dev/sdb2' . This means the device 'file' is still there and its this that you use in the dd command.
Assuming the machine you are using has plenty of disk space you can just create images of each sd card partition doing this:
sudo dd if=/dev/sdb1 of=~/boot.img
and
sudo dd if=/dev/sdb2 of=~/rootfs.img
'if' means input file and 'of' means output file
The boot image copy won't take very long
The rootfs copy will take much longer because the partition is 8GB - or 16GB, or however big the partition is.
Those .img files are now on your home directory, that's what ~/ means along with the filename.
If you create a new bigger sd card with octopi on, you can then copy those image files back.
Put the new card in, unmount the partitions and then use
'sudo dd if=~/boot.img of=/dev/sdb1'
'sudo dd if=~/rootfs.img of=/dev/sdb2'
BE VERY CAREFUL that you know which devices your old memory card mounts on - you don't want to overwrite the system you are running. Once you've copied your image files back over to the new card, eject and put into your Pi and boot - n.b. this won't work if your original images don't have the correct boot files for the Pi you are using, so beware if you are using a card that was created before the Pi4 was released.
BTW, the image files on your hard disk are essentially backups, very useful, I've just had a Pi trash its microSD card and I've had to rebuild Octoprint on a new one.
1 Like
Many Thanks rcw88,
This information will be most helpful
Thanks
I thought I'd throw this out there (as someone who owns way too many microSD cards)...
I have macOS and use Apple-PiBaker. It makes it easy then to clone a card. Boot the new one and expand the filesystem using sudo raspi-config and you're all set.
1 Like
I use Macs too, but not with the 3D printing, am using discarded (i.e far too old to run Windoze on) laptops with Ubuntu LTS 20.04 or Pixel X86, I'm a STEM Ambassador, so have a fleet of scrapped laptops to hand that I use with STEM events.
I also am using a Mac and I will have a look at the Apple-PiBaker program. Many thanks
1 Like
About using dd in any linux-environment, there is a simpler way to make a backup and then later put that on a new micro-sd card to use. I use this all the time, also to make duplicates of an install to run for example octoprint on multiple pi's (of course you need to change the name of the system so you don't get double names on the network).
First go to a shell and use "blkid" to see which filesystems are listed. you will probably have the sd-card listed like /dev/sdb1 or /dev/sdc1 (and /dev/sdc0).
Well, that sdc1 or sdc2 are the partiotions, and you want a copy of the whole drive (card): sdc or sdb for example.
if it is on sdc for this card, you can use to make an image:
dd if=/dev/sdc of=myimage.img bs=2048K status=progress
explained:
if: input file (so in this case the whole sd-card)
of: output file (so the name you choose)
bs: blocksize. 2048K is going much faster then without specification and if you have more memory you can make it larger to get faster copies
status=progress : makes sure you can read how far the copy is.
After it it finished, you use umount or unmount it in the filemanager and put the new card in
if it is listed on the same drive (as usual), to put the image to the card:
dd of=/dev/sdc if=myimage.img bs=2048K status=progress
So, just reverse the order.
And then yes, boot up, expand the filesystem and change the name if wanted in raspi-config, reboot and ready.
By the way, on some cheap cards, the size is listed wrong so that it seems to be for example 64GB but in reality it is only a 4 GB card so it fills really quickly after a while.
That is a known selling-trick....
1 Like
Thanks for the extra tips, and yes, using the image copies of the whole drive at the device level is faster than at the partition level, and if the sd card isn't already partitioned, makes things a whole lot easier.
re bootable SD cards. I really don't understand whats going on here, I used Win32DiskImager with OctoPi .img file "2019-09-26-octopi-buster-lite-0.17.0.img" to create my bootable copy of OctoPrint.
But if I image that SD card and clone to another card the OctoPrint doesn't boot and I can't SSH to it.
I also tried Paragon HDM which is normally dead solid.
Is there the equivalent of windows MBR or something on the SD card?
Something like that.
There is a fat32 partition with the bootloader and configuration files. (It's the one with the octoprint wpa config file on it)
Does the Pi even see the Fat32 partition?
Anyway, I seem to have resolved my problem which seems to be down to dodgy SD cards. I don't usually run the Pi with the HDMI connected so I didn't see the message "end kernal panic".
Boots off the FAT partition, then the EXT4 partition is mounted as part of boot. That's why ssh is on the /boot along with config.txt, they are used to configure the O/S as it comes up - along with feeding the WiFi settings with the WPA.
If there's an MBR on the partition, that would definitely bork the Pi booting. It just wants a plain FAT partition. MBR's are for hard disks, I'm not even sure there's a possibility of having one on an SD card without checking.
If anyone is going the 'dd' route, there's also a project called ddrescue which gives you more feedback of what it's doing.
sudo apt-add-repository universe && sudo apt install gddrescue
I use it whenever I'm needing to clone a card. Mostly because it tells me how long it's going to take 
Ubuntu? I'm sure things are much easier for you, then. Linux obviously has native support for the EXT4 format standard whereas Apple/Microsoft have purposely prevented its inclusion.
Cloning a microSD in Ubuntu (or any Linux-like o/s) might be as simple as mounting both and then some sort of copy/paste like behavior. Otherwise, I might recommend the excellent/free GPartEd program.
https://duckduckgo.com/?q=how+to+clone+with+gparted&t=osx&ia=web
It's probably worth noting that the Desktop version of the Raspberry Pi OS has a program under Accessories called SD Card Copier.
My god, thanks you, honestly it's disturbing how simple that was lol
I just cloned my 4gb card to my 8gb card and it worked but my 8gb card thinks it has only 4gb of space on octoprint? Any idea how to fix this. Thanks
SSH to the pi and run sudo raspi-config and there's an option in there somewhere to expand the filesystem.
1 Like
This also works for migrating to a SSD, in my case the Argon One SSD addon.
1 Like
You also need to open raspi-config and enter the ADVANCED tab. Hit the "Expand File System" command to take advantage of all the new free space.
1 Like