Shulou(Shulou.com)06/01 Report--

This article mainly shows you "how to modify the disk image in linux to create a home lab based on raspberry pie". It is easy to understand and well-organized. I hope it can help you solve your doubts. Let me lead you to study and learn this article "how to modify disk image in linux to create a home lab based on raspberry pie".

Use raspberry pie or other single board computers to create a "home private cloud".

Building a home lab can be an interesting way to entertain yourself while learning new concepts and experimenting with new technologies. Thanks to the popularity of single board computers (SBC), led by raspberry pie, it is easy to build a multi-computer lab in a comfortable home. It is also an excellent way to create a "home private cloud" to experience cloud native technology for less money than trying to build the same configuration with mainstream cloud service providers.

This article describes how to modify the disk image of a raspberry pie or other single board computer, preconfigure the host's SSH, and disable services that force campaign interaction configuration at first startup. This is a great way to get your device "up and running", similar to a cloud instance. After that, you can use the automated process to make more professional and in-depth configuration through SSH connections.

In addition, when adding more raspberry pie to your lab, modify the disk image so that you only need to write the image to a SD card and put it in the raspberry pie!

Multiple Raspberry Pi computers, a switch, and a power bank

Uncompress and mount the image

For this project, you need to modify a server disk image. During the test, I used Fedora Server 31 ARM. After you download the disk image and verify its checksum, you need to unzip it and mount it to a location in the host's file system so that you can modify it as needed.

You can use the xz command to extract the Fedora server image with the-- decompress parameter:

Xz-decompress Fedora-Server-armhfp-X-y.z-sda.raw.xz

This leaves an unzipped original disk image (it automatically replaces the .xz compressed file). The original disk image is just as it sounds: a file that contains all the data on the formatted disk. This contains partition information, boot partition, root partition, and other partitions. You need to mount the partition you intend to modify, but to do this, you need to know the starting location and sector size of the partition in the disk image so that you can mount the correct sector of the file.

Fortunately, you can use the fdisk command on a disk image as easily as on a real disk. Use the-- list or-l parameters to view a list of partitions and their information:

# use fdisk to list the partitions of the original image file: $fdisk-l Fedora-Server-armhfp-31-1.9-sda.rawDisk Fedora-Server-armhfp-X-y.z-sda.raw: 3.2 GiB, 3242196992 bytes 6332416 sectorsUnits: sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisklabel type: dosDisk identifier: 0xdaad9f57 Device Boot Start End Sectors Size Id TypeFedora-Server-armhfp-X-y.z-sda.raw1 8192 163839 155648 76M c W95 FFedora-Server-armhfp-X-y.z-sda.raw2 * 163840 1163263 999424 488M 83 LinuxFedora-Server -armhfp-X-y.z-sda.raw3 1163264 6047743 4884480 2.3G 83 Linux

All the information you need is available in the output above. Line 3 represents the sector size (both logical and physical): 512 bytes / 512 bytes.

The device list shows the partitions in the original disk image. First, Fedora-Server-armhfp-X-y.z-sda.raw1 is undoubtedly the bootstrap partition because it is the first, small (76MB only), and the type is identified as c, that is, W95 FAT32 (LBA), which is a FAT32 partition launched from the SD card.

The second partition is not very large, only 488MB. This partition is a Linux native type partition (Id 83), which may be a Linux boot partition with kernel and initramfs.

The third partition may be what you need: it has the size of 2.3GB, so there should be a major part of the distribution in it, and it is a Linux native partition type, which is to be expected. This partition should contain the partitions and data that you need to modify.

The third partition starts at sector 1163264 (shown as the Start column in the output of fdisk), so your mount offset is 595591168, which is calculated by multiplying the sector size by the starting sector (1163264) (that is, 512 * 1163264). This means that you need to mount the file at an offset of 595591168 in order to mount it to the correct location.

Equipped with this information, you can now mount the third partition to your home directory:

$mkdir ~ / mnt$ sudo mount-o loop,offset=595591168 Fedora-Server-armhfp-X-y.z-sda.raw ~ / mnt$ ls ~ / mnt works directly in the disk image

After the disk image has been unzipped and mounted to a location on the host, you can modify the image to suit your needs. In my opinion, the easiest way to make changes to the mirror is to use chroot to change the working root of your session to the working root of the mounted mirror. But it's a little tricky.

After you change the root directory, your session will use the binaries in the new root directory. Unless you are doing all this on an ARM system, the architecture of the unzipped disk image will be different from the host system you are using. Even in a chroot environment, the host system cannot use binaries of a different architecture. At the very least, it can't be used on this machine.

Fortunately, there is a solution: qemu-user-static. Instructions from Debian Wiki:

"[qemu-user-static] provides simulation binaries in user mode and is statically built. In this mode, QEMU can start a Linux process compiled for another CPU on one CPU... if the binfmt-support package is installed, the qemu-user-static package registers the binary format that the emulator can handle so that it can run binaries from other architectures directly."

This is exactly what you need to work in a non-native architecture in a chroot environment. If the host system is Fedora, use DNF to install the qemu-user-static package and restart systemd-binfmt.service:

# use DNF to enable a non-local arch chroot environment and add new binary format information # the output mirrors the compact $dnf install qemu-user-static$ systemctl restart systemd-binfmt.service

Using this method, you can change the root directory to a mounted disk image, and run the uname command to verify that everything is working:

