| 29 Nov 2024 |
 Mic92 | Interestingly I think I found now a bug in the disko mount code. | 13:37:50 |
| Mic92 | https://buildbot.thalheim.io/#/builders/64/builds/872/steps/1/logs/stdio | 13:37:52 |
| Mic92 | Here it imports the zpool before resolving device dependencies. | 13:38:09 |
| Mic92 | lassulus: any idea how to solve this? | 13:39:34 |
 lassulus | You added a reverse list | 13:40:22 |
| Mic92 | Not this is mount not unmount | 13:40:45 |
| lassulus | https://github.com/nix-community/disko/pull/891/files#diff-84f980eccc1d3f99c10f8b0e6c5c5fc2af2069517533c4c4d73264a190e85188R647 | 13:41:00 |
| Mic92 | thx | 13:44:21 |
| Mic92 | Ok. CI is green now. Ready for review! | 13:50:31 |
| Mic92 | lassulus: oh, new edge case for veritysetup. We would need a device that is used at mount time, that is different from the device at boot time. | 15:43:59 |
| lassulus | uh | 15:45:16 |
| lassulus | I'm not sure I understand :D | 15:45:25 |
| Mic92 | lassulus: So you first format /dev/sda with ext4, than mount it, write to it, unmount it. And than you run veritysetup format /dev/sda /dev/sdb. /dev/sdb is than your hash device that stores the hash merkel tree. At boot time you than mount veritysetup open mydevice /dev/sda /dev/sdb and mount /dev/mapper/mydevice to where ever it needs to go. | 15:48:12 |
| lassulus | can't you mount it in a tmpdir for the first mount and mount it with veritysetup for the mount step? | 15:52:58 |
| Mic92 | lassulus: no, because mounted veritysetup devices are read-only | 15:54:38 |
| Mic92 | The idea is to have immutable filesystems that can be verified and not tempered with. | 15:55:18 |
| lassulus | ah, well the mount command from disko is just used for installation anyway | 15:57:35 |
| lassulus | so you just define the /dev/sda in there and the verity thingie in the config? | 15:57:51 |
| lassulus | type would be similiar to the luks type | 15:58:11 |
| lassulus changed their profile picture. | 18:30:30 |
 netpleb | In reply to @joerg:thalheim.io
netpleb: there is a format mode that should not destroy your existing disk and add missing partitions disks etc. But I am not sure this works for raid conversion yet. Thanks for your reply. Ok, let's ignore the raid1 complication for now and just assume I want to add a second disk to my existing btrfs fileystem. So I would:
- update my
disks.nix file in my flake repo to include the additional disk
nixos-rebuild switch --flake . --target-host <user@target_ip>- on target system run
disko -m format ...
And hope for the best. Is that about right?
| 23:50:38 |
| netpleb | In reply to @joerg:thalheim.io
netpleb: there is a format mode that should not destroy your existing disk and add missing partitions disks etc. But I am not sure this works for raid conversion yet. * Thanks for your reply. Ok, let's ignore the raid1 complication for now and just assume I want to add a second disk to my existing btrfs fileystem. So I would:
- update my
disks.nix file in my flake repo to include the additional disk
nixos-rebuild switch --flake . --target-host <user@target_ip>- on target system run
disko -m format ...
And hope for the best. Is that about right?
| 23:50:50 |
| netpleb | I guess maybe steps #2 and #3 might be reversed? | 23:51:42 |
| 30 Nov 2024 |
| Mic92 | netpleb: that format command has to be used with caution. We only test basic transition, so your migration might have been not properly tested. You can use the --dry-run command and inspect if the commands makes sense. | 07:40:57 |
|  42398234iuodfhjkdsfjdsfsdffgs joined the room. | 10:35:34 |
|  @jappie3:matrix.org left the room. | 20:24:44 |
| 1 Dec 2024 |
|  @tanvir:hackliberty.org removed their profile picture. | 17:39:28 |
| @tanvir:hackliberty.org removed their display name ππππππ. | 17:41:50 |
| @tanvir:hackliberty.org left the room. | 17:47:24 |
| 2 Dec 2024 |
|  SΓ‘vio joined the room. | 03:40:06 |
