* Marc Haber mh+grml-devel@zugschlus.de [120102 11:35]:
On Mon, Jan 02, 2012 at 01:22:21AM +0100, Christian Hofstaedtler wrote:
- Marc Haber mh+grml-devel@zugschlus.de [120101 23:45]:
On Sun, Jan 01, 2012 at 11:10:40PM +0100, Ulrich Dangel wrote:
- Marc Haber wrote [01.01.12 22:33]:
Loading an 350 MB image to RAM takes considerably more time than an 130 MB image.
You can load the image into ram after you started it via the command grml2ram. This means you can copy it to ram while already working.
Nice idea. How about an option to copy to ram in the background?
What do I do on old systems that only have 512 MB RAM?
Use an old release.
With old security-bugs? I don't like that idea at all.
I obviously don't understand your use case.
I thought this was about having an arch-specific Grml ISO in /boot for rescue purposes.
Where about the only things that matter are kernel and ssh. Both have been unpatched for the time since the last release anyway, which was up to 6+ months, depending on the release, and how often you update your ISOs.
Where there have been no such grave bugs in these software pieces in the past, that this was completely acceptable to everyone.
Additionally, on my typically 1 GB large boot, I was able to place to grml-small images in addition to the normal /bot contents. I was already forced to resize /boot on my notebook because of grmls size increase.
As i said before you can place the grml iso images on a dedicated LVM lv or on raid and use that for mounting the isos. Stacked setups will work also (LVM on raid)
That doesn't help too much for systems that are already installed.
1GB is enough for kernels, initrds and Grml.
Are you aware how big kernel debug infos are?
Installing linux-image-3.1.0-1-amd64-dbg did not change the size of /boot for me. I keep an old grml64 (full, so 700M) in /boot, and total size is <750M.
-ch