X-Git-Url: https://git.grml.org/?a=blobdiff_plain;ds=inline;f=faq%2Findex.html.tt2;h=aec2e2d24aaace23fc475d75fe5889295a145465;hb=cf004e597c0433c8f7e77907ef0c61d48b73b3a9;hp=6a40cba4a080ab3cd652d2e89d60a391cb75c878;hpb=cef5477b001d17d652687e2f5f3480d4b5dc17d4;p=grml.org.git diff --git a/faq/index.html.tt2 b/faq/index.html.tt2 index 6a40cba..aec2e2d 100644 --- a/faq/index.html.tt2 +++ b/faq/index.html.tt2 @@ -28,7 +28,7 @@
Up2date: applies to Grml releases version 2013.02
+Up2date: applies to Grml version 2018.12
@@ -42,6 +42,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 +117,17 @@
Codename of Grml 2013.02 is "Grumpy Grinch", well we're getting older.
+Codename of Grml 2017.05 is "Gnackwatschn", which is + an austrian and bavarian word, meaning "hit in the neck". + We consider this an alternative to a facepalm.
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:
+ devices execute (replace "$name" with the name of the PV): + ++# Start lvm2-pvscan@$name ++ +
or if you don't know its name, use:
-# /etc/init.d/lvm2 start +# Start lvm2-lvmetad +# vgchange -ay
If you want to enable LVM by default just boot using the 'lvm' @@ -239,7 +299,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 +342,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).