Bug information:

The caligula-bin AUR package does not install properly, giving the reason "One or more files did not pass the validity check!"
Upon further inspection of the PKGBUILD it has the incorrect checksum.

The checksum of the caligula-x86_64-linux in release 0.4.3 is d3f6753312ac8283c9c0b4e1821a40500209f0b0fcb95f8dd23be0e44f9c95dc, however the checksum in the AUR PKGBUILD is 15ce35f702f2afdd78cb8d829f24bb9a9ab2661c350f30c7cffe577326b9ef73.

OS/Environment

• OS: Arch Linux
• Version: v0.4.3
• Distribution channel: AUR

omg nonbinary log files i'm so happy for them

I'm just gonna use NixOS VMs to do this because that seems like the easiest to set up.

The fancy graphy TUI might not be very accessible or screenreader friendly, so a proper GUI would improve this. Also, it might just be more user-friendly for people less familiar with the terminal, while still trying to be lightweight as possible.

Existing GUI lightweight disk imagers

Other lightweight disk imaging GUIs exist, like Rufus and such, but they don't have a cool graph like I do, and as we all know, cool graphs are extremely important. Additionally, they don't have blackjack and hookers, and I would make mine with blackjack and hookers.

How to invoke?

The GUI code would probably be invoked with caligula gui or caligula-gui. Additionally, it should be behind a feature flag so that the TUI-only version doesn't get excessively bloated. We would then end up with 2 new versions, something like caligula-minimal and caligula-full, which might get confusing and a bit painful to work with.

I suppose the MacOS (and eventual Windows) version could just have it baked in by default because those systems almost always have a desktop.

The whole damn thing needs more colors

There are starting to be many eyes on this project so I should document some of the development tricks and rules I'd like people to follow

PR #70, which increased the amount of logging, also increased the binary size by over 1MB across all platforms, which violates our current SLA for max binary size of 4MB. Can we shrink it?

This will improve our ability to track the performance of sensitive parts, namely the writer process. Likely, we would use the criterion crate to implement this.

This issue only calls for a system that may be run manually; CI-run benchmarks can be done later.

yeah

Because it's probably better to do that tbh

support escalating through systemd's run0

Describe the bug

$ caligula burn ~/downloads/licheervnano_sd.img.lz4
Input file: /home/felix/downloads/licheervnano_sd.img.lz4
Detected compression format: no compression
> Is this okay? No

To Reproduce

Download the lz4 images from https://github.com/Fishwaldo/sophgo-sg200x-debian/releases and try to burn it

Expected behavior

lz4 compression should be detected and decompressed.

OS/Environment

• OS: Arch Linux
• Version: 0.4.4
• Distribution channel: distribution package

Describe the bug

A clear and concise description of what the bug is.

To Reproduce

Steps to reproduce the behavior:

1. Plug in a USB
2. ./caligula-x86_64-darwin burn caligula-x86_64-darwin
3. Go through the prompts
4. Select the plugged USB
5. The osascript prompt pops up. Entering in the password, however, does not appear to grant sudo, and the password is asked in the terminal again.
6. Running yields the error

Full terminal output:

> ./caligula-x86_64-darwin burn caligula-x86_64-darwin
Couldn't detect compression format for caligula-x86_64-darwin
> What format to use? no compression
> What is the file's hash?
Input is empty
> What is the file's hash?
Input is empty
? What is the file's hash? <canceled>
> Select target disk disk2 | Generic STORAGE DEVICE Media - 62.6 GB (disk, remov
able: yes)
Input: caligula-x86_64-darwin
  Size: 4.0 MB
  Compression: no compression

Output: disk2
  Model: Generic STORAGE DEVICE Media
  Size: 62.6 GB
  Type: disk
  Path: /dev/rdisk2
  Removable: yes

> Is this okay? Yes
> We don't have permissions on /dev/rdisk2. Escalate using sudo? Yes

Password:
An unexpected error occurred: panicked at src/ui/main.rs:36:9:
Explicit failure signaled: Some(UnknownChildProcError("Resource busy (os error 16)"))

Please report bugs to https://github.com/ifd3f/caligula/issues and attach the following log files, if they exist:
- /var/folders/f1/0sb8zs9d5ps5pt4h1w9g8zzm0000gp/T/caligula/log/1714949843182.main.log
- /var/folders/f1/0sb8zs9d5ps5pt4h1w9g8zzm0000gp/T/caligula/log/1714949843182.child.log

Expected behavior

You only get asked for password once, and the burn happens

Log files

1714949843182.child.log
1714949843182.main.log

OS/Environment

• OS: MacOS Version 14.2.1 (23C71) x86_64
• Version: v0.4.4
• Distribution channel: release binary

Additional context

N/A

Because coverage is nice.

Though I suppose on the other hand, it's rather embarrassing how little test coverage I have, so,

It's complicated, polluting, and doing this will let us drop crate interprocess.

Is your feature request related to a problem? Please describe.

I'm always frustrated when can't pkgs.caligula

Describe the solution you'd like

put caligula in nixpkgs

Describe alternatives you've considered

flake which is annoying

Additional context

no

I got rid of it because it requires very specific byte alignment and I was too lazy to fix it. But, it should bring small efficiency gains, so we should probably bring it back at some point.

Besides allowing the user to provide a plain hash, also allow the user to simply pick a hash algorithm and compute the file's hash, without validating the file against an existing hash.

It failed earlier because the Apple SDK headers I was linking to were failing for some strange reason.

