| Age | Commit message (Collapse) | Author |
|---|
|
* unionfs-fuse itself has been always very buggy for us.
* unionfs-fuse code in live-boot as been experimental at best.
* the FUSE implementation is horribly slow due to the nature of
FUSE (~10min to boot a live system with unionfs-fuse compared
to <<1min with aufs).
* and last but not least, there's overlay in kernel mainline now.
|
|
compatibility (Closes: #773881).
When overlayfs got merged into kernel mainline it was
renamed to overlay. We don't provide backwards compatibility
since overlayfs support was experimental and only with
non-debian default kernels available.
|
|
Loading, please wait...
[ 4.237575] sd 2:0:0:0: [sda] Assuming drive cache: write through
[ 4.239183] sd 2:0:0:0: [sda] Assuming drive cache: write through
[ 4.524950] sd 2:0:0:0: [sda] Assuming drive cache: write through
modprobe: module unknown not found in modules.dep
|
|
|
|
Golov <evgeni+git@golov.de> for reporting it.
|
|
|
|
Gaudenz Steinlin <gaudenz@debian.org> (Closes: #754166).
|
|
When no device for an overlay can be found, /tmp/custom_mounts.list
won't be created and will produce warnings while booting:
sort: /tmp/custom_mounts.list: No such file or directory
rm: can't remove '/tmp/custom_mounts.list': No such file or directory
Properly handle this case by calling rm with the -f option and calling
sort only when the file exists.
|
|
When resolvconf is used in the squashfs, /etc/resolv.conf is a symlink
to the generated version. Depending on the size of the squashfs and
other factors, sometimes we try to write to /etc/resolv.conf while it
still points to nirvana, as resolvconf did not generate it yet.
Instead of being racy and writing to a file which will be regenerated
anyways, let's detect resolvconf and write to its base file instead.
Initial detection idea by Mika Prokop <mika@grml.org>
|
|
|
|
|
|
|
|
(Closes: #729041).
|
|
uncompressed filesystems, thanks to John Bazik <jsb@cs.brown.edu> (Closes: #728250).
|
|
For example grml-rescueboot uses findiso for booting the ISO.
When booting from a software RAID using mdadm then
/scripts/local-top/mdadm being used inside
/scripts/boot/9990-misc-helpers.sh leaks its output to the
environment, causing invalid data used inside the
mount_images_in_directory function. Because the invalid data
results in a failing mount_images_in_directory execution we end
up with failed boot and error message:
"No supported filesystem images found at ...."
So instead redirect output of /scripts/local-top/mdadm to
/boot.log. Also make sure to check for existence of
/conf/conf.d/md before accessing it (the file doesn't always
exist).
While at it also make sure the same logic is used for
/scripts/local-top/lvm2.
See http://bts.grml.org/grml/issue1270
|
|
is_nice_device() for newer udev versions.
|
|
This adds support for mounting a plain writable directory as the
persistence storage layer. The $PERSISTENCE_PATH and the persistence-label
are taken into account when searching for the persistence.conf file.
|
|
The path /live/medium is used for probing different devices when searching
for the live rootfs. There is no reason why that device should be banned
from being used for persistence storage. Instead the devices that are
actually used as the backing storage for the live rootfs should be banned.
|
|
If the persistence device has been mounted before, e.g. for mounting the
rootfs image file, then we should try to remount it writable. This way the
result for both cases, 1. was and 2. was not mounted before, are identical.
|
|
We should only check for the persistence media path being a block device
where it is really required which is the case in mount_persistence_media().
|
|
When using PERSISTENCE_PATH we should prepend and append a pathname
separator as this is done with other user provided paths as well, e.g.
LIVE_MEDIA_PATH.
|
|
|
|
|
|
|
|
simple ls call anyway.
|
|
|
|
simplicity.
|
|
|
|
|
|
|
|
|
