GRMLCFG working on 2008.11?
Hello,
I started the grml 2008.11 ISO image in a virtual machine (VirtualBox 2.1.12 on OSX 10.5), which had a 5 GB hard disk. I partitioned the hard disk, and labelled one partition GRMLCFG (obviously after formatting it ;-) ). After restarting I mounted the image, and used
save-config -all
to created a file called config.tbz on that partition.
It seems to me that when booting something from that partition is copied (long list of files), but neither the language setting nor the network settings are restored. Is this normal? Should those settings be stored, or are they excluded? As far as I understood the docu the whole /etc should be saved.
During saving the config, I get errors the first time I run save-config, saying that file xyz changed during reading. Disappears the second time you run save-config.
Any hints? Tricks? Bugs?
Regards, OJ P.S.: If this message appears twice, then posting via gmane *does* work...
[Sorry for the long delay in answering your mail. When digging through my mailbox I noticed nobody answered your mail.]
* Johannes Kastl ojkastl@gmx.de [20090213 15:49]:
I started the grml 2008.11 ISO image in a virtual machine (VirtualBox 2.1.12 on OSX 10.5), which had a 5 GB hard disk. I partitioned the hard disk, and labelled one partition GRMLCFG (obviously after formatting it ;-) ). After restarting I mounted the image, and used
save-config -all
to created a file called config.tbz on that partition.
It seems to me that when booting something from that partition is copied (long list of files), but neither the language setting nor the network settings are restored. Is this normal? Should those settings be stored, or are they excluded? As far as I understood the docu the whole /etc should be saved.
This is a known limitation because GRMLCFG is used too late in the bootprocess for some stuff like language settings. I forwarded this issues to our bug tracking system:
http://bts.grml.org/grml/issue628 http://bts.grml.org/grml/issue629
During saving the config, I get errors the first time I run save-config, saying that file xyz changed during reading. Disappears the second time you run save-config.
Thanks for reporting. GNU tar sucks BTW. ;) Anyway, should be fixed with grml-saveconfig version >=0.2.7.
P.S.: If this message appears twice, then posting via gmane *does* work...
Yeah it does :)
regards, -mika-
On 3/13/09 12:39 AM Michael Prokop wrote:
[Sorry for the long delay in answering your mail. When digging through my mailbox I noticed nobody answered your mail.]
No problem.
This is a known limitation because GRMLCFG is used too late in the bootprocess for some stuff like language settings. I forwarded this issues to our bug tracking system:
Maybe one could workaround the network by just stopping and restarting the network interfaces?
Regards, OJ
* Johannes Kastl ojkastl@gmx.de [20090314 17:16]:
On 3/13/09 12:39 AM Michael Prokop wrote:
This is a known limitation because GRMLCFG is used too late in the bootprocess for some stuff like language settings. I forwarded this issues to our bug tracking system:
Maybe one could workaround the network by just stopping and restarting the network interfaces?
Well, grml uses pump as dhcp-client for every existing network interface (by default, can be disabled using the nodhcp bootoption). The main reason for this is that it's faster to just invoke pump for each interface in the background than setting up /etc/network/interfaces and/or invoking dhclient. The timing is important because when booting grml finished people expect to have a working network setup (if DHCP is available in the network). If they can't access the network stright after booting they might think that something is broken because the network doesn't work yet - even though it's usually just a slow DHCP server. ;)
What would work is booting with bootoption nodhcp, setup /etc/network/interfaces via GRMLCFG and provide a simple grml.sh script on the GRMLCFG device which just executes '/etc/init.d/networking restart'.
I'm thinking about moving the GRMLCFG stuff from the end of the bootprocess to the beginning. Nowadays thanks to udev we have most relevant parts of the hardware recognition stuff available soon after init(8) is invoked. Just LVM and SW-RAID might be possible showstoppers for some GRMLCFG users, though supporting them through something like /etc/init.d/bootlocal.last would be possible anyway. And the benefit of the reording could be possible checks in the bootprocess whether network interfaces are already set up and skip invocation of pump then.
regards, -mika-
participants (2)
-
Johannes Kastl -
Michael Prokop