This functionality would be useful for stuff like:

• adding a ssh and wpa_supplicant file to raspberry pi images
• adding some configs to an install image

UX

A MVP would look like running a script after burn is complete. So the raspberry pi example script might look like:

touch $out1/ssh
wpa_passphrase mywifi mypassword > $out1/ssh

where $out1, $out2, $out3, ... are environment vars set to paths of mounted partitions.

Title.

The main reason I mention this is because it would break the AUR bin package if it were updated to 0.4.3 with there being no binaries to get from that release 😅

If it's just too soon and they like haven't shown up yet or something feel free to yell at me.

A UI to image lots of disks at once! Like etcherPro if it weren't $1200 and Electron

That way it can get compiled with the right flags :3

Is your feature request related to a problem? Please describe.

Lots of disk images are distributed via zip files. We should be able to handle those automatically.

This wasn't implemented earlier because zip files are an archive format and I was unsure how I would handle the multi-file case.

Describe the solution you'd like

If a zip file is provided, find the most suitable file to image inside, and ask the user to burn that one.

For example, let's say we have these items in a zip file:

• something-arm64-whatever.iso (8GiB)
• LICENSE (2KiB)
• README (1KiB)

we would obviously want to pick something-arm64-whatever.iso.

Probably the algorithm would go something like this:

1. Find the first file with extension .iso or .img. If there are multiple files, bail and ask the user to pick a specific file in the zip file, with an autocompletey searchy prompt.
2. Find the largest file.

In both cases, we would obviously ask the user to confirm that this is indeed the file that they want.

Describe alternatives you've considered

N/A

Additional context

N/A

Currently, we always do a block size of 128KiB. But maybe there's a faster block size, and the code should figure that out.

• For Linux, maybe look under /sys/class/block/nvme0n1/queue/*_block_size?
• For MacOS, the native bindings already export block size, but perhaps there's a better parameter to use.
• Maybe we could vary the block size as we write.

Sure, I won't be testing them much, but having automated builds for computers I don't have, like aarch64-linux, would be very useful.

We should probably have a bunch of flags like so:

• -f/--force means "yes to everything except sudo escalation"
• --use-sudo means "yes to specifically sudo escalation, but not necessarily everything else"
• -i/--interactive is the current behavior, and --non-interactive means "do not ask, and fail if we don't know what to do." If not specified, this condition should be detected via isatty().

If any arguments are underspecified for any of these conditions (i.e. --hash=ask or no --out) then we should immediately fail.

This task may require a good amount of refactoring to accomplish.

This sounds satanic, but it's really just a background process running as root, that spawns other processes running as root. The point is so that we can spawn multiple writers running as root.

This is meant to support #64. The reason we can't just sudo caligula writer processes over and over again is because most desktop sudo installations (rightfully) drop your sudo cookie after a while and it would suck to have to repeatedly enter in your password when you only really need to do it once.

Not all processes would need root permissions; in that case, the writer processes would simply fork off the main user process. Here's an example of how the process parenting might look:

                                                    ----- (root) writer
                                                   /
(user) main process ------ (root) escalated daemon ------ (root) writer
                    \                              \
                     ----- (user) writer            ----- (root) writer

All children will speak directly to the main process directly by connecting to its named socket. No pipe forwarding or multiplexing should be necessary.

Describe the bug

caligula shows an ultra fast "Burning" progress while decompressing:

and the progress stopped while real writing is happening, according to dstat:

The time chart actually shows the "missing" part:

(Decompressing for ~1s, verifying for ~10s, and the remaining ~20s is the missing "actual write" time)

OS/Environment

• Terminal emulator: GNOME Console
• OS: Arch Linux
• Version: 0.4.5
• Distribution channel: distribution package

Introduced as a result of dependency updates in #53

After running chmod +x on Caligula's binary it MacOS refuses to run it, saying it may be malware.

Pwease 🥺👉🏻👈🏻

Describe the bug

caligula's TUI always freezes after showing "Done". I tried a lot of different keys and also searched through the bug tracker, but didn't find a way to exit it normally.

Ctrl-C will kill the TUI successfully, but leaving the terminal in a non-operational state (no char output on key input) that could only be fixed by something like "reset".

Expected behavior

Press any key, or some easily expected keys (Esc, q, Enter...) to exit and prompt it.

OS/Environment

• OS: Arch Linux
• Version: 0.4.4
• Distribution channel: distribution package

I turned it off because the libraries I'm using bind to a C library, and when I cross-compile to it, it uses the host compiler instead of the cross compiler, making the builds fail.

Is your feature request related to a problem? Please describe.

I'm always frustrated when cannot cargo install caligula

Describe the solution you'd like

cargo publish caligula

Describe alternatives you've considered

Not doing that

Additional context

no

Usually, if you just straight-up dd a Windows ISO to a disk, it will likely not boot. You need to do some other stuff, described here.

We'll want to auto-detect if we're writing windows and write it.

It's like, so many different things coming together in weird ways so I should do this

Is your feature request related to a problem? Please describe.

This should improve the pipeline by making it so that we're certain the code changes don't break things.

Describe the solution you'd like

An end-to-end NixOS test that does the following:

• Spawn a VM with a USB
• Run caligula in a tmux session
• Send inputs to caligula in tmux
• Preferably, also takes a dump of the output on both success and failure

Describe alternatives you've considered

• Running it outside of a NixOS test, as a script that invokes QEMU

Additional context

N/A