Up2date: applies to Grml version 2013.09
+Up2date: applies to Grml version 2020.06
@@ -42,6 +41,7 @@Unless you've a good reason to really choose the 32bit flavour we - strongly encourage you to use either the grml64 or the grml96 + strongly encourage you to use either the grml64 or the grml96 flavour.
-Please notice that this schema was introduced starting with the - downsized Grml release 2011.12. Until then grml96 didn't exist and - grml32 was known as just 'grml'.
-grml-small provides a reduced set of available software compared to @@ -120,15 +116,16 @@
Codename of Grml 2013.09 is "Hefeknuddler", well we like beer.
+Codename of Grml 2020.06 is "Ausgehfuahangl", which is + an austrian word for a face mask.
The switch from file-rc to systemd happened for various reasons. + Grml used file-rc for many years, mainly because it provided a better + way to control startup behavior via its /etc/runlevel.conf configuration + than with using sysvinit. Though for us Grml developers this also meant + that whenever there have been any changes in Debian's startup + configuration we had to compare our /etc/runlevel.conf setup with what a + normal Debian system would give us. Users who wanted to remaster Grml + with a custom startup procedure as well had to practically fork + maintenance of the /etc/runlevel.conf file. This didn't only mean + tracking new features/services, but also solve any possible issues + around it - duplicating efforts and wasting developers time + unnecessarily. Lately we also started to see problems that no one else + seemed to have (or care about enough), for example with multiple network + cards we ran into race-conditions with resolvconf. Problems like that + turned out to be release stoppers for us.
+ +systemd on the other hand provides great documentation, service + supervision, takes care of parallel service startup and is the default + init system on most Linux distributions nowadays. This means more users, + better testing and integration. Logging, startup time investigation (to + get a fast boot procedure) and identifying failed service startups with + sysvinit/file-rc was always hard, unreliable or even impossible under + certain conditions. bootlogd was unreliable (while `journalctl -b` is + available out-of-the-box with systemd), bootchart not nicely integrated + (while systemd-analyze blame/critical-chain works out-of-the-box) and we + aren't aware of any equivalence for e.g. `systemctl --failed`.
+ +While migrating our stack to systemd is not fully finished + yet, its switch - at least so far - was easier than expected. It also + turns out that it gives users who want to remaster Grml (or build their + very own ISOs from scratch using grml-live) more flexibility and control + over the startup process. systemd's override.conf mechanism and preset + feature provides the flexibility to overwrite unwanted behavior, without + losing the option to use existing defaults.
+ +Last but not least we think it's good that systemd is actively + maintained and receives attention. The sysvinit/file-rc ecosystem was + stagnating/non-existend for too many years. Grml used its own initrd + implementation in its very beginnings, until a more broadly available + initramfs-tools/ live-boot solution appeared, broadening the user base, + sharing goals amongst different (live) distributions. Back in the days + Grml - like many other live distributions - had to implement hardware + recognition on its own. While udev received lots of complaints back + then, its integration actually solved all the hardware recognition for + the good. systemd's vision of stateless systems is something which helps + building live systems like Grml.
+ +While we don't claim that systemd is perfect and doesn't have its + issues and drawbacks (like any software), we're happy about its + existence and more than happy about development and support by Debian's + systemd folks.
+LVM (Logival Volumes) is not started by default to - avoid any possible damage to your data. To get access to present LVM - devices just execute:
+ avoid any possible damage to your data. To activate present LVM + devices execute (replace "$name" with the name of the PV): + ++# Start lvm2-pvscan@$name ++ +
or if you don't know its name and to enable all present ones, use:
-# /etc/init.d/lvm2 start +# vgchange -ay
If you want to enable LVM by default just boot using the 'lvm' @@ -239,7 +296,7 @@ grml keyboard=de xkeyboard=de lang=at # enter this at the bootprompt your data. To get access to present SW-RAID devices just execute:
-# /etc/init.d/mdadm-raid start +# mdadm --asssemble --scan
If you want to enable SW-RAID by default just boot using @@ -282,13 +339,12 @@ grml keyboard=de xkeyboard=de lang=at # enter this at the bootprompt
Available bootoptions relevant in live-cd mode:
+Available bootoptions relevant in live mode:
Further information: manpages hwclock(8), tzselect(1) and tzconfig(8); Is it possible to install Grml to harddisk? -
Short anwer: No.
- -If you want to get a plain Debian system take a look at grml-debootstrap.
- -Long(er) answer: yes it's possible to install Grml. But it's not - supported and you'll be on your own. That's why we decided to make it - not-so-obvious. If you really know what you're doing you'll find out on - your own. Reminder: use grml-debootstrap or Debian Installer instead.
+No. If you want to get a Debian system take a look at grml-debootstrap (or use the Debian Installer instead).
You want to deploy Grml in your data center, use it as part of your business or have an emergency case? You're happy with Grml but would - like to get your very own live cd (providing your favourite software - selection, special configuration, setup and your bootsplash)? + like to get your very own live system (providing your favourite software + selection, special configuration, setup and a custom bootsplash)? Please get in touch with us.
