Do modification to rootfs (petalinux on zynq) - linux

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.

Related

Flashing to SD Yocto image following solidrun tutorial

I'm following these steps (https://github.com/SolidRun/meta-solidrun-arm-imx8) to build a Yocto image. I have built one, but on the last step, it doesn't work.
bunzip2 -c tmp/deploy/images/imx8mpsolidrun/core-image-minimal-imx8mpsolidrun.wic.bz2 | sudo dd of=/mnt/F bs=1M
dd: failed to open '/mnt/F': Is a directory
My SD is mounted on F and I'm using Ubuntu 18.04 WSL. What is wrong? I have tried to decompress the file imx8mpsolidrun/core-image-minimal-imx8mpsolidrun.wic.bz2
but i get this:
bzip2: Input file tmp/deploy/images/imx8mpsolidrun/core-image-minimal-imx8mpsolidrun.wic.bz2 is not a normal file.
What is wrong here?
Thank you so much.
Well you are not following the tutorial.
dd command allow you to write in a file not a directory, "of" stands for output file https://man7.org/linux/man-pages/man1/dd.1.html. Here you try to do it on a directory.
When you plug your usb device, a new file is created at /dev/. It is often /dev/sdX with X a letter. For instance /dev/sda or /dev/sda1.
Hence I suggest you to determine what is the file created when you plug your device.
# usb not mounted
sudo blkid
# usb mounted
sudo blkid
Then you will find your /dev/sdX. Afterwards type your command as suggested in the tutorial :
bunzip2 -c tmp/deploy/images/imx8mpsolidrun/imx-image-full-imx8mpsolidrun.wic.bz2 | sudo dd of=/dev/sdX bs=1M

How to deploy files to /boot partition with Yocto

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

Howto change Clonezilla default menu selection items

