What can be deleted to free up space in onboard storage?

[Christopher Burian]

Hi all,

I'd like to install x264 and ffmpeg, but ran out of space while downloading ffmpeg source.  I'm ordering some micro SD cards to work with but once I'm done developing, I'd like to be booting off onboard storage.

On a new BB Green df shows just 153M free of 3.6G volume.  That's a lot of stuff.  So I'm wondering if if there's a guide to what can be deleted to make more room for user created content in the onboard volume.

Thanks,
Chris

[Graham]

Are you using an external video display, or, are you running headless?

The standard distribution is the largest, and has everything in it.

If you don't use the local video output, you could use the IoT version, which is about half the size.

Or, for smallest size, start with the console version, which is about one fourth the size, and add in only those packages you need.

--- Graham

==

[William Hermans]

Yes, there are literally hundreds, if not thousands of guides out there how to "trim the fat" off Linux. Pick one, and get to it.

[Christopher Burian]

Thanks, Graham, that's what I was looking for.  Start with the minimalist system and put in (or build) the packages I need.  Building takes forever though, I need to set up cross compiling on another machine.

William, I didn't get very far with apt-get remove before I was still left with lots of cruft and not knowing what I can get rid of without breaking things.

Best regards,
Chris

[Graham]

You did not say if you are using the video output and HDMI. 

I just saw that they are including a 2GB lqxt version in the weekly distribution package again.

This is for the early 2GB eMMC version of the BBB.

If you do need the lqxt version, you could install this, expand the file system to 4 GB, and still have room, as long as what you need for your base was not removed in the 2 GB reduction.

--- Graham

==

[William Hermans]

On Fri, May 12, 2017 at 5:33 AM, Christopher Burian <cjbu...@gmail.com> wrote:

William, I didn't get very far with apt-get remove before I was still left with lots of cruft and not knowing what I can get rid of without breaking things.

Best regards,
Chris

So, you need to be more specific as to what you need then. See, myself, I do not start with an image that has everything under the sun built into it. I start with a minimal image, and manually install what I need. So this: https://wiki.ubuntu.com/ReducingDiskFootprint is a pretty good guide as to what to do. Then yes, it is Ubuntu, but at least 80% of the stuff talked about can be done verbatim for Debian. Especially considering Ubuntu is based on Debian.Then when and if you run into trouble with a command, because of Debian <-> Ubuntu differences, a good google session should clear that up easily.

Something to be aware of. Some kernel modules may seem unnecessary for your purposes, but may be needed by something you're unaware of. So, before completely removing(deleting) kernel modules, at least move them some place safe, so you could easily put them back if you run into trouble. Also think hard about removing some of the other files they talk about. Again, google will work wonders in "telling you" if you need those files or not.

Not to mention there is a post by me on these forums many months ago asking Robert how he creates his Ultra bare minimal images. Search the groups here for keywords "William Robert Reduce rootfs", and it'll probably come up.

[William Hermans]

This is the specific post I mentioned: https://groups.google.com/forum/#!searchin/beagleboard/William$20Robert$20Reduce$20rootfs|sort:relevance/beagleboard/0IDdkljrWOE/9V3X0gSvMHkJ

[William Hermans]

