You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Chroots are heavily used by Rescuezilla's build scripts to create a root filesystem. One workaround listed in that bug report is "pre-seeding", which leads the package to be installed at first boot. This is not suitable because Rescuezilla's read-only filesystem uses OverlayFS, which is not yet compatible with snapd as described the bug report, and because the live USB will likely be used on older hardware with weaker CPUs so the overhead of re-installing packages may become significant.
For yet-unreleased Rescuezilla v1.0.6 upgrade to Ubuntu 20.04 (only for the new 64-bit release), snap-based packages was avoided by simply switching to Firefox and disabling snapd. But this approach may not be suitable going forward. It's ideal for end-users to not to have to be adversely affected by this, so I wrote a comment in the bug report above.
The text was updated successfully, but these errors were encountered:
Since Ubuntu 19.10, Chromium Browser is only packaged as a Snap. Unfortunately Snap-packages cannot be installed in a chroot: https://bugs.launchpad.net/snappy/+bug/1609903 (bug report from 2016)
Chroots are heavily used by Rescuezilla's build scripts to create a root filesystem. One workaround listed in that bug report is "pre-seeding", which leads the package to be installed at first boot. This is not suitable because Rescuezilla's read-only filesystem uses OverlayFS, which is not yet compatible with snapd as described the bug report, and because the live USB will likely be used on older hardware with weaker CPUs so the overhead of re-installing packages may become significant.
For yet-unreleased Rescuezilla v1.0.6 upgrade to Ubuntu 20.04 (only for the new 64-bit release), snap-based packages was avoided by simply switching to Firefox and disabling snapd. But this approach may not be suitable going forward. It's ideal for end-users to not to have to be adversely affected by this, so I wrote a comment in the bug report above.
The text was updated successfully, but these errors were encountered: