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)