By the way, similar to what Graham mentioned. Get a larger sdcard. Personally I use 16G sdcards( think we have some 32's as well ), and resize the main partition to file the whole card. There are actually a few ways to do this, for me the quickest was is to use fdisk. Basically it involves deleting the main partition, then recreating the same partition, but with no limitation on the end. Which will use the entirety of the sdcard. Something to note about this procedure. If you do not know what you're doing, it can be "dangerous". No, the card wont destroy your neighborhood or anything of that nature, but you can render the disk unreadable. e.g. lose your existing data.

[Dennis Lee Bieber]

On Fri, 12 May 2017 17:49:39 -0700, William Hermans
<yyr...@gmail.com> declaimed the following:

>By the way, similar to what Graham mentioned. Get a larger sdcard.
>Personally I use 16G sdcards( think we have some 32's as well ), and resize
>the main partition to file the whole card. There are actually a few ways to
>do this, for me the quickest was is to use fdisk. Basically it involves
>deleting the main partition, then recreating the same partition, but with
>no limitation on the end. Which will use the entirety of the sdcard.
>Something to note about this procedure. If you do not know what you're
>doing, it can be "dangerous". No, the card wont destroy your neighborhood
>or anything of that nature, but you can render the disk unreadable. e.g.
>lose your existing data.
>

On that point, I've found the most noticeable trap is that fdisk
defaults to creating the partition at 2048, but recent BBB images start at
(I recall) 8192.

If one doesn't reset the starting point, one either ends up wiping part
of the boot configuration data, OR is unable to find the base of the file
system.
--
Wulfraed Dennis Lee Bieber AF6VN
wlf...@ix.netcom.com HTTP://wlfraed.home.netcom.com/

[William Hermans]

On Sat, May 13, 2017 at 5:20 AM, Dennis Lee Bieber <wlf...@ix.netcom.com> wrote:

On Fri, 12 May 2017 17:49:39 -0700, William Hermans
<yyr...@gmail.com> declaimed the following:

>By the way, similar to what Graham mentioned. Get a larger sdcard.
>Personally I use 16G sdcards( think we have some 32's as well ), and resize
>the main partition to file the whole card. There are actually a few ways to
>do this, for me the quickest was is to use fdisk. Basically it involves
>deleting the main partition, then recreating the same partition, but with
>no limitation on the end. Which will use the entirety of the sdcard.
>Something to note about this procedure. If you do not know what you're
>doing, it can be "dangerous". No, the card wont destroy your neighborhood
>or anything of that nature, but you can render the disk unreadable. e.g.
>lose your existing data.
>

        On that point, I've found the most noticeable trap is that fdisk
defaults to creating the partition at 2048, but recent BBB images start at
(I recall) 8192.

So you use file, and write all that information odwn.

        If one doesn't reset the starting point, one either ends up wiping part
of the boot configuration data, OR is unable to find the base of the file
system.
--
        Wulfraed                 Dennis Lee Bieber         AF6VN
    wlf...@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/raudhc9abimhdtmuj14l0ji3m0rn43eg4e%404ax.com.

For more options, visit https://groups.google.com/d/optout.

[William Hermans]

Write that information down . . .

[Robert Nelson]

The starting address is stored in the /boot/SOC.sh file...

Regards, 

[William Hermans]

So I usually use this method:

On Beaglebone:
root@wgd:~# cat /etc/dogtag
BeagleBoard.org Debian Image 2017-04-02

On Debian support system:
william@eee-pc:~$ unxz bone-debian-8.7-console-armhf-2017-04-02-1gb.img.xz
william@eee-pc:~$ file bone-debian-8.7-console-armhf-2017-04-02-1gb.img
bone-debian-8.7-console-armhf-2017-04-02-1gb.img: x86 boot sector; partition 1: ID=0x83  , active, starthead 130, startsector 8192, 1732608 sectors, code offset 0x0

I forget if fdisk will also give this information or not, but it should if you run fdisk -l /dev/<device name>. However, running this on a live partition may not work ? Let's find out.

root@wgd:~# lsblk
NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
mmcblk1boot0 179:8    0    2M  1 disk
mmcblk1boot1 179:16   0    2M  1 disk
mmcblk1      179:0    0  3.7G  0 disk
`-mmcblk1p1  179:1    0  3.7G  0 part /

root@wgd:~# fdisk -l /dev/mmcblk1

Disk /dev/mmcblk1: 3.7 GiB, 3909091328 bytes, 7634944 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device         Boot Start     End Sectors  Size Id Type
/dev/mmcblk1p1 *     8192 7634943 7626752  3.7G 83 Linux


And SOC.sh says . . .
root@wgd:~# cat /boot/SOC.sh
#!/bin/sh
format=1.0

board=am335x_evm

bootloader_location=dd_spl_uboot_boot
bootrom_gpt=

dd_spl_uboot_count=1
dd_spl_uboot_seek=1
dd_spl_uboot_conf=notrunc
dd_spl_uboot_bs=128k
dd_spl_uboot_backup=/opt/backup/uboot/MLO

dd_uboot_count=2
dd_uboot_seek=1
dd_uboot_conf=notrunc
dd_uboot_bs=384k
dd_uboot_backup=/opt/backup/uboot/u-boot.img

boot_fstype=ext4
conf_boot_startmb=4 ???
conf_boot_endmb=
sfdisk_fstype=L

boot_label=BOOT
rootfs_label=rootfs

#Kernel
dtb=
serial_tty=ttyO0
usbnet_mem=

I'm assuming this is file is marked executable so it can be "sourced" ?

[William Hermans]

By the way, the above from the "live" image was from eMMC. If that matters.

[William Hermans]

Oh, and right, running fdisk -l on the partition wont work either. You have to issue the command on the block device in whole. As I showed above.

[Robert Nelson]

Correct that's the file, I source it in the grow_partition.sh and update_bootloader.sh across.

Regards,

[Christopher Burian]

This is a lot of great info, thanks.  Appreciate how this topic got fleshed out into a how-to.

Best regards,
Chris