Re: rfc: growlight as d-i partman replacement
[debian-derivatives dropped from cc] [93sam, pabs added to cc] [0] nick black left as an exercise for the reader: > Christian PERRIER left as an exercise for the reader: > > Quoting nick black (nick.bl...@sprezzatech.com): > > > As said, you can find a growlight udeb in the SprezzOS repositories, > > > where it > > > is actively used in our d-i-derived installer: > > It's quite likely that the first step is then to have growlight in > > main Debian, isn't it? > > Indeed. I will file an ITP. sorry to revive an eight-year-old thread, but there has recently been news on this front =]. you might find a web archive useful for context [1]. growlight (as a deb, not an installer component) was admitted into the archive last year, and shipped today as part of bullsye: https://packages.debian.org/testing/source/growlight. i have been actively maintaining and extending it for the past decade, thought the SprezzOS derivative from which it originated is long defunct. debconf21 allocated twenty minutes to discussing this idea [2], and i thought i'd bring it up here so as not to surprise anyone. my main arguments for why it might be worth looking at include: * features and new technologies are added to growlight as they emerge as a natural part of its post-install development [3], whereas partman presumably requires fresh dev effort for any feature desired in the installer. as an example, creating btrfs aggregates requires some conceptual work, some minimal ui work, and some minimal integration, independent of system installation. growlight would gain this functionality as due course, as disk management is its raison d'être, much more so than it is d-i's. * can present dynamic information about multiple devices simultaneously, and perform most actions in parallel. running e.g. concurrent mkfs operations can be displayed and managed. * partman AFAIK only gets run during installation, not in the course of system administration. it is thus possible that growlight would get more and/or more varied testing. * it's already been built as a udeb and used as a partman component, and proven out in the d-i context (see video proof at [4], admittedly from 2013). so we could just start messing around with it pretty much tomorrow. of course, there are plenty of reasons why a change might be undesirable, and i hope to address many of them in my talk. most concerning to me is preseeding, which i would be very hesitant to either (a) invalidate or (b) recreate. so i hope you all watch the talk! hopefully it won't be a grand waste of everyone's time. --nick [0] sam because he's the current QA contact for partman, paul because he was so active on the derivatives list. [1] https://lists.debian.org/debian-boot/2013/02/msg00122.html [2] https://debconf21.debconf.org/talks/3-proposing-a-new-d-i-disk-preparation-tool-growlight/ [3] https://nick-black.com/dankwiki/index.php/Growlight#Some_capabilities [4] https://nick-black.com/tabpower/growlight-return-of.mp4 -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: rfc: growlight as d-i partman replacement
Christian PERRIER left as an exercise for the reader:
I'd like to followup on your suggestion as it seems well thought and
prepared and not just one idea thrown in the wild as I was initially
thinking (sorry for this).
Thanks for your kind words, christian! i'm still wondering what people think
about installing GRUB to all disks (thus making boots more deterministic (see
my mail to this group of 2012-10-13 [0])), but I think this change would be
more valuable still.
You have well identified the difficulty in abandoning partman. The
main problem is probably that partman is well modular and makes it
easy to throw in some new fliesystem support (it seems this is not
I'd say it's simpler to add a filesystem to growlight's c code than the scripts
of partman, personally (I know I'm sounding kinda like Lennart here, but hey,
SprezzOS uses systemd). Here's the fs dispatch table [1], used for creation,
setting a UUID (where appropriate), and setting a label (where appropriate):
static const struct fs {
const char *name;
const char *desc;
int (*mkfs)(const char *,const struct mkfsmarshal *);
int (*uuidset)(const char *,const unsigned char *);
char nameparam; // parameter on cmdline to name
int namemax;// max length of name, if known
} fss[] = {
{
.name = vfat,
.desc = File Allocation Table (DOS default),
.mkfs = vfat_mkfs,
.namemax = 11,
.nameparam = 'n',
.uuidset = NULL,
},
etc etc. Take a look -- I think you'll find the C very readable.
easy to throw in some new fliesystem support (it seems this is not
as easy as it seems, though, as you ended up in developing something
else for ZFS support).
ZFS is a combination of the block layer and filesystem layer. It was going to
require special cases in most any system. Indeed, it gets a whole (small) file
and device class in growlight [2].
I didn't end up using partman because partman is ugly, partman's source is
ugly, partman seems unusable with a large number of drives (I regularly deal
with 128 drives in a machine), partman didn't have UEFI support at the time,
I found d-i debconf scripts difficult to debug, and I need curved unicode
box characters to live.
It is quite easy, though to push for your proposal : develop growlight
and the udebs it produces in the D-I infrastructure, eventually
As said, you can find a growlight udeb in the SprezzOS repositories, where it
is actively used in our d-i-derived installer:
[skynet](0) $ links2 -dump
https://www.sprezzatech.com/apt/pool/main/g/growlight/
Index of /apt/pool/main/g/growlight
[ICO] NameLastSize
Description
modified
--
[DIR] Parent Directory -
[ ] growlight-udeb_1.0.4.5-SprezzOS2_amd64.udeb 06-Feb-2013 122K 04:26
[ ] growlight_1.0.4.5-SprezzOS2.debian.tar.gz 06-Feb-2013 4.6K 04:26
[ ] growlight_1.0.4.5-SprezzOS2.dsc 06-Feb-2013 2.2K 04:26
[ ] growlight_1.0.4.5-SprezzOS2_amd64.deb 06-Feb-2013 208K 04:26
[ ] growlight_1.0.4.5.orig.tar.xz 06-Feb-2013 388K 04:26
--
Apache/2.2.22 (Debian) Server at www.sprezzatech.com Port 443
[skynet](0) $ dpkg-deb -I growlight-udeb_1.0.4.5-SprezzOS2_amd64.udeb
new debian package, version 2.0.
size 128482 bytes: control archive=1301 bytes.
828 bytes,14 lines control
1092 bytes,39 lines * postinst #!/bin/sh
118 bytes, 4 lines templates
Package: growlight-udeb
Source: growlight
Version: 1.0.4.5-SprezzOS2
Architecture: amd64
Installer-Menu-Item: 4200
Maintainer: Nick Black nick.bl...@sprezzatech.com
Installed-Size: 468
Depends: cdebconf-udeb, hw-detect, md-modules, mdadm-udeb, dmsetup-udeb,
libpci3-udeb, libcryptsetup4-udeb, libatasmart4-udeb, libpciaccess0-udeb,
kbd-udeb, e2fsprogs-udeb, dosfstools-udeb, jfsutils-udeb, xfsprogs-udeb,
ntfs-3g-udeb, btrfs-tools-udeb, hfsutils-udeb, f2fs-tools-udeb, util-linux-udeb
Replaces: grub-installer, lilo-installer, partitioner, partman
Provides: bootable-system, created-fstab, harddrive-detection,
made-filesystems, made-swapspace, mounted-partitions, partitioned-harddrives
Section: debian-installer
Priority: standard
Description: Prepare target
Growlight udeb, unsuitable for installation on normal machines.
[skynet](0) $
Obviously this is not going to land for Wheezy, but it seems that this provides
a pretty decent starting point for the beginning of the next development epoch.
Thanks!
-rigorously, nick
Re: rfc: growlight as d-i partman replacement
Quoting nick black (nick.bl...@sprezzatech.com): As said, you can find a growlight udeb in the SprezzOS repositories, where it is actively used in our d-i-derived installer: It's quite likely that the first step is then to have growlight in main Debian, isn't it? signature.asc Description: Digital signature
Re: rfc: growlight as d-i partman replacement
Christian PERRIER left as an exercise for the reader: Quoting nick black (nick.bl...@sprezzatech.com): As said, you can find a growlight udeb in the SprezzOS repositories, where it is actively used in our d-i-derived installer: It's quite likely that the first step is then to have growlight in main Debian, isn't it? Indeed. I will file an ITP. -- nick black http://www.sprezzatech.com -- unix and hpc consulting to make an apple pie from scratch, you need first invent a universe. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130207232436.ga12...@qemfd.net
Re: rfc: growlight as d-i partman replacement
Karl Goetz left as an exercise for the reader: How will this go for ports, non x86 and non linux? non-x86: there's no x86-specific code in growlight. if all the libraries are available, everything should be fine. will need to support setting up bootloaders on those architectures if they don't use GRUB/efistub. non-linux: would need some work to implement some kernel-specific stuff, but that's all stuff that partman currently does not provide. i'm primarily thinking here: - inotify (implementable in terms of freebsd's EVFILT_VNODE - sysfs records used to determine rotation speed - sysfs records used to determine physical sector size - ioctl's used to inform kernel of partition table changes not all filesystems will be available and there might be some extra filesystems. I don't know anything about hurd, and can't really answer you there. I'm pretty familiar with freebsd, and think porting will not be very difficult. I've added a bug on this: https://www.sprezzatech.com/bugs/show_bug.cgi?id=628 Thanks for pointing this out! -- nick black http://www.sprezzatech.com -- unix and hpc consulting to make an apple pie from scratch, you need first invent a universe. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130208014450.ga13...@qemfd.net
Re: rfc: growlight as d-i partman replacement
Quoting nick black (nick.bl...@sprezzatech.com): Hello! Last summer, I was hoping to add ZFS support to the Debian installer. After playing around with partman a week or two, I ended up developing an entirely new application, growlight [0]. It is currently used in the SprezzOS installer [1], and has been used by a small, ZoL-intensive user base for several months (since ZoL 0.6.0-rc11 days). It has had open bugtracking [2] and git-based source control [3] since its first commit. .../... I'd like to followup on your suggestion as it seems well thought and prepared and not just one idea thrown in the wild as I was initially thinking (sorry for this). It would thus be a shame that you don't get any followup, whic hwould be likely to happen. You have well identified the difficulty in abandoning partman. The main problem is probably that partman is well modular and makes it easy to throw in some new fliesystem support (it seems this is not as easy as it seems, though, as you ended up in developing something else for ZFS support). It is quite easy, though to push for your proposal : develop growlight and the udebs it produces in the D-I infrastructure, eventually provide D-I images that use it instead of partmanand we'll see if people adhere to it. After all, the modular structure of D-I makes it easy to replace one component by another. However, given that most of what remains of the D-I team is now focused on the wheezy release, it is likely that you do'nt get much feedback in the beginning. But, eh, this is about all what we have to propose, I guess..:-) signature.asc Description: Digital signature