Sudo chroot ~ / mnt/ / usr/bin/uname-a-rLinux marvin 5.5.16-200.fc31.x86_64 # 1 SMP Wed Apr 8 16:43:33 UTC 2020 armv7l armv7l armv7l GNU/Linux

Running uname in a chroot environment displays armv7l, the architecture of the original disk mirror, rather than the host architecture in the output. Everything is as expected, you can continue to modify the mirror.

Modify disk image

Now that you can switch directly to the ARM-based disk image and work in that environment, you can modify the mirror itself. You need to set up the image so that it can be started and accessed immediately without any additional settings on the raspberry pie. To do this, you need to install and enable sshd (OpenSSH daemon) and add an authorized password for SSH access.

To make it behave more like a cloud environment and realize your dream of building a private cloud at home, add a local user, give that user sudo access, and (like a heavy user in the cloud) allow that user to use sudo without a password.

So, what you're going to do is:

Install and enable SSHD (SSHD is already installed and enabled in the Fedora ARM image, but you may need to perform these tasks manually for your distribution)

Set up a local user

Allow local users to use sudo (no password required, optional)

Add authorization key

Allow root to mirror SSH with an authorized password (optional)

I use the GitHub function, which allows you to upload your SSH public key and access it at https://github.com/.keys. I find this a convenient way to distribute public keys, but I am paranoid by nature, and I always check to see if the downloaded key matches what I expect. If you don't want to use this method, you can copy your public key from your host to the chroot environment, or you can host the public key on the Web server you control so that you can use the same workflow.

To start modifying the disk image, change the root directory to the mounted disk image again, and start a shell this time so that you can run multiple commands:

# for brevity, omit the output of these commands (if any) $sudo chroot ~ / mnt / bin/bash # install openssh-server and enable it (done on Fedora) $dnf install-y openssh-server$ systemctl enable sshd.service # allow root to use an authorized password to access SSH$ mkdir / root/.ssh # download or add an additional authorization password file Your public password # replace URL with your own public password path $curl-o / root/.ssh/authorized_keys$ chmod 700 / root/.ssh$ chmod 600 / root/.ssh/authorized_keys # add a local user And put them into the wheel group # change the group and users to everything you want useradd-g chris-G wheel-m-u 1000 chris # download and add your authorization password # change the home directory and URLmkdir / home/chris/.sshcurl-o / home/chris/.ssh/authorized_keyschmod 700 / home/chris/.sshchmod 600 / home/chris/.ssh/authorized_keyschown-R chris.chris / home/chris/ as you did above .ssh / # allows wheel groups (using your local users) without using a password to use susoecho "% wheel ALL= (ALL) NOPASSWD:ALL" > > / etc/sudoers.d/91-wheel-nopasswd

This is all you need to do to set up SSH when you start a raspberry pie or other single board computer for the first time. However, each distribution has its own characteristics. For example, Raspbian already contains a local user: pi, and does not use the wheel group. So for Raspbian, it's best to use an existing user, or delete the pi user and replace it with another user.

In the case of Fedora ARM, the image will prompt you to complete the settings when the first boot starts. This will destroy the purpose of the changes you made above, especially before the setup is complete, it will completely prevent startup. Your goal is to make raspberry pie work like part of a private cloud infrastructure, and this workflow includes setting up the host remotely via SSH when the host starts. Disables the initialization setting, which is controlled by initial-setup.service:

# disable initial-setup.serviceunlink / etc/systemd/system/multi-user.target.wants/initial-setup.serviceunlink / etc/systemd/system/graphical.target.wants/initial-setup.service for multiple users and drawing targets

When you are in the chroot environment, you can make any other changes you want to your system, or just leave it there and configure it through SSH according to the cloud native workflow after the first startup.

Recompress and install the modified image

After making these changes, all that's left is to recompress the disk image and install it on your raspberry pie's SD card.

Ensure that you exit the chroot environment, and then unmount the disk mirror:

$sudo umount ~ / mnt/

Just as you initially unzipped the image, you can use the xz command again to compress the image. By using the-- keep parameter, xz retains the original mirror rather than cleaning it up. Although this will take up more disk space, the retained uncompressed image will allow you to make incremental changes to the image you are working on without having to decompress it every time. This is great for saving time when testing and adjusting mirrors.

# compressed disk image as a .xz file, but keep the original disk image xz-- compress Fedora-Server-armhfp-31-1.9-sda.raw-- keep

The compression process will take some time, so take advantage of this time to stand up, stretch your body, and let your blood flow again.

After the compression is complete, you can copy the new and modified disk image to the SD card for use with raspberry pie. The standard dd method of placing images on SD cards is also easy to use, but I like to use Fedora's arm-image-installer because it provides some options when dealing with unedited images. It also works well with edited mirrors and is a little more friendly than the dd command.

Be sure to check which disk drive the SD card is on and use it with the-- media parameter:

# use arm-image-installer to copy the modified disk and mirror it to the SD card arm-image-installer-- image=Fedora-Server-armhfp-X-y.z-sda.raw.xz-- target=rpi3-- media=/dev/sdc-- norootpass-- resizefs-y

Now that you have a new, modified Fedora Server ARM image ready for raspberry pie or other single board computers, you are ready to boot and immediately SSH into your modified image. This method can also be used to make other changes, and you can also use raw disk images from other distributions if you prefer them to Fedora. This is a good foundation to start building a home lab private cloud.

These are all the contents of the article "how to modify disk images in linux to create a home lab based on raspberry pie". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.