The title says it all: I want to get rid of this (really annoying) mmcblk0p1 partition on the latest Ubuntu image and boot directly into /sda1. The current mmcblk0p1 partition is only 14GB large on my 64GB SDcard, which means I just loose ~40GB of storage! I can’t even apply system updates!
I’ve already installed some applications onto mmcblk0p1: is there any way to copy everything to sda1 before deleting the partition?
Back to the office this morning, I tried to remove the SD card and boot the machine: you guessed right as the board booted on its internal mmcblk0 card.
Now the obvious question: how can I 1) copy all my software from the internal eMMC to the SD card and 2) deactivate the eMMC to boot on the SD card (or change the boot options)?
Not an answer, but some related information: Since this has eMMC, it is not a dev kit. It is a separately purchased module with a third party carrier board. Most likely it requires the third party board support package for any kind of flash (which is usually the same as dev kit, but with modified device tree).
SD card models (dev kits) have the SD card slot on the module itself; third party setups with an eMMC module have the SD card on the carrier board, and not on the module. Drivers and device tree differ quite a bit for these, and normally SD card boot is not supported on a third party carrier board without additional work (e.g., it might use an initrd flash).
SD card content on a dev kit is just the rootfs. There are a lot of other partitions, and they will either be found in QSPI memory (on the module; part of a dev kit), or in those other eMMC partitions. Boot content intended to be on an eMMC partition will need to remain there even if you are booting to an SD card rootfs. See this regarding some of the “extra” partitions of an eMMC model: https://forums.developer.nvidia.com/t/topic/232508/15
Don’t even try to put those extra partitions on an SD card for an eMMC model.
Thanks a lot for this clear explanation! I understand I’ve tried to copy/paste things on different boards and that is never a recipe for success! 🤦♂️
I’ll then dig deeper into the manufacturer’s documentation to see how I can 1) keep the system on the eMMC and 2) use the SD card (which is indeed on the carrier board 😉) as the /home partition where my software will run.
Your carrier board manufacturer will have the information for that. You’ll likely end up with all of the non-rootfs partitions on eMMC, and the rootfs on the SD card. This would open up a lot of space on eMMC (the rootfs is by far the majority of space used on eMMC). However, it is possible that you still need the “/boot” on eMMC if it chain loads to SD. An actual flash with correct parameters would be needed to avoid chain loading from eMMC to SD (the boot partitions are not part of the chain loading other than perhaps pointing at the first extlinux.conf file to use; if the pointer is set during flash to look for the SD card, then it will look there first, and only the non-rootfs of eMMC is needed).
Surprising: I thought keeping rootfs partitions on the eMMC would be better, as the system is rather stable, whereas the application, which will collect thousands of images, would better fit on the SD card… 🤔
By the way, thanks for the hint, I’ll check this against the manufacturer’s documentation! 🙏
FYI, if you have a separate SD card (not with rootfs), and if you just want to mount this at some particular location other than “/”, then this is fairly trivial. As an example, most of the space consuming NVIDIA optional software goes to “/usr/local” (as do many third party packages). One could create a large SD card partition, format it as ext4, and mount in on “/usr/local” (probably after cloning the original “/usr/local” content). Then add a proper “/etc/fstab” mount specification. This is trivial. However, if you want to do this, please ask since an incorrect fstab entry could cause boot to halt when the SD card is not present (the usual fstab entry can be modified to make it tolerate a missing SD card).