This fix should also make this Hydra job happy again: https://hydra.nixos.org/job/nixos/trunk-combined/nixos.sd_image_raspberrypi4.aarch64-linux/

I've verified that the resulting SD-Card image boots on my Raspberry Pi 4. 🍾

For me sudo didn't work any more. Could this possibly be because of this change?
I think some shared library wasn't owned by the correct user (root).
Edit: Can you confirm this behavior?

For me sudo didn't work any more. Could this possibly be because of this change?
I think some shared library wasn't owned by the correct user (root).
Edit: Can you confirm this behavior?

fakeroot call is required if If you're using Single User nix.

I'm cross-compiling on NixOS. What do you mean with single-user nix?

Edit: I will retry - will take some time as I also garbage collected before to be safe.

I'm cross-compiling on NixOS. What do you mean with single-user nix?

I had this issue when using https://nixos.org/nix/manual/#sect-single-user-installation on Ubuntu, that's why there is a fakeroot call.

As far as I understand https://git.qemu.org/?p=qemu.git;a=commit;h=d8c08b1e6c7b1a5be1ec70e339437823a41b1946 a new version of qemu might fix that and allow us to use fakeroot again? Also I consistently get an image file with invalid permissions inside (the ones from my user) with this pull request.

As far as I understand https://git.qemu.org/?p=qemu.git;a=commit;h=d8c08b1e6c7b1a5be1ec70e339437823a41b1946 a new version of qemu might fix that and allow us to use fakeroot again? Also I consistently get an image file with invalid permissions inside (the ones from my user) with this pull request.

@mohe2015 I also see subtle issues with building this from a multi-user install that I didn't notice before:

[julian@nixos:~]$ sudo ls
sudo: error in /etc/sudo.conf, line 0 while loading plugin "sudoers_policy"
sudo: /nix/store/dga8f95c24vziiir8xalmrfay4f3jxhg-sudo-1.8.31p1/libexec/sudo/sudoers.so must be owned by uid 0
sudo: fatal error, unable to load plugins

[julian@nixos:~]$ ls -lh /nix/store/dga8f95c24vziiir8xalmrfay4f3jxhg-sudo-1.8.31p1/libexec/sudo/sudoers.so
-r--r--r-- 1 julian users 393K Jan  1  1970 /nix/store/dga8f95c24vziiir8xalmrfay4f3jxhg-sudo-1.8.31p1/libexec/sudo/sudoers.so

Mmh. I think this can be fixed by using mkfs.ext4 options:

                   root_owner[=uid:gid]
                          Specify the numeric user and group ID of the root directory.  If no UID:GID is  specified,
                          use  the user and group ID of the user running mke2fs.

Will try this later. Converting this PR to a draft until then to prevent people from merging it. :)

I couldn't get it to work with the root_owner option. I think it's result is the following:

[moritz@nixos:~/nixpkgs]$ ls -l /run/media/moritz/
total 8
drwxr-xr-x 3 moritz users 4096 Jan  1  1970 NIXOS_BOOT
drwxr-xr-x 4 root   root  4096 Jan  1  1970 NIXOS_SD

[moritz@nixos:~/nixpkgs]$ ls -l /run/media/moritz/NIXOS_SD/
total 236
drwx------ 2 root   root   16384 Jan  1  1970 lost+found
drwxr-xr-x 3 moritz users   4096 Jan  1  1970 nix
-r--r--r-- 1 moritz users 217404 Jan  1  1970 nix-path-registration

So the root directory is owned by the specified user but not the files in it. Maybe I did something wrong so you should still try it out.

Edit: Updating qemu to 5.1.0-rc1 and using fakeroot did work but I don't know if that change would currently be accepted (as it is not yet a stable release; see https://wiki.qemu.org/Planning/5.1 for their current plans)

@mohe2015 You are right, the root_owner option is not good enough to do what we want. What does confuse me is how the store paths in the image actually have my user's UID, even through they are built by a nixbld user.

@mohe2015 I'm not sure how we ever end up with sane uid/gids using mkfs.ext4:

In the build sandbox the nixbld user is 1000:100, but outside of the sandbox this is usually the uid/gid of the first user in the system. Hence we get the broken owners in the image.

Ideally, mkfs.ext4 would support a uid mapping configuration, but unfortunately it doesn't. Manually doing chown -R root:root before packing it into the file system also doesn't work, because it ends up with lots of invalid argument errors.

I'm open to ideas...

For me it worked by building with qemu 5.1.0-rc1 and using fakeroot. At least sudo worked and I couldn't find something nonworking. But there still were some strange file permissions in there.

For me it worked by building with qemu 5.1.0-rc1 and normally using fakeroot. At least sudo worked and I couldn't find something nonworking.

Ah, because fakeroot makes stat etc return uid 0 for files owned by the current user (nixbld) these end up being owned by root in the generated image. It feels a bit accidental. :)

Yeah, I think the problem is that running chown root:root without root permissions wouldn't work so you use fakeroot to fool mkfs.ext4 into thinking its a file owned by root so it can build the correct file system. But honestly I don't know how nix works and if I'm right.

I think the problem is that running chown root:root without root permissions wouldn't work so you use fakeroot to fool mkfs.ext4 into thinking its a file owned by root so it can build the correct file system.

Yes, that's also my current understanding. Not an ideal situation.

I've added the fakeroot call again. This doesn't make the cross-compilation setup painless, but should work for native builds of the raspberry pi 4 install image at least.

I think you need to also add back fakeroot in two other places.

And also do you know more whether qemu 5.1.0-rc1 would be accepted in nixpkgs unstable? I assume I will have to wait for the release until it gets incoporated here but I don't know.

I think you need to also add back fakeroot in two other places.

You were too fast, I fixed it right after @GrahamcOfBorg complained. :)

And also do you know more whether qemu 5.1.0-rc1 would be accepted in nixpkgs unstable? I assume I will have to wait for the release until it gets incoporated here but I don't know.

The binfmt emulation is pretty nice and having it fail in weird ways definitely sucks. No idea whether this counts as good reason to include a RC into unstable.

Btw, with the current version of this PR and qemu 5.1-rc1 on the build host, I can build a SD Card image that works. Finally!

Thanks for this fix -- I ran into this breakage locally and this worked like a charm.

As the pr became quite uncontroversial now, i would merge this in the next days if no one objects.

FWIW, the Debian maintainers decided to backport the QEMU fix @mohe2015 mentioned in their stable QEMU 5.0 package (original issue). Perhaps we can reuse the same patch and apply it on top of the current QEMU 5 package in nixpkgs?

https://sources.debian.org/patches/qemu/1:5.0-14/linux-user-refactor-ipc-syscall-and-support-of-semtimedop.patch/

In the meantime, is this ready to merge @tfc? I just got a Raspberry Pi 4B in the mail, and I'm hyped 👀