I am using clonezilla-live-2.6.1-11-amd64.iso
I would like to change the default section when booting off the live USB to perform full backups of the whole drive. for example:
on screen "Mount Clonezilla image directory" I would like to change the default from local_dev to use samba_server
on screen "Mount Samba server" I would like to change the default from 192.168.1.1 to 192.168.1.2
on screen "Mount Samba server" account change the default administrator to clonezilla
When I enter the items in
/syslinux/syslinux.cfg
.
ocs_repository="smb://clonezilla:password#192.168.1.2/zilla/
the menu's still ask me the default address of 192.18.1.1 and username administrator
so it appears I am not understanding the documentation. Does anyone have an example cfg?
I have delved into customizing "LiveISO's" and CloneZilla specifically so I will give a general idea of how I would attack this.
Looking at my notes this is all I had. To enable SSH Deamon I would unpack the ISO, edit the following and repack the iso using mksquashfs.
Eg:
Preparing to unpack ISO:
sudo apt-get install -y squashfs-tools
Copy iso to /tmp & rename live.iso
mkdir /tmp/mnt
sudo mount -o loop /tmp/live.iso /tmp/mnt
sudo find /tmp/mnt \( -name '*.squashfs' -o -name "*.SQFS" \) -exec unsquashfs -d /tmp/squashfs-root/ {} \;
sudo umount /tmp/mnt
sudo rm /tmp/mnt -R
cd /tmp/squashfs-root
This leaves you with:
/tmp/live.iso
/tmp/squashfs-root/FilesFromSquashedFS
Make Changes…..
sudo nano /tmp/squashfs-root/etc/ocs/ocs-live.conf
scroll to bottom & add:
ocs_daemon=\"ssh\"
Then Repack ISO:
cd /tmp
sudo mksquashfs /tmp/squashfs-root filesystem.squashfs
sudo rm /tmp/squashfs-root -R
This leaves you with:
/tmp/live.iso
/tmp/filesystem.squashfs
Now use an ISO editing Program to insert the filesystem.squashfs into the original ISO making sure to use the same name as the original ISO "squasedfs" used. Sometimes it's a different extension.
The above method is quite "General" but I found some LiveOS creators have scripts for booting the OS, making changes and then creating an ISO from the running OS.
For CloneZilla this is what I have found after a quick google.
https://clonezilla.org/advanced/customized-clonezilla-live.php
Simple Version of that Link:
Create Custom Script named custom-ocs ( A sample script file /usr/share/drbl/samples/custom-ocs)
Mount /home/partimag/
Copy script to /home/partimag/ and cd to /home/partimag/
Run the following to generate ISO
ocs-iso -g en_US.UTF-8 -k NONE -s -m ./custom-ocs
For other options, please run ocs-iso -h or ocs-live-dev -h to get more info.
Another Link (https://clonezilla.org/related-articles/012_Automated_USB_thumb_drive_using_Custom/Automated_USB_thumb_drive_using_Custom.html) shows this method which seems to indicate to me that if you place a script inside the ISO and then point to it via an edited syslinux.cfg (You could edit it using either of the above methods) you can auto-run it that way. The link says to boot USB and select first menu option, but I would want it to be fully automated where if you do nothing that option is selected regardless.
Here is the edit to syslinux.cfg that he uses:
kernel /live/vmlinuz1
append initrd=/live/initrd1.img boot=live union=aufs noprompt noprompt ocs_live_run="/live/image/live/custom-ocs" ocs_live_extra_param="" ocs_live_keymap="NONE" ocs_live_batch="yes" ocs_lang="en_US.UTF-8" vga=791 ip=frommedia nolocales
Note: ocs_live_run="/live/image/live/custom-ocs" This to me means run this script after booting, but I haven't tested/messed with CloneZilla in a while.
Personal Opinion: I love Parted Magic but some people don't like that it has some weird licensing now and isn't really free, but old 2013 version can be found and/or buy it for like $10. It has CloneZilla built in and also an MKISO script for making an ISO out of the booted/edited/LiveOS, but again, I generally would unpack the ISO using squashfs and then repack and inject into ISO.
Here are my links to what I've done customizing "LiveISO's". My final project years ago was a "Parted Magic" LiveISO that booted, started a PWD protected VNC sessions + ssh and e-mailed me the DHCP IP address. (I had hit and miss results with the e-mail portion, but depending on your setup you could use static IP or check router for DHCP IP address)
https://www.freesoftwareservers.com/display/FREES/Customize+LiveISO%27s
You can indeed have your Samba share automatically pre-mounted by using ocs_repository= in your vmlinuz kernel boot arguments.
However, it needs to be in the right boot file.
According to the boot parameters documentation, the relevant file is one of:
/syslinux/isolinux.cfg when booting from CD on a MBR machine
/syslinux/syslinux.cfg when booting from USB flash drive on a MBR machine
/boot/grub/grub.cfg when booting from a uEFI machine
/tftpboot/pxelinux.cfg/default or similar on your PXE server, when booting from PXE on a MBR machine
/tftpboot/grub/grub.cfg or similar on your PXE server, when booting from a uEFI netboot machine
Depending on your Samba server, you might also need to specify the SMB version to be used. From the same documentation page:
To assign the image repository via URI (Uniform Resource Identifier),
use "ocs_repository". URI supported in Clonezilla live:
[dev|smb|smb1|smb1.0|smb2|smb2.0|smb2.1|smb3|smb3.0|smb3.11|smb3.1.1|ssh|nfs|nfs4|http|https|ram]:[//[user:password#]host[:port]][/]path

Set-id bits on an ISO

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.

How to create vmlinuz and initrd

I need to create vmlinuz and initrd that will allow to launch linux with some custom scripts and settings.
How to do it properly?
I've found https://wiki.alpinelinux.org/wiki/How_to_make_a_custom_ISO_image that describes how to create ISO image but as I understand ISO and vmlinuz are different things.
I had moby initrd and vmlinuz.
vmlinuz is a kernel to load. No need to modify it for vm
initrd is what I needed.
I had to unpack it:
mkdir temp
cd temp
gunzip -c initrd.img | cpio -i
So we will have access to the filesystem that will be loaded after the kernel. I made my changes and packed it back to initrd.img with a command
find . | cpio -o -H newc | gzip > ../new-initrd.img

Resources