With FAT32 images, copying files to an unmounted image is possible with the mcopy command:
mcopy -v -i [image file] -s [files to copy] ::/
However, this is not possible with an ext4-based image file. Is there an equivalent command to achieve the same result for an ext4-based image file? Mounting is not an option due to the image build tool (Yocto) being used not having sudo access.
Related
I'm trying to deploy some binary files to /boot in a Yocto image for RPi CM3 but it deploys them to the wrong location.
do_install() {
install -d ${D}/boot/overlays
install -m 0664 ${WORKDIR}/*.dtb ${D}/boot/overlays/
install -m 0664 ${WORKDIR}/*.dtbo ${D}/boot/overlays/
}
The files are deployed to /boot in the / partition of the final image, but not to the /boot partition. So they are not available at boot time.
I already googled and studied the kernel recipes (and classes) of the Poky distribution but I didn't find the mechanism it uses how to ensure that the files are deployed to the boot image (and not to the /boot dir in the root image).
Any help is appreciated :)
Update #1
In my local.conf I did:
IMAGE_BOOT_FILES_append = " \
overlays/3dlab-nano-player.dtbo \
overlays/adau1977-adc.dtbo \
...
"
And in my rpi3-overlays.bb
do_deploy() {
install -d ${DEPLOYDIR}/${PN}
install -m 0664 ${WORKDIR}/*.dtb ${DEPLOYDIR}/${PN}
install -m 0664 ${WORKDIR}/*.dtbo ${DEPLOYDIR}/${PN}
touch ${DEPLOYDIR}/${PN}/${PN}-${PV}.stamp
}
Using this the image builds, but the files stillt don't get deployed in the /boot partition.
Using RPI_KERNEL_DEVICETREE_OVERLAYS I get a build error because the kernel recipe tries to build the dtbo files like dts files.
RPI images are created with sdimage-raspberrypi.wks WIC wks file. It contains:
part /boot --source bootimg-partition ...
so it uses bootimg-partition.py wic plugin to generate /boot partition. It copies every files defined by IMAGE_BOOT_FILES variable.
It seems you want to add some devicetree overlays, so you need to modify machine configuration and more specifically RPI_KERNEL_DEVICETREE_OVERLAYS variable. IMAGE_BOOT_FILES variable is set in rpi-base.inc.
If you don't have any custom machine or custom distro defined, you can add it in local.conf:
RPI_KERNEL_DEVICETREE_OVERLAYS_append = " <deploy-path>/<dto-path>"
You can see here how to add files in deploy directory.
After too many hours of investigation it turned out, that deploying files to other partitions than / is not easily possible. I now went the way of a post-processing script that mounts the final image, deploys the additional files and unmounts it.
# Ensure the first loopback device is free to use
sudo -n losetup -d /dev/loop0 || true
# Create a loopback device for the given image
sudo -n losetup -Pf ../deploy/images/bapi/ba.rootfs.rpi-sdimg
# Mount the loopback device
mkdir -p tmp
sudo -n mount /dev/loop0p1 tmp
# Deploy files
sudo -n cp -n ../../meta-ba-rpi-cm3/recipes-core/rpi3-overlays/files/* tmp/overlays/
sudo -n cp ../../conf/config.txt tmp/config.txt
sudo -n cp ../../conf/cmdline.txt tmp/cmdline.txt
# Unmount the image and free the loopback device
sudo -n umount tmp
sudo -n losetup -d /dev/loop0
I have two questions:
What command can I use, to move a file into another docker volume?
What command can I use, to extract a file into another volume?
I have Docker running on a VPS with 160GB Disk space.
I downloaded a snapshot .tar file on that VPS and the next step would be to unpack it. However, because the unpacked file is 88GB, I added an additional volume with 100GB to my droplet.
My plan is, to move that .tar file to the 100GB volume.
And then unpack it back into the main 160 volume.
This would be the code to unpack the file:
cd /tmp
an then:
sudo tar xvC /var/lib/docker/volumes/NAME_OF_YOUR_VOLUME/_data/data/tomo/ -f 20190617.tar
But I am a newbie and I don't understand that command and don't know how it works, when you have two volumes.
This is how I solved it.
find the new volume: fdisk -l
create a new directory and then mount the volume on it: sudo mount /dev/something /new/dir
extract the .tar on that mounted directory: sudo tar xvC /new/dir -f 20190617.tar
move it to the docker volume(after making room by deleting the .tar): cp -R /var/lib/docker/volumes/...
I'm creating an ISO of a Debian system with:
mkisofs -V "Debian ISO" -cache-inodes -J -l -o file.iso debian-system/
The problem is: when I mount the ISO (mount -o loop) ping and sudo don't work because their suid bits have not been set.
I know that special bis are cleared by the -r flag. This flag generates the "rationalized Rock Ridge directory information" which enables to retain the original file permissions, but also clears any set-id bits.
But if I don't use -r, file permissions will be the same for all files, as specified at runtime when the ISO is mounted.
Question: how to add set-id files like ping and sudo to a linux "live" ISO?
You need to use an alternate file system, that supports those permissions.
The way a LiveCD/DVD works is there is a squashfs file that is mounted with changes made in RAM.
You could "fake" the same by creating a file full of zeros using dd, make a file system on it wtih mkfs.ext4, mount it, and copy the files onto it. Then on your custom disk, mount it as loop (mount -o loop /path/to/file /mnt/point) and symlink/etc the binaries over.
I've installed Petalinux 2014.4 on my Zynq board, but the NAND flash is not mounted when I boot up the board. I'm wondering if it's possible to change rootfs.cpio by extracting the package and then do changes to fstab and so make a cpio arhcive back. If yes, is it enough to just run petalinux-build after that?
Thanks :)
If you have access to the ramdisk image file, then yes, you can modify its contents. I assume that your image file is compressed using gzip. Furthermore I assume that you use U-Boot and your compressed ramdisk image has a U-Boot preamble.
First you need to strip the U-Boot header:
dd bs=64 skip=1 if=uramdisk.cpio.gz of=ramdisk.cpio.gz
Next, we decompress:
gunzip ramdisk.cpio.gz
Finally we extract the CPIO archive:
mkdir ramdisk && cd ramdisk
cpio -i -F ../ramdisk.cpio
Either you execute the latter command as root or you change the file ownership back to root before archiving again. This is necessary for your init program to start. After your modifications you can create your image file again:
find . | cpio -o -H newc | gzip -9 > ../ramdisk_new.cpio.gz
mkimage -A arm -T ramdisk -C gzip -d ramdisk_new.cpio.gz uramdisk.image.gz
Notice that the mkimage tool is part of U-Boot and is located in the respective sources in the tools directory.
I am not familiar with PetaLinux so I don't know whether this general answer suits your needs and expectations.
Using cpio package tools is OK. But it needs to be done every time you updates rootfs.
You can also use PetaLinux built-in tool to accomplish this. It doesn't need extra steps once you set it up.
Create the app:
petalinux-create -t apps -n fstab_mount_sd --template install --enable
In the created components/apps/fstab_mount_sd directory, modify the Makefile to append contents to current fstab file or replace the original fstab with your version of fstab file.
Here's an example of the fstab_mount_sd Makefile:
install:
$(TARGETINST) -a "/dev/mmcblk0p1 /media/card auto defaults,sync,noauto 0 0" /etc/fstab
$(TARGETINST) -a means append the following text to the destination file.
Note: commands in makefile should start with Tab. Replace the spaces before $(TARGETINST) in previous code block with a Tab.
You can read the help of the $(TARGETINST) command by going to PetaLinux install directory and run components/rootfs/targetroot-inst.sh
More convenient while development is using any standard distribution.
Petalinux can be used to create the kernel, u-boot files.
Then install a Linux of your favor on the sd card and boot it up.
You can use the standard tools apt for example to install packages.
How can i make a .ubi file from a .tar.gz or folder if this is possible at all?
I looked at this (did not help me):
Creating UBI Image
To create the image from a rootfs you've built first you need to create the ubi.ini file, that describes your ubi image. Create a regular text file, ubi.ini, example contents, for more info run ubinize -h:
[ubi_rfs]
mode=ubi
image=ubifs.img
vol_id=0
vol_size=87349248
vol_type=dynamic
vol_name=ubi_rfs
vol_alignment=1
vol_flags=autoresize
Next you'll run the commands that actually build it. Here ubi.ini is the file you just created, ubifs.img is a temp file you can delete once you are done, and your_erootfs.ubi is the name of the rootfs image that will be created.
sudo /usr/sbin/mkfs.ubifs -m 2048 -e 129024 \
-c 677 -r /path/to/rootfs ubifs.img
sudo /usr/sbin/ubinize -o your_erootfs.ubi \
-p 131072 -m 2048 -s 512 -O 512 ubi.ini
Note the part in the mkfs command that says
-r /path/to/rootfs
Un-tar your tar.gz file and use the resulting directory as the destination for -r.