Bug#705183: molly-guard: SSH_CONNECTION can be kept with specific sudoers config
Package: molly-guard Version: 0.4.5-1 Severity: wishlist Dear Maintainer, In the molly-guard(8) manual page, it is said that the following situations are still unguarded: · running sudo within screen or screen within sudo; sudo eats the SSH_CONNECTION variable, and screen creates a new pty. · executing those command in a remote terminal window, that is a XTerm started on a remote machine but displaying on the local X server. * What led up to the situation? At home I have a computer that can be accessed from remote hosts via ssh. I often run sudo within screen, so just after molly-guard installation I have set ALWAYS_QUERY_HOSTNAME to true, as suggested in the manpage. But I have found this is not very convenient for local sessions (i.e. when I can physically access the computer). * What exactly did you do (or not do) that was effective (or ineffective)? Then I have played with sudoers options and set: Defaults env_keep+=SSH_TTY SSH_CONNECTION and I have (re)commented the ALWAYS_QUERY_HOSTNAME assignment in the rc file. This works like a charm: ssh sessions are protected, and local sessions can be rebooted/halted directly. This has been tested with both: $ ssh user@remote -t screen $ ssh -X user@remote xterm $ ssh -X user@remote xterm -e tmux (and some other variations) I noticed that SSH_TTY is not set with ssh -X ...; but SSH_CONNECTION is set in all cases except when a screen session is reattached remotely to a detached screen session that was created locally. Unfortunately, it is also set when a screen session is reattached locally to a detached session that was created remotely. Maybe this is not exactly what you mean when you say: If you can think of ways to protect against those, please let me know! (because it requires to modify the configuration of another program instead of modifying the code of molly-guard itself), but I think this small piece of sudoers configuration covers enough use cases to be at least mentioned in the documentation. Thank you quidame -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-486 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages molly-guard depends on: ii procps 1:3.3.3-3 molly-guard recommends no packages. molly-guard suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703404: debian-installer: wheezy (PXE boot) failes to install busybox and kernel
Package: debian-installer Version: 20130211 Followup-For: Bug #703404 Hi, I don't understand why bug #703146 is not already fixed, but here is a workaround based on the suggestion of Pierre Blondeau (http://bugs.debian.org/703404#112): It consists to modify /bin/apt-install in the initrd to make it manages errors differently; if installation of a package fails (this can happen for busybox or any other package after the debootstrap-base stage), then clean and update the APT database of the target, and try again. This works fine, also for automated and preseeded installations; this has been tested with the netboot initrd (20130211). See the diff in attachment. cheers, quidame -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-486 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- no debconf information --- a/bin/apt-install 2011-02-11 03:00:13.0 +0100 +++ b/bin/apt-install 2013-04-02 10:07:43.038031326 +0200 @@ -76,6 +76,21 @@ in-target sh -c debconf-apt-progress --no-progress --logstderr -- \ apt-get $apt_opts install $packages || ERRCODE=$? + +# This is a workaround of the bugs: +# http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703146 +# http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703404 +# If installation of a package fails, clean and update APT database, and try +# again. +if [ $ERRCODE != 0 ]; then + ERRCODE=0 + in-target find /var/lib/apt/lists/ -type f -delete + in-target apt-get update + in-target sh -c debconf-apt-progress --no-progress --logstderr -- \ + apt-get $apt_opts install $packages || ERRCODE=$? +fi + + if [ $REMOUNT_CD ]; then load-install-cd /target || true fi
Bug#703747: netcfg: preseed netcfg: confusion or regression about disable_dhcp, disable_autoconfig and use_autoconfig
Package: netcfg Version: 1.106 Severity: normal Tags: d-i Dear Maintainer, * What led up to the situation? I have built a preseed.cfg file to perform an automated installation on a remote Virtual Machine with a static IP address. The original iso image was downloaded from: http://ftp.debian.org/debian/dists/wheezy/main/installer- amd64/current/images/netboot/mini.iso [built on 20130211] Then the iso image has been rebuild with a custom initrd including the preseed.cfg file at its root, with: [...] # gunzip initrd.gz # ls preseed.cfg | cpio --create --append --format newc --file initrd # gzip --best initrd [...] # genisoimage [...] I'm not an expert nor a wizard of preseeding, but enough familiar with this technique to read and understand documentation. First of all, I have read this page: http://www.debian.org/devel/debian-installer/News/2013/20130217 where it is explicitly said: 'Use netcfg/disable_autoconfig instead of netcfg/disable_dhcp (#689531).' This is confirmed by: http://lists.debian.org/debian-boot/2012/10/msg00054.html http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689531#25 and even /var/lib/dpkg/info/netcfg.templates in the initrd of the installer. But with: d-i netcfg/disable_autoconfig boolean true netcfg still try DHCP first, and installation fails. * What exactly did you do (or not do) that was effective (or ineffective)? I don't own an amd64 PC, so I have performed other tests with my i386 laptop. I have played with several sets of configuration in preseed.cfg or on boot command line, with the following, surprising results: d-i netcfg/disable_autoconfig boolean true - doesn't work d-i netcfg/use_autoconfig boolean false - doesn't work d-i netcfg/disable_autoconfig boolean true d-i netcfg/use_autoconfig boolean false - doesn't work on boot cmdline: netcfg/disable_autoconfig=true netcfg/use_autoconfig=false - doesn't work But with the official mini.iso (the same as above but for i386), without preseed.cfg or whatever, just on boot command line of the default menu entry: netcfg/disable_dhcp - leads me directly to the configuration of a static IP Now, if I put this in a preseed.cfg: d-i netcfg/disable_dhcp boolean true d-i netcfg/get_ipaddress string 192.168.1.86/24 d-i netcfg/get_gateway string 192.168.1.1 d-i netcfg/get_nameservers string 192.168.1.1 it works like a charm So, what about netcfg/use_autoconfig and netcfg/disable_autoconfig ? Or what about the documentation ? I don't understand. The version of netcfg shipped in the downloaded mini.iso is 1.106; there was a bugreport against the same program, version 1.92, to say that d-i netcfg/disable_dhcp boolean true fails [1]. Is 1.106 a regression ? Now, to build a generic preseed.cfg file that could work with different versions of the installer, and to be sure DHCP config is skipped, I use: d-i netcfg/disable_dhcp boolean true d-i netcfg/disable_autoconfig boolean true d-i netcfg/use_autoconfig boolean false knowing that at least one of them (and probably two) is useless; but how to know which, in advance... cheers, quidame [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688273 -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (500, 'testing-proposed-updates') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-486 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691029: udisks: set ID_DRIVE_DETACHABLE to 0 has no effect. This can lead to system crash.
Package: udisks
Version: 1.0.4-7
Severity: normal
Dear Maintainer,
When I use ENV{ID_DRIVE_DETACHABLE}:=0 in custom udev rules,
it has no effect, and the whole drive is detached when I unmount the
partition from my Desktop / File Manager. It seems to be not so grave,
but I work on systems embedded on USB/Firewire/MMC devices. For
external HDD, there is no problem, but with USB sticks, if I have set
a non-system partition (not registered in fstab) to be mounted/unmounted
from the Desktop or File Manager, I can mount it as expected, but when
I unmount it, the drive hosting the system is detached, and then system
crashes and all the work in progress is lost.
First I have tried to know if Udisks is correctly integrated in my desktop
environment. I use Xfce4 (4.8) with Thunar as file manager. When I write
udev rules with things like:
SUBSYSTEMS==usb, \
KERNEL==sd?*, \
ENV{UDISKS_PRESENTATION_NAME}=$env{ID_VENDOR} (%n}, \
ENV{UDISKS_PRESENTATION_ICON_NAME}=removable-media, \
ENV{UDISKS_SYSTEM_INTERNAL}=1
all works fine: when I plug a USB stick in, partitions are shown with the
'removable-media' icon, the labels are as expected (for example
SanDisk (1) and SanDisk (2) ) and I am prompted for authentication
when I click on the icon in Thunar.
But ID_DRIVE_DETACHABLE has no effect at all.
Maybe the drive is not detached while there is another of its partitions
mounted. But my system is on encrypted LVM, so the first partition is
a PV: not *mounted*, just in use.
I can give more detailed info if you ask me
Thanks,
quidame
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'testing-proposed-updates')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-3-486
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages udisks depends on:
ii dbus 1.6.8-1
ii libatasmart4 0.19-1
ii libc6 2.13-35
ii libdbus-1-31.6.8-1
ii libdbus-glib-1-2 0.100-1
ii libdevmapper1.02.1 2:1.02.74-4
ii libglib2.0-0 2.33.12+really2.32.4-2
ii libgudev-1.0-0 175-7
ii liblvm2app2.2 2.02.95-4
ii libparted0debian1 2.3-11
ii libpolkit-gobject-1-0 0.105-1
ii libsgutils2-2 1.33-1
ii libudev0 175-7
ii udev 175-7
Versions of packages udisks recommends:
ii cryptsetup-bin 2:1.4.3-2
ii dosfstools 3.0.13-1
ii eject 2.1.5+deb1+cvs20081104-11
ii hdparm 9.39-1+b1
ii ntfs-3g 1:2012.1.15AR.5-2.1
ii policykit-1 0.105-1
Versions of packages udisks suggests:
pn mdadm none
ii reiserfsprogs 1:3.6.21-1
ii xfsprogs 3.1.7+b1
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678954: lvm2: Inconsistencies between lvm.conf and udev rules lead to hide VG, and worse
Package: lvm2
Version: 2.02.95-4
Severity: important
Dear Maintainer,
Here is the partition scheme of my system:
$ lsblk --noheadings -o TYPE,NAME,MOUNTPOINT /dev/sdb
disk sdb
part └─sdb1
lvm ├─usb-boot (dm-0) /boot
lvm └─usb-luks (dm-1)
crypt └─luks (dm-2)
lvm ├─luks-root (dm-3) /
lvm └─luks-home (dm-4) /home
It worked fine, but recently, and because several other drives using LVM can be
plugged on the same computer and I don't want to automatically activate them
when my system boots, I have modified the 'filter' assignment in
/etc/lvm/lvm.conf.
Knowing that:
$ ls -l /dev/disk/by-id | awk '/\/sdb1$/ {print $9}'
usb-Storage_Media_07BB103100182DD2-0:0-part1
my filter is:
filter = [ a|^/dev/disk/by-id/usb-Storage_Media_07BB103100182DD2-0:0-part1$|,
a|^/dev/mapper/luks$|, r|.*| ]
But:
# vgscan
Reading all physical volumes. This may take a while...
Found volume group usb using metadata type lvm2
The luks VG is not found !
In lvm.conf, only filter has been modified, and in the 'devices' section, I
have this default:
obtain_device_list_from_udev = 1
But:
$ /sbin/udevadm info --query symlink --name dm-0
$ /sbin/udevadm info --query symlink --name dm-1
$ /sbin/udevadm info --query symlink --name dm-2
$ /sbin/udevadm info --query symlink --name dm-3
root
$ /sbin/udevadm info --query symlink --name dm-4
The symlinks exist (at least in /dev/mapper) but are no more managed by udev !
It seems they have been created from the initramfs environment.
After what, when udev runs again from the system environment, some rules I
don't understand make those symlinks no more managed by udev, and unusable by
LVM tools !
In /lib/udev/rules.d/60-persistent-storage-dm.rules:
ENV{DM_UDEV_DISABLE_DISK_RULES_FLAG}==1, GOTO=persistent_storage_dm_end
In /lib/udev/rules.d/60-persistent-storage-lvm.rules:
ENV{DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG}==1,
GOTO=persistent_storage_lvm_end
What about the two previous rules ?
What is the need to prevent creation of symlinks by udev the second time it
runs ?
After 'update-initramfs -u', I have to boot the system manually from the
initramfs shell, because
/conf/conf.d/cryptroot don't exist, because /dev/mapper/luks-root is not seen
as a Logical Volume,
and the 'cryptroot' initramfs hook fails. But I'm not sure I have to report a
bug against the cryptsetup
package for that.
When the responsible files 60-persistent-storage-{dm,lvm}.rules are copied in
/etc/udev/rules.d
and then the above rules are just commented, all works fine (symlinks,
cryptroot and other expected
behaviours). But I suppose that there can be side effects concerning temporary
nodes. What about ?
Cheers,
quidame
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'testing-proposed-updates')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-2-486
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages lvm2 depends on:
ii dmsetup 2:1.02.74-4
ii initscripts 2.88dsf-22.1
ii libc6 2.13-33
ii libdevmapper-event1.02.1 2:1.02.74-4
ii libdevmapper1.02.12:1.02.74-4
ii libreadline5 5.2-11
ii libudev0 175-3.1
ii lsb-base 4.1+Debian6
lvm2 recommends no packages.
lvm2 suggests no packages.
-- Configuration Files:
/etc/lvm/lvm.conf changed [not included]
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675467: ITP: bilibop -- run Debian from external media
Package: wnpp Severity: wishlist Owner: bilibop project quid...@poivron.org * Package name: bilibop Version : 0.1 Upstream Author : bilibop project quid...@poivron.org * URL : https://poivron.org/~quidame/bilibop_project/ * License : GPL-3.0+ Programming Lang: Shell Description : run Debian from external media Bilibop is a collection of scripts using or used by other programs (initramfs- tools, udev, aufs, mount, GRUB2) to help admins to maintain a Debian GNU/Linux operating system installed on a removable and writable media. One of its main goals is to fix security issues or harden standard rules and policies to make the system more robust in this particular situation. The bilibop source package builds the following binaries: bilibop: metapackage bilibop-common: shell functions to find the drive hosting the root filesystem (dm-crypt, LVM, loop devices, aufs and any combination of them are supported) bilibop-rules: udev rules to fix the removable drive hosting the running system, and all its partitions, as members of the 'disk' group (fixes bug #645466). Other optional features for the desktop environment (based on Udisks). bilibop-lockfs: make a standard installation to behave like a LiveUSB. Can be used as an alternative (and enhancement) of the fsprotect package. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675532: RFS: bilibop/0.1 (ITP #675467)
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package bilibop * Package name: bilibop Version: 0.1 Upstream Author: bilibop project quid...@poivron.org * URL: https://poivron.org/~quidame/bilibop_project/ * License: GPL-3.0+ Section: admin It builds those binary packages: bilibop - run Debian from external media - metapackage bilibop-common - shell functions for bilibop scripts bilibop-lockfs - lock filesystems and write changes into RAM bilibop-rules - udev rules for OS running from external media To access further information about this package, please visit the following URL: http://mentors.debian.net/package/bilibop Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/b/bilibop/bilibop_0.1.dsc To know more: The bilibop suite is designed to help admins to maintain a Debian OS installed on a removable and writable media. One of its main goals is to fix security issues or harden standard rules and policies, to make the system more robust in this particular situation. bilibop-common functions use proc, sysfs and udev databases to query informations about block devices. The drivemap command shows them in a tree of dependencies. bilibop-rules fixes bug #645466: using the bilibop-common functions, the udev rules file fixes the external disk hosting the running system, and all its partitions, as members of the 'disk' group instead of 'floppy'; dm-crypt, LVM, loop devices and aufs root filesystems (and any combination of them) are supported. bilibop-lockfs can be used as an alternative to the 'fsprotect' package (especially for OS on USB stick), with additional features: - whitelist based configuration: all is protected but the listed fs/mountpoints - not only filesystems are set readonly, but also block devices - swap device management - notifications are send to the user about filesystems status (about temporary or permanent changes) Thanks for your attention quidame -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-proposed-updates') Architecture: i386 (i686) Kernel: Linux 3.2.0-2-486 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671734: grub-common: Add a variable in /etc/default/grub to pass specific kernel parameters in the 'recovery mode' entry
Package: grub-common
Version: 1.99-21
Severity: normal
Tags: upstream
Hello,
When running Debian in 'recovery mode' from GRUB2, there in fact is no
'recovery' or 'failsafe' useful option added to the kernel parameters: only
'single'. I think it would be nice to add a variable in /etc/default/grub for
that. For example (keeping 'single' as implicit parameter):
GRUB_CMDLINE_LINUX_RECOVERY=noapic noapm nodma nomce nolapic nomodeset nosmp
For me, the best reason to do that is that it is easier to delete useless
options in the GRUB-edit mode than remember the names of relevant options in
the same mode.
Because I'm not familiar with the patch mechanism, I can't provide you a clean
patch, but I can show you a possible way:
1. Modification in Upstream util/grub-mkconfig.in: add line #240:
GRUB_CMDLINE_LINUX_RECOVERY \
2. Modification in Upstream util/grub.d/10_linux.in: replace line #195:
single ${GRUB_CMDLINE_LINUX}
by:
single ${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_RECOVERY}
3. Modification in Debian debian/default/grub.diff: add line #12:
+GRUB_CMDLINE_LINUX_RECOVERY=noapic noapm nodma nomce nolapic nomodeset nosmp
NOTE: here the parameters listed in GRUB_CMDLINE_LINUX_RECOVERY are the sames
than those used in the 'failsafe' entry of Debian LiveCDs.
If you think I have to contact directly upstream maintainers, or if you prefer
I send you relevant patches, feel free to say me; I'm open and I will try.
Thanks
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'testing-proposed-updates')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-2-486
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages grub-common depends on:
ii gettext-base0.18.1.1-5
ii libc6 2.13-30
ii libdevmapper1.02.1 2:1.02.67-2
ii libfreetype62.4.9-1
ii libfuse22.8.7-2
ii zlib1g 1:1.2.6.dfsg-2
Versions of packages grub-common recommends:
pn os-prober none
Versions of packages grub-common suggests:
ii desktop-base 6.0.7
ii grub-emu none
ii multiboot-doc none
ii xorriso1.2.2-1
-- Configuration Files:
/etc/grub.d/10_linux changed:
set -e
prefix=/usr
exec_prefix=${prefix}
datarootdir=${prefix}/share
.. ${datarootdir}/grub/grub-mkconfig_lib
export TEXTDOMAIN=grub
export TEXTDOMAINDIR=${datarootdir}/locale
CLASS=--class gnu-linux --class gnu --class os
if [ x${GRUB_DISTRIBUTOR} = x ] ; then
OS=GNU/Linux
else
OS=${GRUB_DISTRIBUTOR} GNU/Linux
CLASS=--class $(echo ${GRUB_DISTRIBUTOR} | tr 'A-Z' 'a-z' | cut -d' ' -f1)
${CLASS}
fi
case ${GRUB_DEVICE} in
/dev/loop/*|/dev/loop[0-9])
GRUB_DEVICE=`losetup ${GRUB_DEVICE} | sed -e s/^[^(]*(\([^)]\+\)).*/\1/`
# We can't cope with devices loop-mounted from files here.
case ${GRUB_DEVICE} in
/dev/*) ;;
*) exit 0 ;;
esac
;;
esac
if [ x${GRUB_DEVICE_UUID} = x ] || [ x${GRUB_DISABLE_LINUX_UUID} =
xtrue ] \
|| ! test -e /dev/disk/by-uuid/${GRUB_DEVICE_UUID} \
|| uses_abstraction ${GRUB_DEVICE} lvm; then
LINUX_ROOT_DEVICE=${GRUB_DEVICE}
else
LINUX_ROOT_DEVICE=UUID=${GRUB_DEVICE_UUID}
fi
if [ x`${grub_probe} --device ${GRUB_DEVICE} --target=fs 2/dev/null || true`
= xbtrfs ] \
|| [ x`stat -f --printf=%T /` = xbtrfs ]; then
rootsubvol=`make_system_path_relative_to_its_root /`
rootsubvol=${rootsubvol#/}
if [ x${rootsubvol} != x ]; then
GRUB_CMDLINE_LINUX=rootflags=subvol=${rootsubvol} ${GRUB_CMDLINE_LINUX}
fi
fi
linux_entry ()
{
os=$1
version=$2
recovery=$3
args=$4
if ${recovery} ; then
title=$(gettext_quoted %s, with Linux %s (recovery mode))
else
title=$(gettext_quoted %s, with Linux %s)
fi
printf menuentry '${title}' ${CLASS} {\n ${os} ${version}
if ! ${recovery} ; then
save_default_entry | sed -e s/^/\t/
fi
# Use ELILO's generic efifb when it's known to be available.
# FIXME: We need an interface to select vesafb in case efifb can't be used.
if [ x$GRUB_GFXPAYLOAD_LINUX != x ]; then
if [ x$GRUB_GFXPAYLOAD_LINUX != xtext ]; then
cat EOF
load_video
EOF
fi
cat EOF
set gfxpayload=$GRUB_GFXPAYLOAD_LINUX
EOF
fi
cat EOF
insmod gzio
EOF
if [ x$dirname = x/ ]; then
if [ -z ${prepare_root_cache} ]; then
prepare_root_cache=$(prepare_grub_to_access_device ${GRUB_DEVICE} | sed
-e s/^/\t/)
fi
printf '%s\n' ${prepare_root_cache}
else
if [ -z ${prepare_boot_cache} ]; then
prepare_boot_cache=$(prepare_grub_to_access_device ${GRUB_DEVICE_BOOT} |
sed -e s/^/\t/)
fi
printf '%s\n' ${prepare_boot_cache}
fi
message=$(gettext_printf Loading Linux %s ... ${version})
cat EOF
echo'$message'
linux ${rel_dirname}/${basename}
root=${linux_root_device_thisversion} ro ${args}
EOF
if test -n ${initrd} ; then
message=$(gettext_printf Loading initial ramdisk ...)
