{{Header}}
{{Title|title=
grub-live - boot an existing Host OS or VM into Live Mode
}}
{{#seo:
|description=Add a Live Mode entry to the grub boot menu on your existing Debian host platform. Stop Persistent Malware. Read-only mode. Make all writes go to non-persistent storage (RAM) instead of the hard disk.
|image=Live-mode-promo.jpg
}}
{{live}}
[[File:Live-mode-promo.jpg|thumb]]
{{intro|
The grub-live package offers an additional "LIVE mode" boot menu entry for the [https://www.gnu.org/software/grub/ GNU GRUB boot loader].

This package is compatible with many Linux distributions, including Debian and Ubuntu. In {{project_name_long}} and {{Whonix}} it is installed by default. Grub-live can be applied for a host {{os}} as well as for a guest OS on a virtual machine.
}}
[[image:Grub-live_mode_indicator_in_debian.cleaned.png|thumb|Debian Live Mode Boot ([[Live Mode]])]]

[[image:Grub-live mode indicator in kicksecure.cleaned.png|thumb|[[Kicksecure|{{project_name_short}}]] Live Mode Boot ([[Live Mode]])]]

[[image:live_boot.png|Live Mode Boot|thumb|[[Whonix|{{Whonix}}]] Live Mode Boot ([[Live Mode]])]]

= Compatibility =

grub-live is compatible and tested with '''Debian, Kicksecure and Whonix'''. In Kicksecure and Whonix it is installed by default. It should also without any problems run on Ubuntu and other Linux distributions which implement Debian live boot. But due to little user adoption and testing at this point in time grub-live for those distributions is still labelled [[untested]].

= Installation / Getting started =

The grub-live package is hosted under the [https://github.com/{{project_name_short}}/grub-live grub-live GitHub repository]. There you will also find the '''installation guide'''.

After the installation you can instantly use the Live Mode in your operating system. Simply boot/reboot your system and choose the new "LIVE mode" option in the boot menu. For {{project_name_long}} specifically read: [[Live_Mode|Detaillled documentation for using the live mode for {{project_name_long}}]].

{{Anchor|grub-default-live}}
= Set grub-live as Default in GRUB boot menu =
Optional.

If you have installed grub-live and you want the "LIVE mode" option to be the default selected option in your grub menu please follow the instructions below. Be aware however that due to little user adoption and testing yet this options is still labelled '''[[untested]]'''.

<span class="fontsize19">1. Do a grub-live package installation check</span>

By default the <code>grub-live</code> package is installed in {{project_name_short}}. If you boot your system and a boot menu entry "LIVE mode" is already avaialble, then <code>grub-live</code> is already installed.

Alternatively you can make sure the package [https://github.com/{{project_name_short}}/grub-live <code>grub-live</code> package] is installed. The following command can be used to check on the command line if the package is already installed by default.

{{CodeSelect|code=
dpkg -l {{!}} grep grub-live
}}

<span class="fontsize19">2. Set LIVE mode as default boot menu entry</span>

There are 2 ways to accomplish this. Choose one ot these options

'''Option (A) -  symlink method'''

* Advantage: This is easier because updates to [[grub-live]] will be automatically applied.
* Disadvantage: There will be a duplicate live boot menu entry.
* Copy and execute the following command

{{CodeSelect|code=
sudo ln -s /etc/grub.d/11_linux_live /etc/grub.d/09_linux_live
}}

'''Option (B) - moving method'''

* Advantage: No duplicate live boot menu entry.
* Disadvantage: Updates to [[grub-live]] will '''NOT''' be automatically applied.
* Copy and execute the following command

{{CodeSelect|code=
sudo mv /etc/grub.d/11_linux_live /etc/grub.d/09_linux_live
}}

<span class="fontsize19">3. Re-generate grub boot menu</span>

The grub boot menu needs to be regenerated for the changes to be applied. Copy and execute the following command

{{CodeSelect|code=
sudo update-grub
}}

<span class="fontsize19">4. DONE</span>

The process of changing from "live mode opt-in through boot grub menu" to "live boot by default" has been completed.

<span class="fontsize19">5. Updates</span>

If in step 2 "option (B)" was chosen then this process might need to be repeated from time to time if there have been updates to GRUB or to your system. The need to repeat this process from step 1 to step 4 will be indicated as soon as the "LIVE mode" entry will not be the default entry in the GRUB boot menu anymore.

If in step 3 "option (A)" was chosen then this step is not needed. Updates will be applied automatically.

= Get GRUB to remember your last choice (e. g. Live mode) =
Optional.

If you don't want to set Live Mode as your permanent default boot option but still want the comfort of having GRUB remember your last choice, e. g. "Live mode", then follow these instructions. <ref>
Based on [https://askubuntu.com/a/149572 this askubuntu answer].
</ref>

'''1.''' {{Open with root rights|filename=
/etc/default/grub.d/50_user.conf
}}

'''2.''' Now add those two lines to this file: {{CodeSelect|inline=true|code=
GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=true
}}

'''3.''' Finally execute this command: {{CodeSelect|inline=true|code=
sudo update-grub
}}

'''4.''' Done.

Your boot menu now remembers your last choice.

= Alternative to grub-live =

As an alternative to grub-live it is also possible to automatically detect
if the disk is set to read-only and enable live mode automatically using the
<code>ro-mode-init</code> package. Read
[[VM_Live_Mode/ro-mode-init|VM Live Mode - Alternative ro-mode-init Configuration]]
for further instructions.

<code>ro-mode-init</code> is currently less tested than <code>grub-live</code>.

= Comparison between grub-live and Tails =

Tails is its own operating system whereas grub-live is a package enabling Live Mode on different Linux distributions. The following table will show advantages and disadvantages of grub-live in regard to Tails. It shall be noted however that whereas Tails is optimized in regard to Live mode grub-live is vastly more compatible with other systems.

'''Table:''' ''Comparison of grub-live and Tails''

{| class="wikitable" style="text-align: center; background-color: #fff"
|- style="background-color: #f9f9f9"
! style="height: 35px"| '''Aspect'''
! '''grub-live on the host''' <ref>Meaning, <code>grub-live</code> outside of a virtual machine. For <code>grub-live</code> in a VM, see [[Live Mode]].</ref> /<br />'''grub-default-live on the host'''
! '''Tails DVD only'''
! '''Tails USB / DVD, with persistent USB'''
! '''Tails read-only medium and other devices with write capability unplugged''' <ref>Assuming Tails on a DVD which can only be written to once, not DVD-RW.</ref> <ref>Or using Tails USB with a physical, active, and effective (non-circumventable by software) write protection switch enabled.</ref>
|-

! Common <ref>As in a substantial user group willing and able to do this.</ref> mode of operation
| {{Yes}}
| {{Yes}}
| {{Yes}}
| {{No}} <ref>This would be a prudent approach but search engines indicate that no or very few users run this configuration.</ref>
|-

! Amnesic / protects against disk modifications <ref>Excluding malware compromise.</ref>
| {{Yes}}
| {{Yes}}
| {{Yes}}
| {{Yes}}
|-

! Protects against malware persistence on hard drive after malware compromise
| {{No}} <ref name=targeted_persistent_malware>Once targeted malware is active it can circumvent read-only settings, mount the harddrive, and add malware which becomes active after next boot.</ref>
| {{No}} <ref name=targeted_persistent_malware />
| {{No}} <ref name=targeted_persistent_malware />
| {{Yes}} <ref name=targeted_persistent_malware />
|-

! Protects against [[Malware_and_Firmware_Trojans#Firmware_Trojans|firmware trojans]] after malware compromise
| {{No}} <ref name=targeted_persistent_malware>Once targeted malware is active it can circumvent read-only settings, mount the harddrive, and add malware which becomes active after next boot.</ref>
| {{No}} <ref name=targeted_persistent_malware />
| {{No}} <ref name=targeted_persistent_malware />
| {{No}} <ref name=targeted_persistent_malware />
|-

! Avoid writing to arbitrary (non-boot) host disks
| ?
| {{Yes}} <ref name=tails-avoid-host-disk-usage>
Quote https://tails.boum.org/contribute/design/

<blockquote>
Tails takes care not to use any filesystem that might exist on the host machine hard drive, unless explicitly told to do so by the user. The Debian Live persistence feature is disabled by passing <code>nopersistence</code> over the kernel command line to live-boot.
</blockquote>
</ref>
| {{Yes}} <ref name=tails-avoid-host-disk-usage />
| {{Yes}} <ref name=tails-avoid-host-disk-usage />
|-

! Disables removable drives auto-mounting
| {{No}}
| {{Yes}} <ref name=tails-disables-removable-drives-auto-mounting>
Quote https://tails.boum.org/contribute/design/#index39h3

<blockquote>
Removable drives auto-mounting is disabled in Tails 0.7 and newer.

https://gitlab.tails.boum.org/tails/tails/-/blob/master/config/chroot_local-includes/etc/dconf/db/local.d/00_Tails_defaults</blockquote></ref> <ref>
https://gitlab.tails.boum.org/tails/tails/-/blob/master/config/chroot_local-includes/etc/dconf/db/local.d/00_Tails_defaults contains a configuration for GNOME only. This is reasonable in the Tails context since its default desktop is GNOME and others are unsupported.
</ref>
| {{Yes}} <ref name=tails-disables-removable-drives-auto-mounting />
| {{Yes}} <ref name=tails-disables-removable-drives-auto-mounting />
|-

! Disables swap
| ?
| {{Yes}}
| {{Yes}}
| {{Yes}}
|-

! Disabled virtual machine shared folders
| {{No}} <ref>
Considered a feature or bug?
</ref>
| ?
| ?
| ?
|-

! Wipe RAM on shutdown
| {{No}}, but see [[ram-wipe]]. <ref>
* https://forums.whonix.org/t/is-ram-wipe-possible-inside-whonix/5596
* https://github.com/QubesOS/qubes-issues/issues/1562

Then a meta package <code>amnesia</code> could depend on both <code>grub-live</code> and <code>wiperam</code> to simplify live boot for users.
</ref>
| Yes, but with limitations. <ref name=tails_wipe_ram>https://tails.boum.org/contribute/design/memory_erasure/</ref>
| Yes, but with limitations. <ref name=tails_wipe_ram />
| Yes, but with limitations. <ref name=tails_wipe_ram />
|-

! Wipe video RAM on shutdown
| {{No}} <ref>
https://github.com/QubesOS/qubes-issues/issues/1563
</ref>
| {{No}} <ref name=tails-wipe-video-ram>https://gitlab.tails.boum.org/tails/tails/-/issues/5356</ref>
| {{No}} <ref name=tails-wipe-video-ram />
| {{No}} <ref name=tails-wipe-video-ram />
|-

! Emergency shutdown on USB removal
| {{No}}
| {{Yes}}
| {{Yes}}
| {{Yes}}
|-

! Live Mode Usability <ref>The user being aware of currently running in live mode vs persistent mode.</ref>
| style="background-color: {{Yellow}}"| Average <ref>
Without Live Mode Indicator (see below) it is not obvious to the user if they booted into persistent or live mode. This might lead to a mistake where live boot is not selected from the grub boot menu (persistent mode is instead set), but the user believes otherwise.
</ref>
| style="background-color: {{Green}}"| Good <ref name=tails-amnesia-usability>Consistently good because amnesia has always has been a core Tails feature. It is obvious to the user that nothing persists except folders that have selective persistence enabled.</ref>
| style="background-color: {{Green}}"| Good <ref name=tails-amnesia-usability />
| style="background-color: {{Green}}"| Good <ref name=tails-amnesia-usability />
|-

! Live Mode Indicator
| style="background-color: {{Yellow}}"| For Xfce only. <ref>
https://github.com/{{project_name_short}}/desktop-config-dist
</ref>
| style="background-color: {{Green}}"| Unneeded
| style="background-color: {{Green}}"| Unneeded
| style="background-color: {{Green}}"| Unneeded
|-

! Unified Amnesic + Anonymous User Experience
| {{No}} <ref>{{project_name_short}} is primarily run inside virtualizers. <code>grub-live</code> is an extra configuration step on the user's host.</ref>
| {{Yes}}
| {{Yes}}
| {{Yes}}
|-

! Easy standard ("everyday") upgrades <ref name=using-apt>Using standard package managers such as <code>apt</code>.</ref>
| {{Yes}}
| ?
| ?
| ?
|-

! [[Release Upgrade|Release upgrades]] <ref>Such as from Debian <code>stretch</code> to Debian <code>buster</code>.</ref> possible anytime  <ref name=using-apt />
| {{Yes}}
| {{No}} <ref name=tails-release-upgrade>Release upgrade of Tails from lets say Debian <code>stretch</code> to Debian <code>buster</code> is a non-trivial development effort. See also: https://tails.boum.org/doc/upgrade/</ref>
| {{No}} <ref name=tails-release-upgrade />
| {{No}} <ref name=tails-release-upgrade />
|-

! Live boot by default
|
* grub-live: <span style="background:{{Red}}">No</span> <ref name=grub-live-persistent-default>Persistent boot is the default option in grub boot menu.</ref>
* grub-default-live: <span style="background:{{Green}}">Yes</span>
| {{Yes}}
| {{Yes}}
| {{Yes}}
|-

! Persistent boot by default
|
* grub-live: <span style="background:{{Green}}">Yes</span> <ref name=grub-live-persistent-default>Persistent boot is the default option in grub boot menu.</ref>
* grub-default-live: <span style="background:{{Red}}">No</span>
| {{No}}
| {{No}}
| {{No}}
|-

! Full disk encryption compatibility
| {{Yes}}
| {{No}}
| {{No}}
| {{No}}
|-

! Encrypted persistence supported
| {{Yes}}
| {{Yes}} <ref name=tails-encrypted-persistence>https://tails.net/doc/persistent_storage/index.en.html</ref>
| {{Yes}} <ref name=tails-encrypted-persistence />
| {{Yes}} <ref name=tails-encrypted-persistence />
|-

|}

= Security Considerations =
How secure and reliable is any live mode?

Computers typically default to data persistence rather than amnesia. Coupled with widespread computer security vulnerabilities (see [[Dev/About_Computer_(In)Security|About Computer (In)Security]]), implementing a secure system is challenging.

<code>grub-live</code> is relatively straightforward. It primarily involves installing necessary dependencies and setting kernel parameters (details in [[#Implementation|Implementation]]). However, the software it is based on, such as <code>dracut</code> (or <code>initramfs-tools</code>/Debian's <code>live-tools</code>), mount, overlayfs are complex. Sparse developer documentation in this area makes this difficult. There is also an increased risk of failures post [[Release Upgrade]] or after installing new major versions of {{project_name_short}} or Debian, due to the [[unspecific|generic nature of the solution]].

There is a potential risk that [[malware]] could [[#remount|remount]] a read-only disk as read-write. While no confirmed cases exist, theoretically, even legitimate software could inadvertently perform such actions. To mitigate this risk, it's advisable to use grub-live in conjunction with a physical read-only mode for hard drives, where feasible. See [[read-only]].

Using grub-live on the host operating system, combined with virtual machines (VMs), is a safer configuration. In this setup, any disk remounting as read-write within a VM would be negated upon rebooting the host. VMs, in this context, are unaware of the host's live mode status and cannot directly alter it.

Would using an [[ISO]] image be safer? Generally, yes. Because ISOs commonly aren't modified. It seems unlikely that an ISO would be inadvertently remounted as read-write, unless targeted specifically by malware.

Tools like <code>growisofs</code> can append data to an ISO, it's more complex than a simple remount command. Even without <code>growisofs</code>, Malware could potentially [https://wiki.debian.org/RepackBootableISO repack] and rewrite an ISO, but it is an even more complicated process. Not something that can happen by accident.

What about read-only media, like a DVD-R (not DVD-RW)? This is indeed a safer option, but less practical. It requires burning the DVD, then using it in a read-only DVD reader, which is not a common practice. Such devices are not popular anymore nowadays.

Combining physical write protection switches with grub-live would further enhance security. However, even this is not foolproof due to potential hardware vulnerabilities or defects. Thus, it should be considered an additional layer of defense rather than a complete solution.

Reflecting on these aspects, we can categorize security configurations from least to most secure, as follows:

Notes:

* This list, created in December 2023, might have minor inaccuracies but generally represents the correct security hierarchy.
* ISO HDD: It is possible to boot an ISO located on the hard drive. This is unspecific to Kicksecure and out of scope for this documentation.

# VM live mode HDD boot without read-only VM HDD ("least secure")
# VM live mode HDD boot with read-only VM hard drive
# VM live mode ISO boot without VM HDDs connected
# host live mode HDD without read-only HDD
# host live mode HDD without read-only HDD + using VMs
# host live mode HDD with read-only HDD
# host live mode HDD with read-only HDD + using VMs
# host live mode ISO HDD with read-only HDD
# host live mode ISO HDD with read-only HDD + using VMs
# same as above but with [[Full Disk Encryption]] as an additional safety layer
# same as above but hardware write protection switches enabled
# host live mode ISO DVD-RW with
# host live mode ISO DVD-RW with + using VMs
# host live mode ISO DVD-R with
# host live mode ISO DVD-R with + using VMs
# same as above but with all other storage devices disconnected ("most secure")

Additional steps users can take to improve the security of live mode:

* Avoiding installation of additional software, especially more complex software that uses mount / loop devices or breaks the live indicator such as for example <code>snapd</code>.
* [[root#Prevent Malware from Sniffing the Root Password|Prevention of Malware Sniffing the Root Password]], because remount read-write requires [[root]].

See also {{whonix_wiki
|wikipage=Forensics
|text=Whonix technical design documentation on forensics
}}.

In summary, while striving for maximum security, absolute guarantees are unattainable. Users seeking higher data amnesia assurances should consider becoming developers or auditors, or sponsoring focused development and review in the realm of anti-forensics, including the development of comprehensive automated testing frameworks.

= Remount Disk as Read-Write after booting into Live Mode =
{{Anchor|remount}}
This is chapter is more of developer documentation, proof of concept, for curiosity than something that users should do.

'''1.''' Create a mount folder <code>/mnt/disk</code>.

{{CodeSelect|code=
sudo mkdir /mnt/disk
}}

'''2.''' Mount.

Note: <code>/dev/sda3</code> applies to VirtualBox VMs. It needs to be replaced with the actual hard drive device name.

{{CodeSelect|code=
sudo mount /dev/sda3 /mnt/disk
}}

'''3.''' Remount a read-write.

{{CodeSelect|code=
sudo mount -o remount,rw /dev/sda3 /mnt/disk
}}

'''4.''' Do persistent modifications.

For example, create a file <code>/home/test-file</code>.

{{CodeSelect|code=
touch /mnt/disk/home/test-file
}}

It is unclear if the disk could even be remounted to <code>/</code> but that is left as an sysadmin exercise to the reader.

'''5.''' When done, unmount.

{{CodeSelect|code=
sudo umount /mnt/disk
}}

'''6.''' Remove the mount point.

Optional.

{{CodeSelect|code=
sudo rmdir /mnt/disk
}}

'''7.''' Done.

The process has been completed.

Questions and answers:

* Is this a security issue? Yes.
* Is this issue specific to, caused by grub-live or Kicksecure? No, [[unspecific|unspecific to Kicksecure]].
* Is this issue reproducible on other live systems, i.e. without grub-live, Kicksecure being involved? Yes.
* Are also similar live systems affected? Yes, see [[#Security_Considerations|Security Considerations]].
* What users can do to improve their security? See same link as above.

= Troubleshooting =

Here are some problems you might encounter and their possible solutions.

== Missing grub-live boot menu entry ==
Please check your local file {{CodeSelect|inline=true|code=/etc/grub.d/11_linux_live}} looks exactly the same as [https://github.com/Kicksecure/grub-live/blob/master/etc/grub.d/11_linux_live <code>/etc/grub.d/11_linux_live</code> on GitHub] to verify you have the latest version of the grub-live package. Note, that the stable version might look slightly different than the developers or testers version on github.

Please run the following commands for debugging / information gathering and post them when creating any support requests.

{{CodeSelect|code=
dpkg-query -W -f='${db:Status-Status}' initramfs-tools
}}

{{CodeSelect|code=
dpkg-query -W -f='${db:Status-Status}' dracut
}}

== Live Check Systray Issues ==

The live mode is indicated by a Live Check Systray icon. I can happen that this icon has an issues. If so here's what you can do.

First of all this is '''NOT an [[Malware_and_Firmware_Trojans#Valid_Compromise_Indicators_versus_Invalid_Compromise_Indicators|indication of compromise by malware]]'''. The real issue is as simple as: '''The Live Check Systray is broken'''.

'''Known issues:'''

* 1) As mentioned in chapter [[read-only#VirtualBox|Combine Kicksecure Live VMs with Read-only Mode for Virtual Hard Drives chapter VirtualBox]].

If not an already known issue, please follow these steps:

<span class="fontsize19">1. Is livecheck.sh showing an error?</span>

If [https://github.com/{{project_name_short}}/desktop-config-dist/blob/master/usr/share/livecheck/livecheck.sh livecheck] is showing an error it might be the following issue. Live check runs command <code>sudo --non-interactive /bin/lsblk --noheadings --raw --output RO</code> as the current unprivileged user. You can test this for yourself with the following command. If this is working then this is NOT the issue

{{CodeSelect|code=
sudo --non-interactive /bin/lsblk --noheadings --raw --output RO
}}

If this is not working the problem might be that [https://forums.whonix.org/t/whonix-xfce-development/6213/102 this will only work by default for the user <code>user</code>], no other user. For example it will not work by default for the Linux user account <code>user2</code> or any other than <code>user</code>.

If the problem is that a user other than <code>user</code> is the logged in subject then

* '''option (A)''' the current user - for example <code>user2</code> - needs an exception in <code>/etc/sudoers.d</code>. For comparison see file [https://github.com/{{project_name_short}}/desktop-config-dist/blob/master/etc/sudoers.d/desktop-config-dist <code>/etc/sudoers.d/desktop-config-dist</code>].
* '''option (B)''' the current user - for example <code>user2</code> - needs to be or become a member of any of the following Linux user groups:
<code>users</code>
<code>staff</code>
<code>adm</code>
<code>sudo</code>
<code>root</code>
<code>wheel</code>
<code>console</code>
<code>console-unrestricted</code>

<span class="fontsize19">2. Try lsblk</span>

If the above method does not work try also this:

{{CodeSelect|code=
sudo /bin/lsblk
}}

<span class="fontsize19">3. If nothing works, report the bug</span>

If you are still having issues you can [[Reporting_Bugs|report a bug]] with the output from above two <code>lsblk</code> commands included from above.

== Technical Details of livecheck.sh ==
This chapter is for advanced users only.

Most users can skip this chapter. See [https://github.com/{{project_name_short}}/desktop-config-dist/blob/master/usr/share/livecheck/livecheck.sh livecheck.sh] for further script details.

* The meaning of <code>0</code> in <code>lsblk</code> output is <code>read-write</code>.
* The meaning of <code>1</code> in <code>lsblk</code> output is <code>read-only</code>.

If anything in coloumn <code>RO</code> is set to <code>0</code>, then it is not blessed [[read-only|read-only hard drive mode]].
-----
Example <code>lsblk</code> without any <code>snapd</code> installed, {{project_name_gateway_short}}, live mode, and [[read-only|read-only hard drive mode]] enabled.

<pre>
sudo lsblk
</pre>

<pre>
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0  100G  1 disk
└─sda1   8:1    0  100G  1 part /lib/live/mount/medium
</pre>
-----
Example <code>lsblk</code> without any <code>snapd</code> installed, {{project_name_gateway_short}}, live mode, and [[read-only|read-only hard drive mode]] disabled.

<pre>
sudo lsblk
</pre>

<pre>
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0  100G  0 disk
└─sda1   8:1    0  100G  0 part /lib/live/mount/medium
</pre>
-----
Example <code>lsblk</code> with <code>snapd</code> and <code>WickrMe</code> installed, {{project_name_workstation_long}}, persistent mode, and [[read-only|read-only hard drive mode]] disabled.

<pre>
sudo lsblk
</pre>

<pre>
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
loop0    7:0    0 62.1M  1 loop /snap/gtk-common-themes/1506
loop1    7:1    0  446M  1 loop /snap/wickrme/352
loop2    7:2    0   55M  1 loop /snap/core18/1754
sda      8:0    0  100G  0 disk
└─sda1   8:1    0  100G  0 part /lib/live/mount/medium
sr0     11:0    1 1024M  0 rom
</pre>

= Developer Information =
Users can skip this chapter and below.

== Implementation ==
This is based on dracut module <code>90overlay-root</code> which gets enabled when kernel parameter <code>rootovl</code> is set. <code>90overlay-root</code> is only available in the Debian fork of dracut.

* dracut module source file: {{CodeSelect|code=/usr/lib/dracut/modules.d/90overlay-root/overlay-mount.sh|inline=true}}
* [https://github.com/{{project_name_short}}/grub-live <code>grub-live</code> source code]
* main file: [https://github.com/{{project_name_short}}/grub-live/blob/master/etc/grub.d/11_linux_live <code>/etc/grub.d/11_linux_live</code>]
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017039
* https://github.com/dracutdevs/dracut/issues/1565

== Development ==
Should port to [https://github.com/dracutdevs/dracut/tree/master/modules.d/90overlayfs <code>90overlayfs</code>]

{{CodeSelect|code=
rd.live.overlay.overlayfs=1 rd.live.overlay.readonly=1
}}

While Debian did not https://salsa.debian.org/debian/dracut/-/merge_requests/20 the module will be updated in the next major version of Debian as per usual as Debian receives newer dracut versions from dracut upstream.

== Porting grub-live to other Linux Distributions ==
Might be rather simple in comparison to other packages.

grub-live should already be compatible with any Debian based distribution as mentioned on top of this wiki page. Testing is very limited.

Qubes support:

* That would require packaging grub-live for Fedora.
* Or as a first step copying over the config files.

What grub-live technically in essence does:

* 1) The grub-live is just shipping 1 grub config file [https://github.com/{{project_name_short}}/grub-live/blob/master/etc/grub.d/11_linux_live <code>/etc/grub.d/11_linux_live</code>].
* 2) Pull required dependencies in [https://github.com/{{project_name_short}}/grub-live/blob/master/debian/control <code>debian/control</code>]
* 3) Postinst runs: "<code>sudo update-grub</code>"

= Footnotes =

{{reflist|close=1}}
[[Category:Documentation]]
{{Footer}}