disko | 361 Members | |
| disko - declarative disk partitioning - https://github.com/nix-community/disko | 93 Servers |
| Sender | Message | Time |
|---|---|---|
| 29 Nov 2024 | ||
| 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 | |
| I guess maybe steps #2 and #3 might be reversed? | 23:51:42 | |
| 30 Nov 2024 | ||
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 | |
| 10:35:34 | ||
| 20:24:44 | ||
| 1 Dec 2024 | ||
| 17:39:28 | ||
| 17:41:50 | ||
| 17:47:24 | ||
| 2 Dec 2024 | ||
| 03:40:06 | ||
| 8 Dec 2024 | ||
| Does disko support unlocking a LUKS drive via crypttab after boot? | 01:53:23 | |
| * Does disko support unlocking a LUKS drive via crypttab after boot? Edit: Either I was stupid or this has been fixed | 01:54:24 | |
| * Does disko support unlocking a LUKS drive via crypttab after boot? | 01:54:38 | |
| * Hi yall, not sure if I'm just stupid and missing something but disko in disko mode is failing to setup luks on an empty drive. If the drive aleady has partitions or anything else on it it works but otherwise just fails somewhere after partitioning. It makes a luks device with password "password" even though it is set to prompt and then doesnt open the volume so creating filesystems fails. Edit: Either I was stupid or this has been fixed | 01:55:12 | |
| * Does disko support unlocking a LUKS drive via /etc/crypttab after boot? | 01:59:11 | |
| was also wondering if I have to specify drive names when using disko-install or if I can make it just use the ones in my config | 02:11:12 | |
| * Does disko support unlocking a LUKS drive via /etc/crypttab after boot? Seems there used to be a way to disable auto unlocking a specific drive at boot, maybe that's what I'm looking for? | 02:40:59 | |
| * Does disko support unlocking a LUKS drive via /etc/crypttab after boot? Seems there used to be a way to disable auto unlocking a specific drive at boot, maybe that's what I'm looking for? Edit in case anyone ever searches for this: options.intirdUnlock = false | 02:50:34 | |