Is the `attribures` patch for Disko need?

[dvaerum]

Hey nvmd

I was going through your setup and how you configured the disks using Disko to get my stuff working (and it was a huge help, thanks 😁).
I just wanted to understand this attributes config better because I tried without it, and it just seems to work.

https://github.com/nvmd/nixos-raspberrypi-demo/blob/main/disko-nvme-zfs.nix#L9-L11

https://github.com/nvmd/nixos-raspberrypi-demo/blob/main/disko-nvme-zfs.nix#L31-L33

So, can you explain why to was added? I tested on a Raspberry Pi 4B so maybe it is needed for some of the other models to boot?

[nvmd]

Hi @dvaerum,

https://github.com/nvmd/nixos-raspberrypi-demo/blob/main/disko-nvme-zfs.nix#L9-L11

Required Partition attribute is absolutely optional. I just thought it makes semantic sense to mark this partition as such, and then use the attribute in the services.udev.extraRules to make udisks ignore the partition.

https://github.com/nvmd/nixos-raspberrypi-demo/blob/main/disko-nvme-zfs.nix#L31-L33

That's an interesting experiment.
Well, Legacy BIOS Bootable is kind of required for u-boot (but not for kernelboot). Why it looks so:

• on my Raspberry Pi 4B u-boot couldn't find the partition where to look for extlinux configuration without it
• the documentation I read indicated that indeed u-boot needs this attribute on GPT drive
• default sd-card image generator also sets the attribute

Maybe the u-boot behavior could have changed in the newer version (but I kind of doubt it). Or maybe you might have some custom u-boot config on the firmare partition, <something>.env?

Disko sets the attributes (as well as labels, for example, and most if not all the other partition table related things) only on initial drive format.
When testing, did you try to reformat the drive completely, or did you just change the configuration removing the attribute and it still worked?
You can check what attributes are currently set with fdisk or similar tool.

[dvaerum]

Maybe the u-boot behavior could have changed in the newer version (but I kind of doubt it). Or maybe you might have some custom u-boot config on the firmare partition, <something>.env?

I think I am running standard firmware, I at least don't remember doing anything with custom firmware and I have just tried you demo with the only changed being the 2 attributes options commented out.

The reason I started digging around was because I couldn't find a pull-request for your patch to disko 😅
nvmd/disko@9dc58d4

When testing, did you try to reformat the drive completely, or did you just change the configuration removing the attribute and it still worked?

I used disko-install when flashing the sdcard and I can see that disko-install runs wipefs so I am pretty sure that a full wipe is done, but maybe I am missing something

sudo disko-install --flake .#server-pi-04 --disk main /dev/mmcblk0

You can check what attributes are currently set with fdisk or similar tool.

I just checked with fdisk --list-details /dev/mmcblk1 and I don't see any Attrs (or maybe that is not what you meant)

Disk /dev/mmcblk1: 59.48 GiB, 63864569856 bytes, 124735488 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 713A049E-4C78-483C-88FE-317C3BE119FE
First usable LBA: 34
Last usable LBA: 124735454
Alternative LBA: 124735487
Partition entries starting LBA: 2
Allocated partition entries: 128
Partition entries ending LBA: 33

Device           Start       End   Sectors Type-UUID                            UUID                                 Name          Attrs
/dev/mmcblk1p1    2048   4196351   4194304 EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 C17DE04D-A4F5-4972-87BF-3F91F1AFCC9D FIRMWARE      
/dev/mmcblk1p2 4196352   8390655   4194304 C12A7328-F81F-11D2-BA4B-00A0C93EC93B C7D9A7FB-5238-4C1A-A37D-6E046A277CCC ESP           
/dev/mmcblk1p3 8390656 124733439 116342784 0FC63DAF-8483-4772-8E79-3D69D8477DE4 9A81D935-2FBD-4951-B037-8B0CB909D314 disk-main-zfs 

[nvmd]

The reason I started digging around was because I couldn't find a pull-request for your patch to disko 😅
nvmd/disko@9dc58d4

Well, these changes weren't upstreamed only due to the lack of time to do so.
I see someone decided to step forward and created a PR with my cherry-picked commit nix-community/disko#1069. So here it is:)

I just checked with fdisk --list-details /dev/mmcblk1 and I don't see any Attrs (or maybe that is not what you meant)

Yes, that's exactly what I meant. It would look like this if you had them set:

 Attrs
RequiredPartition
LegacyBIOSBootable

I see you have /dev/mmcblk0 and /dev/mmcblk1. Is that the same physical device?

I've checked that sd-image doesn't in fact set these GPT attributes, but still sets MBR bootable flag. This is still according to u-boot docs.

I guess, it works for you now, maybe it is indeed optional, at least in some scenarios.

I remember the RPi4 not booting without the LegacyBIOSBootable attribute, on the system that boots from USB SATA drive (i.e. /dev/sda), so that I had to, naturally, add attributes functionality to disko.

Now, unfortunately, I don't have a board to test the configuration similar to what you have: u-boot from sdcard, but with gpt partition table.

[dvaerum]

I see someone decided to step forward and created a PR with my cherry-picked commit nix-community/disko#1069. So here it is:)

Awesome, that was my plan to do to, but maybe there was a reason for why it wasn't done, so I wanted to ask 😅 and I was curious why it worked without it 😁

[nvmd]

You're welcome, thank you for bringing that up, actually!

[dvaerum]

You're welcome, thank you for bringing that up, actually!

My pleasure 😁

[stepbrobd]

@nvmd absolute goat thanks for making this!

as a temporary workaround you can do the following:

    disko.url = "github:nix-community/disko?ref=pull/1069/merge";