disko | 357 Members | |
| disko - declarative disk partitioning - https://github.com/nix-community/disko | 89 Servers |
| Sender | Message | Time |
|---|---|---|
| 27 Nov 2024 | ||
but here is my question: can I somehow simply update my disks.nix file and use disko to add the 2nd device to the btrfs filesystem? or do I need to run the respective btrfs device add ... and btrfs balance start -mconvert=raid1 commands myself? | 18:45:58 | |
* but here is my question: can I somehow simply update my disks.nix file and use disko to add the 2nd device to the btrfs filesystem? or do I need to run the respective btrfs device add ... and btrfs balance start -mconvert=raid1 commands myself (which is of course how I have done it in a non-declarative pre-disko world)? | 18:46:27 | |
| 23:33:42 | ||
| 29 Nov 2024 | ||
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. | 13:07:19 | |
| I don't think we have any convert for this use case | 13:07:42 | |
| lassulus: https://github.com/nix-community/disko/pull/891/files#r1863500583 I need your help with one _unmount option definition. I don't yet understand yet, how thse magic { fs = ; dev = }; attrs are working and when I cannot use them | 13:08:30 | |
| whats the error? I think you need to use config.content._unmount.fs instead of the top level thingie? | 13:17:39 | |
| I think I fixed | 13:22:04 | |
| Interestingly I think I found now a bug in the disko mount code. | 13:37:50 | |
| https://buildbot.thalheim.io/#/builders/64/builds/872/steps/1/logs/stdio | 13:37:52 | |
| Here it imports the zpool before resolving device dependencies. | 13:38:09 | |
| lassulus: any idea how to solve this? | 13:39:34 | |
| You added a reverse list | 13:40:22 | |
| Not this is mount not unmount | 13:40:45 | |
| https://github.com/nix-community/disko/pull/891/files#diff-84f980eccc1d3f99c10f8b0e6c5c5fc2af2069517533c4c4d73264a190e85188R647 | 13:41:00 | |
| thx | 13:44:21 | |
| Ok. CI is green now. Ready for review! | 13:50:31 | |
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 | |
| uh | 15:45:16 | |
| I'm not sure I understand :D | 15:45:25 | |
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 | |
| can't you mount it in a tmpdir for the first mount and mount it with veritysetup for the mount step? | 15:52:58 | |
| lassulus: no, because mounted veritysetup devices are read-only | 15:54:38 | |
| The idea is to have immutable filesystems that can be verified and not tempered with. | 15:55:18 | |
| ah, well the mount command from disko is just used for installation anyway | 15:57:35 | |
| so you just define the /dev/sda in there and the verity thingie in the config? | 15:57:51 | |
| type would be similiar to the luks type | 15:58:11 | |
| 18:30:30 | ||
In reply to @joerg:thalheim.io 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:
| 23:50:38 | |
In reply to @joerg:thalheim.io* 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:
And hope for the best. Is that about right? | 23:50:50 | |