how to inject workloads into the provided FS image (no loop mount / no guest networking) and ensure runtime dependencies?

[sdcnsd]

I’m using your CXL-DMSim (gem5 FS) setup and trying to reproduce / extend the experiments by adding additional workloads (Redis + memtier_benchmark). My environment is a cloud server where loop mounting is not available, and the guest OS inside gem5 appears to have no network interface (only lo), so I can’t install dependencies via apt inside the guest.

Could you please share the recommended / official workflow you used to add workloads into the provided disk image and ensure they run correctly?

My setup

Host: cloud VM (cannot use loop mount)

Guest: no networking (ip a shows only lo; ping 8.8.8.8 “Network is unreachable”)

What I tried

Inject files into the ext4 partition using debugfs:

debugfs -w -R "write <host_file> /home/cxl_benchmark/" parsec_p1.img

then merge back using dd if=parsec_p1.img of=parsec.img bs=512 seek=2048 conv=notrunc

For memtier, I created a portable bundle (binary + copied shared libraries + LD_LIBRARY_PATH wrapper). This works.

For Redis, bundling /usr/bin/redis-server + copied libraries causes a segfault inside the guest (likely ABI / glibc mismatch between host and guest rootfs).

Questions

Did you build the workloads inside the guest rootfs (so they match the guest glibc), or on the host?

If on the host, did you use:

static linking (musl/static), or

a chroot/container that matches the guest OS version (to ensure ABI compatibility), or

another approach?

Do you have a “known-good” workload package / binaries (e.g., prebuilt memtier/redis, or scripts) that you used for the paper experiments?

Is guest networking intentionally disabled in your image/config? If so, is there an intended way to install packages (offline debs, chroot build, etc.)?

Any recommended settings for persistent vs non-persistent Redis during benchmarking (AOF/RDB off) and how you collected tail latency (P50/P99)?

If you have a short step-by-step reproducibility note (or the exact scripts you used to inject workloads), that would be extremely helpful.

Thanks a lot

[IcarusSong]

I've dealt with the same problem. The key insight is: don't modify the image on the cloud server — do it on a local machine with root access, then upload.

I use a kpartx + chroot approach:

# 1. Map partitions
sudo kpartx -av parsec.img

# 2. Mount the partition
sudo mount /dev/mapper/loop0p1 /mnt/gem5_guest

# 3. Bind-mount system dirs + copy DNS config for network access
sudo mount --bind /dev /mnt/gem5_guest/dev
sudo mount --bind /proc /mnt/gem5_guest/proc
sudo mount --bind /sys /mnt/gem5_guest/sys
sudo cp /etc/resolv.conf /mnt/gem5_guest/etc/resolv.conf

# 4. Chroot in — full Linux environment with network
sudo chroot /mnt/gem5_guest /bin/bash

# Inside chroot: apt install, compile from source, etc.
apt update && apt install -y redis-server build-essential ...

# 5. Exit, unmount, cleanup
exit
sudo umount /mnt/gem5_guest/{dev,proc,sys}
sudo umount /mnt/gem5_guest
sudo kpartx -d parsec.img

Then upload the modified image to your cloud server.

Why Redis segfaults: copying binaries + .so from the host causes glibc ABI mismatch with the guest rootfs. Building inside the chroot uses the guest's own toolchain, so everything is compatible.

[ferry-hhh]

Thank you @sdcnsd for your interest, and many thanks to @IcarusSong for the reply. Regarding the questions above:

1. We compiled all the workloads by mounting the image on the host and then using chroot. This is the exact same workflow as the solution provided by @IcarusSong. The only difference is the second step, where we used sudo mount -o loop,offset=$((2048*512)) parsec.img local_mnt in our local environment.
2. For the issue with the lack of internet access, we have a potential solution. You can refer to Can't connect to internet in chroot:

# Run the following after entering chroot:
echo "nameserver 8.8.8.8" > /etc/resolv.conf

# If you encounter the error "bash: /etc/resolv.conf: No such file or directory",
# delete resolv.conf first, then create the file and run it again:
rm /etc/resolv.conf
touch /etc/resolv.conf
echo "nameserver 8.8.8.8" > /etc/resolv.conf

3. Our Redis evaluation is built upon this project: https://github.com/basicthinker/YCSB-C/tree/master.