) I use Beagle Bone Green for my project. I am building my custom image with buildroot. I want a solution to be able to load the kernel image and rootfs with my apps from u-boot via tftp, but on the other hand I want to be able to use eMMC for some permanent files... What options do I have? Thanks)
initrd/initramfs for your rootfs and mount the emmc into that, e.g. /var or /mnt
nfsroot your rootfs is on a network drive, you can still mount the eMMC into any directory you want for device specific storage
partition eMMC download your rootfs image and write it to one partition on boot (usually from within initramfs). Keep your permanent data in a second eMMC partition. This approach can be useful if either of the previous don't work out e.g. due to not enough RAM or network limitations.
There are probably some other variations that I didn't mention, but those should be the most common.
Related
I know that they are two different things, but what is the difference between the actual Linux kernel and the rootFS file system especially in terms of location in memory and updates?
Regarding partitioning, why is it that the kernel and rootFS are nearly always on different partitions? Won't the kernel code be stored within the rootFS itself? So how are they on different partitions in memory?
Now regarding updating, I've been looking into an OTA update framework which claims to do a full kernel image update. It uses two separate partitions for rootFS. If there is a problem updating one rootFS partition, it can fall back to the working rootFS partition which makes sense. However, how is this actually updating the kernel tho? I don't understand.
I know that they are two different things, but what is the difference between the actual Linux kernel and the rootFS file system especially in terms of location in memory and updates?
Kernel is usually one image file (like zImage). In ARM systems kernel also needs device tree file, but let's avoid it for now. RootFS, in turn, is a file system that contains all files in your /, like binaries (init, bash), config files (/etc), user home directory, and so on. Sometimes RootFs contains kernel image file, sometimes it doesn't, depends on your particular system.
Regarding partitioning, why is it that the kernel and rootFS are nearly always on different partitions? Won't the kernel code be stored within the rootFS itself? So how are they on different partitions in memory?
The key to your questions is to think about bootloader (like U-Boot or GRUB). Once you understand how OS boot process works in bootloader, the answer will automatically reveal itself. As you mentioned, different partitioning schemes exist, which leads to difference in boot process. Actually, there is a lot of different boot schemes out there. Let's review some of them, and hopefully it'll explain what you want to know.
Kernel and rootfs on different partitions. In this case, bootloader usually reads kernel image to RAM, passing rootfs partition via kernel cmdline (via root= parameter). Then bootloader starts kernel execution, and kernel is mounting rootfs from partition specified in root= parameter.
Kernel image is located inside rootfs. In this case, bootloader ought to know where exactly kernel image is located (e.g. in /boot/zImage). Bootloader knows rootfs FS format (e.g. ext4), reads /boot/zImage from rootfs to RAM. Then execution continues as in previous item.
Kernel image and rootfs are passed via network (e.g. TFTP). In such case, sometimes, rootfs is being placed into RAM and mounted as ramdisk (from RAM). No persistent storage is used in such case, and any changes to rootfs will be lost after reboot. Another network case is when rootfs is mounted via NFS, then persistent storage on the server will be used (transparently viewed by the user).
Now regarding updating, I've been looking into an OTA update framework which claims to do a full kernel image update. It uses two separate partitions for rootFS. If there is a problem updating one rootFS partition, it can fall back to the working rootFS partition which makes sense. However, how is this actually updating the kernel tho? I don't understand.
In terms of updates, it's not that different which scheme to use,
(1) or (2). What are you talking about is called (at least in Android) A/B Seamless Updates, meaning that two partitions (A and B) are used for storing the same image (e.g. old rootfs and new rootfs). You need to understand that it's ok to update just rootfs without kernel. There is a rule in kernel development that reads like this: "We don't break userspace". Which means you can rely on different versions of kernel to run the same userspace, or you can rely on one kernel version to run different userspaces.
So it's more like architecture question: do you want to update kernel in your system at all? If yes, then you need to provide two different partitions for kernel and two partitions for rootfs. Or alternatively you can put kernel image and rootfs in the same partition (for example see Android boot image format), and provide second partition for updates.
I have Virtual box and a customized vagrant box. The thing is that my own laptop (Macbook) has only about 10 Gb of free space. So I bought a 128Gb USB Stick. Now I need to figure out a way to boot up vagrant boxes on this usb stick instead of the default hard drive of my laptop.
Almost all google articles explain how to boot up from the usb. But this is not what I exactly want. Have you ever been through such a situation?
any help would be appreciated!
you can do 3 things :
move your vagrant home directory with all the box on the USB stick (if you have many boxes, it will save some space)
you need to set $VAGRANT_HOME environment variable
move your VirtualBox VM to the USB stick; Open VirtualBox preferences panel and select the new default location folder for VMs. You would need to remove/re-add the VMs in VirtualBox after you moved all files to the external hard drive
You can use Linked Clones
By default new machines are created by importing the base box. For large boxes this produces a large overhead in terms of time (the import operation) and space (the new machine contains a copy of the base box's image). Using linked clones can drastically reduce this overhead.
Linked clones are based on a master VM, which is generated by importing the base box only once the first time it is required. For the linked clones only differencing disk images are created where the parent disk image belongs to the master VM.
It will not help for existing vagrant VM but for your new project, it will help to save space
I have my raspberry pi zero, and during development I spend a lot of time to eject-inject SD card and re-flash it. SD card image is prepared in Buildroot, so it includes boot partition with kernel, device tree overlays and partition with rootfs.
Is there simpler way to re-flash SD card? For example via network? I know that U-boot can load kernel via tftp, but if I need not only kernel, but whole image(device tree overlays are extremely important)?
Use TFTP to load the kernel image, and NFS to mount the root filesystem over the network.
Cutting to the Chase
Does the Linux composite USB gadget mass storage function support hot swapping of its LUN media backing files? If so, has anyone gotten it to work?
Background
The Linux USB composite gadget includes a Mass Storage function which can support multiple logical units, each of which maps to a drive image file (like FAT or ISO). From what I can tell, the Mass Storage function appears to inherit some or all of it's configuration interface from the previous standalone g_mass_storage gadget
The documentation implies that you can mount a storage image as a mass storage LUN, and then, at a later time, unmount it and remount a new storage image, in a manner similar to how a physical CD/DVD drive would work. It is this functionality that I am trying to access.
What I Have Tried
I am using insmod/modprobe and rmmod to mount and unmount a single LUN mapped to an ISO image. The modprobe parameters are modified version of the stock Edison config, which it uses to expose its "firmware update" drive image.
The USB slave is an Intel Edison board running a slightly modified Yocto build, the host is OS X 10.10.2:
# Step 1: mount an ISO
modprobe g_multi file=/home/root/first_image.iso removable=1 ro=1 stall=0 idVendor=0x8087 idProduct=0x0A9E iProduct=Edison iManufacturer=Intel
# at this point, the ISO appears on the host (I'm testing with OS X)
# Step 2, at some later time
rmmod g_multi
# The storage disappears from the OS X desktop.
# It does not seem to complain unless you had files open on the media
# Step 3: mount a different ISO
modprobe g_multi file=/home/root/second_image.iso removable=1 ro=1 stall=0 idVendor=0x8087 idProduct=0x0A9E iProduct=Edison iManufacturer=Intel
# The operation appears to work on the device side,
# but the new media does not appear in OS X.
# You can usually get it to work by unplugging the USB cable,
# which presumably resets the port somehow.
I have tried to find a way to reset the OTG device port under software control. That may be the ultimate solution.
I have not (yet) tried using the configfs interface to build and configure the device. That may also be an option, but I'm still working through the docs on that.
Thanks!
At least on:
$ uname -r
4.9.87
I've found this:
$ find /sys -type f -a -name file
/sys/devices/soc0/soc/2100000.aips-bus/2184000.usb/ci_hdrc.0/gadget/lun0/file
/sys/module/g_multi/parameters/file
The prefix will be heavily dependent on your hardware, but the gadget/lun0/file one is writable. You'd then:
echo "/where/is/your/file" >.../lun0/file
and voila. Of course, you need the removable=1 passed go g_file as the OP implied.
To "eject" the device, you simply do the following:
echo >.../lun0/file
This last one may fail if the filesystem is still mounted on the host.
I have a 32GB USB drive that I am trying to use as both a boot drive for a ChromeOS version available from here, and to use the remaining space on the drive as I normally would, just for storage to be accessed via Windows or hopefully the ChromeOS.
I've tried partitioning it in various ways using EaseUS, but every time I've written the ChromeOS image to a partition with the Win32DiskImager, I can't access the larger partition I want as storage.
I feel like I'm missing something major here, can anyone shed some light on this for me?
Thanks!
when you make a bootable usb using ChromeOs image
When does resizing occur?
Partition resizing is initiated by the system, not by the user.
refer here for more information