Package: restore-config Severity: wishlist
Hi, Mika:
First of all, thanks for your hard works that releases grml 0.9-7, and grml-small 0.3-2 recently.
I hope the following minor enhancements to the grml configuration system can make into the 1.0 release.
- support reading configuration files from NTFS partitions. Don't know if it already possible, just list it here first.
- myconfig=scan. I know by default the booting process tries to mount a device labeled GRMLCFG, and do configuration from there.
The problem is that, in nowadays window$ world, the cooperate policy will most often prevent me from change my own disk label. You won't believe it, nowadays window$ world is so dummy-proof that in many places I can't even change my window$ desktop settings.
So I need another automatic way to specify the grml configuration device.
- Boot-Options config.d, i.e., please define a grml configuration directory. On booting all the .tbz files from within the defined directory or from the config.d option, will be restored, in the order by their names.
The save-config generated configuration, the plain bzip2 compressed tar archives is a good thing. But I don't like the fact that all related or unrelated files are all stuffed into this same file. I hope that I can group related files into different .tbz files. It is much more easy to manage than a single file.
- Boot-Options scripts.d, same concept as config.d, for scripts.
- persistentroot. I don't know how comfortable you are about the union fs now, but I still think that a partition or a loopback device as a persistent root, i.e., not only persistent home, is a good idea.
To tell the truth, ever since installing grml 0.7 onto my HD, I didn't use/test the new grml iso files any more. Because I've put so much time & effort configuring the installed grml, that I don't want to waste my time again for a new iso versions. With persistentroot, the journey migrating to newer versions of grml can be a bit smoother.
Moreover, having a persistentroot can put the automatic installation of debian packages (from directory named debs) into real use, because I think the amount of debian packages that can be automatic installed is limited by ram space.
These are all small changes that will have big impacts. Much more flexibilities can be achieved by doing so.
Thanks
Tong
-- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (50, 'unstable'), (30, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-grml Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)