<h1 align="center">FAQ for grml</h1>
- <p><strong>Up2date:</strong> applies to Grml version 2014.11</p>
+ <p><strong>Up2date:</strong> applies to Grml version 2018.12</p>
<p><a name="toc"></a><strong>Index:</strong></p>
<li><a href="#releasename">What about the release name?</a></li>
<li><a href="#requirements">Requirements for running Grml</a></li>
<li><a href="#bootoptions">Which bootoptions does Grml support?</a></li>
+ <li><a href="#systemd">Why is Grml using systemd?</a></li>
<li><a href="#known_issues">Are there any known issues with this release? How about reporting bugs?</a></li>
</ol>
<h3><a name="flavours"></a><a href="#toc">What are grml32 / grml64 and grml96?</a></h3>
<ul>
- <li>grml32-full: 32bit version (kernel and userspace), ~350MB</li>
- <li>grml64-full: 64bit version (kernel and userspace), ~350MB</li>
- <li>grml96-full: multi boot version (featuring the grml32-full and grml64-full ISOs combined on one ISO), ~700MB</li>
+ <li>grml32-full: 32bit version (kernel and userspace)</li>
+ <li>grml64-full: 64bit version (kernel and userspace)</li>
+ <li>grml96-full: multi boot version (featuring the grml32-full and grml64-full ISOs combined on one ISO)</li>
</ul>
<p>Unless you've a good reason to really choose the 32bit flavour we
- strongly encourage you to use either the grml64 or the grml96
+ <em>strongly</em> encourage you to use either the grml64 or the grml96
flavour.</p>
- <p>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'.</p>
-
<h3><a name="grmlsmall"></a><a href="#toc">What is the difference between grml-full and grml-small?</a></h3>
<p>grml-small provides a reduced set of available software compared to
<h3><a name="releasename"></a><a href="#toc">What about the release name?</a></h3>
- <p>Codename of Grml 2014.11 is "Gschistigschasti", which is colloquial for 'fuss' in Austria.</p>
+ <p>Codename of Grml 2018.12 is "Gnackwatschn", which is
+ an austrian and bavarian word, meaning "hit in the neck".
+ We consider this an alternative to a facepalm.
<h3><a name="requirements"></a><a href="#toc">Requirements for running Grml</a></h3>
<ul>
- <li>Intel-compatible CPU (i586 or later, preferably Pentium class or higher)</li>
+ <li>Intel-compatible CPU (i686 or later, preferably Pentium class or higher; although some i586 processors e.g. the 'AMD Geode' are still supported)</li>
- <li>>=256MB of RAM (>=512MB recommended)</p>
+ <li>>=384MB of RAM (>=512MB recommended)</p>
<li>either a bootable CD-/DVD-ROM drive,
a <a href="#usbboot">USB-boot capable system</a> or a
href="http://git.grml.org/?p=grml-live.git;a=blob_plain;f=templates/GRML/grml-cheatcodes.txt;hb=HEAD">grml-cheatcodes
file</a> (also available via <a href="http://grml.org/cheatcodes/">grml.org/cheatcodes/</a>). Of
course <a
- href="http://www.kernel.org/doc/Documentation/kernel-parameters.txt">kernel-parameters.txt</a>
+ href="https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html">the command-line parameters</a>
of the Linux kernel applies to Grml as well.</p>
+ <h3><a name="systemd"></a><a href="#toc">Why is Grml using systemd?</a></h3>
+
+ <p>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.</p>
+
+ <p>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`.</p>
+
+ <p>While migrating our stack to systemd is <em>not</em> 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.</p>
+
+ <p>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.</p>
+
+ <p>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.</p>
+
<a name="release"></a> <!-- old anchor -->
<a name="bugreport"></a> <!-- old anchor -->
<h3><a name="known_issues"></a><a href="#toc">Are there any known issues? How about reporting bugs?</a></h3>
<p>LVM (Logival Volumes) is <strong>not</strong> started by default to
avoid any possible damage to your data. To get access to present LVM
- devices just execute:</p>
+ devices execute (replace "$name" with the name of the PV):</p>
+
+<pre class="rahmen">
+# Start lvm2-pvscan@$name
+</pre>
+
+ <p>or if you don't know its name, use:</p>
<pre class="rahmen">
-# /etc/init.d/lvm2 start
+# Start lvm2-lvmetad
+# vgchange -ay
</pre>
<p>If you want to enable LVM by default just boot using the 'lvm'
your data. To get access to present SW-RAID devices just execute:</p>
<pre class="rahmen">
-# /etc/init.d/mdadm-raid start
+# mdadm --asssemble --scan
</pre>
<p>If you want to enable SW-RAID by default just boot using
<h3><a name="timezone"></a><a href="#toc">How do I configure
timezone on my Grml system?</a></h3>
- <p>Available bootoptions relevant in live-cd mode:</p>
+ <p>Available bootoptions relevant in live mode:</p>
<ul>
- <li>utc: set UTC, if your system clock is set to UTC (GMT)
- <li>gmt: set UTC, if your system clock is set to UTC (GMT) [like bootoption utc]
- <li>tz=$option: set timezone to corresponding $option, usage example:
- tz=Europe/Vienna
+ <li>utc: set UTC, if your system/hardware clock is set to UTC (Coordinated Universal Time)
+ <li>localtime: Hardware Clock is set to local time (LOCAL), this is the default
+ <li>tz=$option: set timezone to corresponding $option, usage example: tz=Europe/Vienna, defaults to UTC if unset
</ul>
<p>Further information: manpages hwclock(8), tzselect(1) and tzconfig(8); <a
<h3><a name="hdinstall"></a><a href="#toc">Is it possible to install Grml to harddisk?</a></h3>
- <p>Short anwer: No.</p>
-
- <p>If you want to get a plain Debian system take a look at <a
- href="/grml-debootstrap/">grml-debootstrap</a>.</p>
-
- <p>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 <a
- href="/grml-debootstrap/">grml-debootstrap</a> or <a
- href="http://www.debian.org/">Debian Installer</a> instead.</p>
+ <p>No. If you want to get a Debian system take a look at <a
+ href="/grml-debootstrap/">grml-debootstrap</a> (or use the <a
+ href="https://www.debian.org/">Debian Installer</a> instead).</p>
<h2><a name="software"></a><a href="#toc">Software</a></h2>
projects / grml.org.git / blobdiff