-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathTODO
117 lines (84 loc) · 5.31 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
-*- mode: outline -*-
* For 1.0.0
- fix all the FIXMEs
- documentation (html, man)
- Maybe revamp command-line usage?
- Maybe add checksum verification of sqsh_layers to linuxrc? If anything's
been modified, make a lot of noise and don't boot.
- Add --with-system-{busybox,e2fsprogs,eudev,lvm2,mdadm,squashfs-tools}
configure flags.
- Pretty sure I broke out-of-tree building at some point... need to fix that.
- Build something into the build system to fetch submodules when building from
dist tarball. Right now, you can really only build the subprojects via a
git clone. (This means our dist tarballs are currently useless, as we don't
yet have --with-system-whatever flags...)
* For 0.x
- Should prefix all our non-standard kernel commandline options w/
ruckusrd.whatever. Once we have config-file support, we should be able to
keep it a bit less verbose, and this will guard us against accidentally
using the same option as something in the kernel or systemd. A couple
should probably stay unprefixed (e.g., root=, quiet).
- Consider adding `rescue` to kick-off a dialog-based rootfs recovery of some
sort? Or maybe just add a /bin/rescue script to run via `initramsys` shell?
- Udev rules to rename network interfaces like systemd, so pre-boot network
config can actually have the right device names?
https://systemd.io/PREDICTABLE_INTERFACE_NAMES/
https://wiki.archlinux.org/title/Network_configuration#Change_interface_name
* proposed for 0.23
- For long-lasting systems, constantly installing updates, doing regular work,
etc, eventually results in essentially the entire collection of sqsh_layers
being replaced in upper with new files. So keeping the original sqsh_layers
around and overlaying eventually turns into a bit of a resource (cpu and
space) waste.
Instead of doing sqsh-commit and sqsh-merge, the user may choose to
"un-sqsh_layer" back into a "regular" root filesystem. Perhaps provide
sqsh_layers2regular and regular2sqsh_layers?
- Sqsh_layer maintenance scripts for all the things that require rebooting.
In particular, sqsh-commit (to create new sqsh from upper) and sqsh-merge (to
merge all lower layers into a single sqsh). And actually, maint might make
more sense... since it will have all the layers mounted. Although, if we
want to do a full reboot after re-layering (to ensure the bootloader cfg
changes happens before continuing), that won't work via maint, so initramsys
would be better suited.
Would still have to tackle the "now go update your bootloader config"
dilemma. Should we sed changes into extlinux.conf, syslinux.conf, or
reconfigure grub? Sounds dicey. I suppose printing out a message telling
the user EXACTLY what to go put in their bootloader config is the best
compromise. Or we could *attempt* to find syslinux.conf and sed changes in
there if found, otherwise tell the user what to change? Worst case, they
don't do it, and their system doesn't boot?
Should we add kernel params to do this, too? Like sqsh_layer-commit and
sqsh_layer-merge? Have them auto-run and leave the user with a prompt to
update bootloader config and reboot (if non syslinux), or just go right
ahead and autoreboot after updating syslinux.conf (ha, don't forget to make
sure to remove sqsh_layer-commit and sqsh_layer-merge before rebooting)?
- Can ruckusrd detect a secondary ESP and keep it in sync with the primary?
This wouldn't be as good as automatically making them match after dorking
around with ESP1 (e.g., installing a new kernel, tweaking syslinux.conf),
but it's better than doing nothing and leaving it up to the user (in which
case, they'll never match)
New boot param: redundant-esp=LABEL1,LABEL2,...
* for 0.22
- Add an install_on_zpool script to configure zfs datasets for a sqsh_layer
system. Dialog to pick topmost layer. Crete zpool/root, zpool/sqsh,
zpool/home, and maybe zpool/scrap. Install layers into zpool/sqsh.
Configure syslinux. Configure EFI bootloader. Hmm... how do we detect the
need (i.e., because there's no need inside a Xen PVH domain)? I suppose
efibootmgr failing would do it...
Could include a corresponding boot param to automate the bootup into
installer process. This should run w/out root disk setup, a la initramsys.
Could call it initramsys-installer. Probably actually run as an init script
inside the initramsys embedded system.
If we start automatically, there's no time for user to create a zpool... so
we'll have to ask them to and drop to a shell. Also, we may have to
partition a disk to create ESP (and swap?)
We could also create the requested pool if it doesn't exist... but out of
what? If there's just one disk, it's obvious... Any more than that, and
it's really too complicated to make an educated guess. Shoot, even 1 disk
we have to make assumptions about partitioning (e.g., ESP, swap).
I think we can take either an existing zpool, or a list of drives to make a
pool out of. In that case, we're going to do either single-disk or mirrored
pairs (because anything else for zroot is silly), we can autodetect EFI by
trying to use efibootmgr, partition each disk with ESP, swap, and rest, then
add all the last partitions to the zpool.
initramsys-installer=IMGDEV,...