I have four LePotatos (all 2GB). Three of them are Ubuntu or Debian headless servers, and one is running Raspbian desktop. The servers are all running flawlessly, but the Raspbian is a bit more sluggish than I had hoped it would be. I was thinking about installing an eMMC on it to improve performance. I spent quite a bit of time setting this up and would rather not have to start from scratch. Is there a way that I can transfer the setup from the SD card to the eMMC so that I don’t have to start over?
SD cards and eMMC are both block devices and act the same way. You just dd from the SD card to the eMMC with a large block size like 1M.
Okay thanks. That makes sense. I’m assuming that the default boot order has the eMMC first, correct?
Yes, the bootloader sequence is printed out on debug UART as the first line.
Howdy. Could I ask for a bit more detail ln how you got this running?
Similar your Potato running Raspbian, I’ve a Potato running Debain Bookworm from a 128GB SD card and have tuned that as I like.
Purchased an official Libre 128GB eMCC card (comes with that USB-A to USB-A cable). With the Potatoe powered off, inserted the eMCC. Powered on the Potato and confirmed the eMCC is seen by the system.
Then did:
sudo dd if=/dev/mmcblk1 of=/dev/mmcblk0 bs=1M status=progress
Came back after a bit and noticed the Potato was powered off (only the red LED was on, no green or blue).
Turned off power to the Potato and removed the SD card.
Connected power to the Potato, monitoring the power up sequence on the serial monitor. The Potato booted, making it to GRUB as normal but then halted with this issue:
Begin: Will now check root file system ... fsck from util-linux 2.38.1
[/sbin/fsck.btrfs (1) -- /dev/mmcblk0p2] fsck.btrfs -a /dev/mmcblk0p2
[ 6.055327] usb 1-1.3: new low-speed USB device number 4 using xhci-hcd
done.
[ 6.062196] BTRFS info (device mmcblk0p2): first mount of filesystem 916ed486-0d67-414c-987d-5709ce79d98c
[ 6.068309] BTRFS info (device mmcblk0p2): using crc32c (crc32c-generic) checksum algorithm
[ 6.076561] BTRFS info (device mmcblk0p2): using free space tree
[ 6.084362] BTRFS error (device mmcblk0p2): device total_bytes should be at most 124801515520 but found 127596998656
[ 6.092958] BTRFS error (device mmcblk0p2): failed to read chunk tree: -22
[ 6.100322] BTRFS error (device mmcblk0p2): open_ctree failed
mount: mounting /dev/mmcblk0p2 on /root failed: Invalid argument
Failed to mount /dev/mmcblk0p2 as root file system.
Checking the eMMC card, out of the box it has about a 200MB EFI partition and then then a second partition with free space space of about 125.8 GB.
So it seems as though – based on this line:
[ 6.084362] BTRFS error (device mmcblk0p2): device total_bytes should be at most 124801515520 but found 127596998656
that the initial “dd” failed as the source and destination SD cards had a size/partition mismatch??
Any ideas on how to resolve??
FWIW, the Potato is now un-bootable as it prioritizes booting the eMCC over the SD card.
Many thanks.
I wish I could help you Xylopyrographer, but I ran into a similar issue when I tried to dd from the SD card to the eMMC. In my case, the eMMC was only a 32GB and the SD card was 64GB. I got frustrated and decided to start over and just use the image from the distro server. It didn’t take as long as I thought to get it back to the way that the SD card was setup because I was able to copy individual files over from the SD card. It probably would have taken longer had I tried to figure out why the dd transfer failed.
Isn’t that the way 
.
I’m almost at the same point.
Thanks for the reply. Have a great one!
dd does not power off the device. It probably only finished a partial copy and the system went into suspend if the image you are using is a desktop image.
The eMMC was mounted to a host machine using the “interrupt U_Boot and typing ums 0 mmc 0” method and connected using the USB-A to USB-A cable.
So if I understand that, the Le Potato isn running, just making the eMMC card available to the host.
The issue was trying to write the image, created from the 128GB SD card originally used to get the board up and running to the eMMC, which only has 125GB available. That caused dd to fail & hang things up.
After trying unsuccessfully to shrink the image size below 125GB, I gave up and started fresh after agin mounting the eMMC as above. Worked like a charm.
Takeaway: If you plan on installing an eMMC after using an SD card to fire things up, make sure the SD card is smaller than the available space on the eMMC card you’ll be installing.
Question: What is on the Libre 128GB eMMC card that eats up 3GB? and can that be cleared out so an entire image sourced from an SD card of the same capacity could have been made to work?
I used an SD card booted up on a Renegade to download the image of the Renegade to the SD card. I then uncompressed the image on the renegade, on the SD card, and dd’d the image to the installed eMMC.
When I did the 2nd Renegade the SD card with an image already on it made the whole job a bit more streamlined.
The eMMC would actually have 2 ‘drives’. 1 drive the smaller one is a boot drive and the larger one is the rest of the story. Is my understanding. I think that’s how it works.
128GB is 128000000000 bytes. 128GB does not equal 128GiB.
Sorry for slight off topic, I have a Commodore 64 working over USB-TTL adapter on lepotato. It works great for serial communication at 2400bps. What are the voltages on UART ? Commodore operates on 5V TTL. Is this compatible ?