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
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
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.
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
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
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.
This is the specific post I mentioned: https://groups.google.com/forum/#!searchin/beagleboard/William$20Robert$20Reduce$20rootfs|sort:relevance/beagleboard/0IDdkljrWOE/9V3X0gSvMHkJ
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 Fri, 12 May 2017 17:49:39 -0700, William Hermans
<yyrkoon@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.
On Fri, 12 May 2017 17:49:39 -0700, William Hermans
<yyrkoon@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.
Write that information down . . .
The starting address is stored in the /boot/SOC.sh file…
Regards,
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/. 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” ?
By the way, the above from the “live” image was from eMMC. If that matters.
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.
Correct that’s the file, I source it in the grow_partition.sh and update_bootloader.sh across.
Regards,
This is a lot of great info, thanks. Appreciate how this topic got fleshed out into a how-to.
Best regards,
Chris