add not-os disk image builder and qemu #10
11
flake.nix
11
flake.nix
@ -229,6 +229,15 @@
|
|||||||
echo file binary-dist $out/boot.bin >> $out/nix-support/hydra-build-products
|
echo file binary-dist $out/boot.bin >> $out/nix-support/hydra-build-products
|
||||||
'';
|
'';
|
||||||
|
|
||||||
|
# Pinned qemu version due to networking errors in recent version 8.2.0
|
||||||
|
qemu = pkgs.qemu.overrideAttrs (oldAttrs: rec {
|
||||||
|
version = "8.1.3";
|
||||||
|
src = pkgs.fetchurl {
|
||||||
|
url = "https://download.qemu.org/qemu-${version}.tar.xz";
|
||||||
|
hash = "sha256-Q8wXaAQQVYb3T5A5jzTp+FeH3/QA07ZA2B93efviZbs=";
|
||||||
|
};
|
||||||
|
});
|
||||||
|
|
||||||
not-os-configured = (import patched-not-os {
|
not-os-configured = (import patched-not-os {
|
||||||
inherit nixpkgs;
|
inherit nixpkgs;
|
||||||
|
fsagbuya marked this conversation as resolved
Outdated
|
|||||||
extraModules = [
|
extraModules = [
|
||||||
@ -241,7 +250,7 @@
|
|||||||
not-os-qemu = { board ? "zc706" }: let
|
not-os-qemu = { board ? "zc706" }: let
|
||||||
|
fsagbuya marked this conversation as resolved
Outdated
sb10q
commented
Why -F raw? Why -F raw?
And you can use mktemp.
fsagbuya
commented
-F raw is the detected backing format for the -F raw is the detected backing format for the `img` file
```
qemu-img: /tmp/tmp.4H8j6kjlht/sd-overlay.qcow2: Backing file specified without backing format
Detected format of raw.
```
sb10q
commented
I can read the man page and figure out what -F does. The point is I'm questioning the use of the raw format over the other options that QEMU offers. I can read the man page and figure out what -F does. The point is I'm questioning the use of the raw format over the other options that QEMU offers.
fsagbuya
commented
Usage here is only for direct backing of the current Usage here is only for direct backing of the current `img` format, otherwise we can convert the raw image first to `qcow2` (or other format recommended) then apply overlay to it.
sb10q
commented
Okay. It's rather unclear from the command line that this applies only to the base SD image. Can you reorder the arguments to make it less confusing, or is this a fundamental issue with the CLI of qemu-img? Okay. It's rather unclear from the command line that this applies only to the base SD image. Can you reorder the arguments to make it less confusing, or is this a fundamental issue with the CLI of qemu-img?
sb10q
commented
And I would avoid reconverting images since those copies are quite large and waste storage or memory. And I would avoid reconverting images since those copies are quite large and waste storage or memory.
fsagbuya
commented
Rearranged the arguments for clarity while maintaining their intended function. Rearranged the arguments for clarity while maintaining their intended function.
|
|||||||
qemuScript = ''
|
qemuScript = ''
|
||||||
#!/bin/bash
|
#!/bin/bash
|
||||||
export PATH=${pkgs.qemu}/bin:$PATH
|
export PATH=${qemu}/bin:$PATH
|
||||||
|
fsagbuya marked this conversation as resolved
Outdated
sb10q
commented
What is this about? What is this about?
sb10q
commented
Just use QEMU copy-on-write overlays, duh. Just use QEMU copy-on-write overlays, duh.
|
|||||||
IMGDIR=$(mktemp -d /tmp/not-os-qemu-XXXXXX)
|
IMGDIR=$(mktemp -d /tmp/not-os-qemu-XXXXXX)
|
||||||
BASE=$(realpath $(dirname $0))
|
BASE=$(realpath $(dirname $0))
|
||||||
qemu-img create -F raw -f qcow2 -b $BASE/sd-image.img $IMGDIR/sd-overlay.qcow2 512M
|
qemu-img create -F raw -f qcow2 -b $BASE/sd-image.img $IMGDIR/sd-overlay.qcow2 512M
|
||||||
|
|||||||
@ -66,10 +66,10 @@ index c61f9d6..4e30d4b 100644
|
|||||||
config = {
|
config = {
|
||||||
system.build.bootStage2 = pkgs.substituteAll {
|
system.build.bootStage2 = pkgs.substituteAll {
|
||||||
diff --git a/zynq_image.nix b/zynq_image.nix
|
diff --git a/zynq_image.nix b/zynq_image.nix
|
||||||
index 3fa23ab..484a063 100644
|
index 3fa23ab..695d876 100644
|
||||||
--- a/zynq_image.nix
|
--- a/zynq_image.nix
|
||||||
+++ b/zynq_image.nix
|
+++ b/zynq_image.nix
|
||||||
@@ -1,66 +1,62 @@
|
@@ -1,66 +1,63 @@
|
||||||
{ config, pkgs, ... }:
|
{ config, pkgs, ... }:
|
||||||
|
|
||||||
let
|
let
|
||||||
@ -136,6 +136,7 @@ index 3fa23ab..484a063 100644
|
|||||||
- passAsFile = [ "qemuScript" ];
|
- passAsFile = [ "qemuScript" ];
|
||||||
+ networking.hostName = "zynq";
|
+ networking.hostName = "zynq";
|
||||||
+ not-os.sd = true;
|
+ not-os.sd = true;
|
||||||
|
+ not-os.simpleStaticIp = true;
|
||||||
+ system.build.zynq_image = pkgs.runCommand "zynq_image" {
|
+ system.build.zynq_image = pkgs.runCommand "zynq_image" {
|
||||||
preferLocalBuild = true;
|
preferLocalBuild = true;
|
||||||
} ''
|
} ''
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user
I don't think a VM is required to create a few filesystems and copy some files.
Where is this idea from?
The VM method is mainly from make-disk-image.nix and some examples in Github. This can be helpful to run disk formatting commands that require root privileges.
I suspect you can use e2fsprogs and mtools instead to modify the disk image directly without this little circus. Try it.
Also parted is more amenable to command line scripting than sfdisk. See the NixOS installation manual which gives you almost exactly the parted commands you need here.
Understood. Will do as suggested.
You may have to create raw filesystem images for each partition, and then dd them at the correct offsets into the final image with the partitions, unless those tools can deal with the partition tables already. Do your research.