Re: Does/can DLB order the disk blocks in the order they are accessed during a default boot?
Hi, Martin Guy (2021-02-23): > I assume it would be feasible to record the sequence of disk accesses > during a normal boot from CD/DVD and ensure that the required blocks > are in the ISO in linear disk-reading order, which should speed boot > time from optical media. > > I guess that means booting the ISO image during the build in something > virtual, with a magic kernel option to make it spew all the disk > access addresses, then reorder the ISO accordingly. > > Does anyone know if this is already done in live-build, or if any > other ISO build systems do this? We do something like this at Tails, using inotify, except: - We update the SquashFS ordering as part of our release process, not as part of the build. - It's not fully automated. Some manual work is required. - Nowadays, we optimize for booting from USB drives, not DVD. The implementation remained identical though. For details, look for files called *boot-profile, and "git grep boot-profile", in our Git repo: https://gitlab.tails.boum.org/tails/tails/ Cheers!
Re: Volume ID with mkfs.msdos
Hi, Roland Clobus (2021-02-16): > On 16/02/2021 08:13, Juergen Fiedler wrote: >> I am using a fairly up to date sid (live-build 1:20210122) to build a >> sid ISO - and it's not working right now. >> >> This is caused by two invocations of mkfs.msdos that use the current >> epoch as the volume-id... >> The volume-id is supposed to be a 32bit hex number (in hex notation), >> and the epoch is significantly larger than 8 digits. Older versions of >> mkfs.msdos tolerated that - but the latest does not. >> >> Does the volume-id parameter in efi-image and binary_grub-efi serve an >> important purpose? If not, could it please be dropped? > > The volume-id itself has no special importance. I've added volume-id > parameter, because without it, the volume-id would have been chosen > randomly, which makes the live image non-reproducible. I'll look into > this to create a patch. FWIW, in case it may help, here's how we create a the Tails FAT filesystem reproducibly (pasting Python code as-is): execute([ 'mkfs.msdos', '-v', # Use constants for normally randomly generated or time-based data # such as volume ID and creation time '--invariant', # Fill all 11 chars of the volume label to avoid any uninitialized # memory from sneaking in '-n', 'TAILS' + 6 * ' ', self.partition.props.block.props.device, ]) Cheers!
Re: Replacing aufs with overlayfs
Hi Debian Kernel Team, intrigeri (2014-12-11): > Ben Hutchings wrote (09 Dec 2014 19:55:10 GMT) : >> Please try the Linux 3.18 packages from experimental (they're not there >> yet, but should be soon) and check that overlayfs does what you need. > > Thanks. I'll test it for Tails' usecases (that use aufs a bit more > than most other live systems, e.g. our incremental upgrades features > uses it) once I find the time to. It took us a while, but I'm happy to report that Tails has finally migrated away from aufs! So as far as Tails is concerned, we don't need the aufs "compat" patchset in src:linux anymore :) In passing, so that I can call "case closed" some of the blockers that were discussed later on this thread back in 2014-2015: 1. overlayfs stack depth upper limit vs. live-boot SquashFS stacking feature It turns out that was a misunderstanding: that upper limit applies to how many overlayfs filesystems can be part of a new overlayfs mount, rather than to how many read-only lower layers it's built from. 2. overlayfs vs. AppArmor It's still true that out-of-the-box, just like aufs, overlayfs does not play well with AppArmor. That's why apparmor.service turns itself into a no-op when it detects a Debian or Ubuntu Live system. To make them work together, one solution is to add a few AppArmor `alias` rules, and to add the `attach_disconnected` flag to every profile. For example: - https://salsa.debian.org/tails-team/tails/-/blob/master/config/chroot_local-includes/etc/apparmor.d/tunables/alias.d/tails - https://salsa.debian.org/tails-team/tails/-/blob/master/config/chroot_local-hooks/48-tweak-AppArmor-profiles - https://tails.boum.org/contribute/design/application_isolation/ Cheers!
Bug#882851: live-config: Wrong time when RTC is set to local time
Hi Marcel, Marcel Partap: > has anything changed about this situation since a year ago? I'm not aware of any change in this respect and I'm confident that live-config contributors would have updated this bug report if there had been changes. > I think you have described the options very well and I also liked > your proposal on 914001.. I have one day to get it implemented .. > Mind assisting me a bit? 邏 I'm afraid I can make time for this under such a tight timeline :/ But if you come back to it later, I'll be there :) Cheers, -- intrigeri
Bug#927219: xorg log
Hi Jonathan, Jonathan Carter: > KMS seems to work just fine, I see the full-resolution plymouth splash, > it's only when Xorg starts when the screen goes blank (I can switch to > VTs though). Well, it may work well enough for Plymouth but both the kernel and X.Org try to use modesetting and fail: - In the Live kernel logs I see: [drm] radeon kernel modesetting enabled. [drm:radeon_pci_probe [radeon]] *ERROR* radeon kernel modesetting for R600 or later requires firmware installed See https://wiki.debian.org/Firmware for information about missing firmware - … which probably explains: (II) [KMS] drm report modesetting isn't supported. On that Live system, X.Org tries in turn the ati, modesetting, fbdev, and vesa drivers. My understanding is that they all fail, some by nicely detecting they can't work without full KMS support, and the vesa driver (I think, since fbdev has been unloaded already at this point) less nicely: it bails out. While on your installed system, you, or d-i, or something else, has explicitly disabled KMS, presumably to workaround the problem this bug report is about: > [23.526] Kernel command line: > BOOT_IMAGE=/boot/vmlinuz-4.19.0-4-amd64 > root=UUID=857f7028-b03d-465d-a5db-c8dfb12dc02b ro quiet nomodeset ^ Then in a context where it's clear(er) that KMS is not fully supported, X.Org manages to fall back to the vesa driver, which somehow manages to display something in degraded mode. I'm no expert in this field but it seems to me that on the Live system, the X.Org vesa video driver fails to detect that it's running in an environment where KMS is enabled but not fully supported, and then does not fall back to degraded mode. Either the kernel exposes an interface that would theoretically allow vesa to identify this situation and accordingly switch to degraded mode, and then it's a bug in the vesa driver. Or the kernel does not, and vesa is unavoidably mislead into believing KMS is fully functional, and then it's a bug in the kernel. It would be nice to check if there are known kernel or X.Org bugs in this area, and if not, ask their respective maintainers guidance wrt. where to reassign this bug report. On the Debian Live front, apart of documenting the known issue and its workaround (add "nomodeset" on the kernel command line), it may technically be possible to workaround this bug for images that use syslinux: dynamically add "nomodeset" to the kernel command line if an affected PCI device is detected (using lua.c32). I don't know if that's possible with GRUB. Cheers, -- intrigeri
Bug#927219: xorg log
Control: tag -1 + moreinfo Hi Jonathan, Jonathan Carter: > Here is my my xorg log file on my AMD Radeon HD 8570D: > […] > [18.261] (II) [KMS] drm report modesetting isn't supported. I suspect we need to include the amdgpu module in the initramfs; at Tails we do it with: https://salsa.debian.org/tails-team/tails/blob/master/config/chroot_local-includes/usr/share/initramfs-tools/hooks/kms Seeing the kernel log would help debug this: most modern X.Org drivers rely on the kernel to do modesetting nowadays. Also, reading the logs, I wonder if xserver-xorg-video-amdgpu is installed. Can you please check, or point us to the exact image you've tested? Thanks in advance!
Bug#922378: live-boot: Libreoffice doesn't start from a live environment. Signal 11
Control: reassign -1 apparmor Control: severity -1 serious Control: retitle -1 AppArmor policy breaks confined software when running under live-boot + overlayfs Control: found -1 2.13.2-9 Hi, Cesar Etxeberria: > Everything works perfectly but libreoffice doesn't start (signal > 11). I can reproduce this with LibreOffice and Evince. The root cause of the problem is that the storage stack set up by live-boot with overlayfs is not supported by our AppArmor policy at the moment. Fixing the root cause of this problem: - will require quite some work; I've started working on this some time ago and will definitely finish it at some point for several reasons, including the fact that Tails needs this to be fixed; - is too involved to happen in time for Buster. So my plan for Buster is to disable apparmor.service when running under live-boot + overlayfs, just like Ubuntu already does in their live images for the exact same reason. This will prevent loading policy at boot time, which will avoid such breakage, except for packages that load policy themselves; thankfully, the nature of these packages (libvirt, LXC) makes it so they have little chance to be used in a Live environment, so I think that'll be good enough; and if it's not good enough, worst case we can patch the Live builds configuration to disable the AppArmor LSM entirely, by passing apparmor=0 on the kernel command line. Cheers, -- intrigeri
Bug#914001: live-config: Assume that RTC is in localtime if Windows is detected
Source: live-config Severity: wishlist Version: 5.20180224 User: tails-...@boum.org Usertags: misc-reported Hi, below, I'll assume that #882851 is fixed. Tails users experience important issues when their RTC is in localtime. It's too hard for non-technical users to 1. guess that the problems they're experiencing might be related to the RTC's timezone; 2. find out whether their RTC is in localtime; 3. pass utc=no every time they start Tails. So it would be nice if live-config supported utc=auto, which would do exactly the same thing as Debian Installer does [1]: if a Windows installation is detected, assume that the RTC is in localtime. I would suggest: - implement support for utc=auto in components/1120-util-linux; ideally, if os-prober is available, make utc=auto the default; but of course, let the kernel cmdline utc= option override it - add Recommends: os-prober (I guess not everyone wants to pull its dependency on grub-common) Thoughts? [1] https://salsa.debian.org/installer-team/clock-setup/blob/master/finish-install.d/10clock-setup#L69 Cheers, -- intrigeri
Bug#882851: live-config: Wrong time when RTC is set to local time
Hi Santiago and others, Santiago García Mantiñán: > I believe that systemd is reading /etc/adjtime before live systems adds the > LOCAL label to it, or something similar (this is just my thought, no > evicence pointing at this yet). Right, systemd starts before live-config (well, it starts live-config) so live-config's 1120-util-linux is simply late at the party. FWIW the relevant systemd code lives in the initialize_clock function (which calls clock_is_localtime, that parses /etc/adjtime). > I have done some tests and at the time 1120-util-linux just a few systemd > services are running: > root 441 0.6 0.4 39176 4400 ?Ss 15:04 0:00 > /lib/systemd/systemd-journald > systemd+ 492 0.4 0.4 129344 4192 ?Ssl 15:04 0:00 > /lib/systemd/systemd-timesyncd > in fact, no other service is running except for init, lvmetad, the kernel > processes and live-config itself. I think timedatectl talks to systemd-timedated.service which is activated on request over D-Bus. D-Bus typically starts after live-config but systemd sets up its listening socket early, so I'm not sure what's going on. I'm not sure that we can expect timedatectl to work during this stage of the boot process but if you want to go further down this path, I would suggest trying to do that in a new live-config-hwclock.service that starts after dbus.service, at least to better understand what's going on; and if despaired, add some debugging to method_set_local_rtc in timedated.c. > So... the question here is... how to we tell systemd at this time of the > boot process that we have the RTC in LOCAL time if setting LOCAL on third > line of /etc/adjtime at this time doesn't work and we cannot use timedatectl? I think there are three main options: 1. Have live-config use hwclock to apply the updated /etc/adjtime I guess calling "hwclock --systz" when utc=no should do the trick: that's what dracut does in the initrd it generates, whenever /etc/adjtime says "LOCAL". But beware: - Reading the systemd source code and hwclock manpage, it seems that some of the operations we want to perform only work the very first time. So once systemd has done them once, it may be too late, so I'm not sure if this can possibly work. But I think it's cheap enough to be worth trying. - Brutally applying a N hours offset to the system time while other services have already started has potential to break all kinds of things. Thankfully we have DefaultDependencies=no and Before=basic.target so the risk is somewhat limited. It might be worth checking if there's anything else we can do to start live-config even earlier, before other important services that have DefaultDependencies=no and might dislike time travel. 2. Move this to live-boot There, mimic what dracut does and call "hwclock --systz" when utc=no. I don't know if we also need to write /etc/adjtime there and I don't know if there's a hook point for initramfs-tools scripts to run after the root FS has been mounted read-write but before init is started. If that works and option #1 doesn't, it can be the cheapest short-term solution. Long-term, given the move to dracut seems unavoidable, it adds code that will need to be ported, which might be problematic (although I expect that teaching dracut to honor utc= would be easy). 3. Move this to systemd i.e. add the equivalent of the live-config.utc= option there and make sure clock_is_localtime honors it. At first glance it looks like the best option: every systemd-based OS benefits from it, this works with dracut too, and we can remove code from live-config. Assuming that would be accepted upstream, the only major downside I see is that it makes it harder to implement automatic discovery of "is RTC in UTC?", which I'm very interested in: that's why I landed here in the first place, will file a wishlist bug blocked by this one shortly. So I would recommend trying (1) and if that fails, trying (2). Meta: is this something you're interested in working on further yourself? Cheers, -- intrigeri
Bug#900688: live-tools: Needs to be adjusted to live-boot's new mountpoints
Control: severity -1 minor Luca Boccassi: > They should indeed be updated, but note that we ship a mount point to > provide backward-compatibility for Buster, so nothing should be broken > for the moment. Good to know, thanks! Cheers, -- intrigeri
Bug#900688: live-tools: Needs to be adjusted to live-boot's new mountpoints
Package: live-tools Version: 1:20171207 Severity: normal X-Debbugs-Cc: benjamin.dr...@profitbricks.com User: tails-...@boum.org Usertags: for-buster Hi! since 1:20180328 live-boot uses /run/live instead of /lib/live/mount (#886328). But at least 5 scripts shipped in live-tools still use the old paths. I did not test what's the exact impact yet but I suspect it breaks some of live-tools functionality. Cheers, -- intrigeri
Re: New team on salsa, which repositories shall we migrate?
Hi, Steve McIntyre: > 10 repos moved now: Thanks! > debian-live/debian-livelive-team/debian-live This seems to be an old copy of the live-build repo. Do we need it? Cheers, -- intrigeri
Re: New team on salsa, which repositories shall we migrate?
Hi, Raphael Hertzog: > At least: > - live-boot > - live-build > - live-config > - live-manual > - live-tools > - live-wrapper > But I think the following can be skipped: > - live-tasks (seems to be maintained in pkg-vmdebootstrap?) > - live-support (what is this about?) > - live-www ACK > What's unclear to me is "live-images". This source package does still > exist in Debian but we haven't touched it since Daniel left. Should we > remove the package entirely? Yes. Thanks for caring! Cheers, -- intrigeri
Bug#886328: live-boot: Please use /run/live instead of /lib/live/mount
Hi, Benjamin Drung: > Therefore move /lib/live/mount to /run/live and skip the intermedia > /live mount points. This reduces code and complexity. As someone who had to repeatedly bang his head against exactly this part of the live-boot code (last time earlier this week), I can only agree with the proposed simplification idea. I didn't do a full code review though. Cheers, -- intrigeri
Bug#886009: live-config: race condition between live-config and systemd-tmpfiles-setup
Control: tag -1 + patch Ronny Standtke: > The attached patch (against the current version in git) fixes this issue. Looks good to me.
Bug#882769: Cannot upgrade from Stretch: cp: target '/lib/live/mount/medium/live/vmlinuz.new' is not a directory
Thomas Goirand: > Do you know if it's possible to generate a Sid live system? We have weekly builds of testing Live ISO images: https://get.debian.org/cdimage/weekly-live-builds/amd64/iso-hybrid/ … so I don't see any reason why building sid Live systems would be impossible :)
Bug#882769: Cannot upgrade from Stretch: cp: target '/lib/live/mount/medium/live/vmlinuz.new' is not a directory
Hi, Thomas Goirand: > After booting a Stretch live image, I tried to upgrade it to Sid, and > it fails with this error: Upgrading a *Live* system from one version of Debian to the other is arguably a corner case and this bug does not affect the usability of live-boot in the vast majority of cases. Besides, I would feel wrong to see live-boot automatically removed from testing merely because of this bug. So perhaps this could be demoted to severity:important? Cheers, -- intrigeri
Re: Planning Buster Live alpha1 release
Jonathan Carter (highvoltage): > On Friday night Steve kicked off builds that we could use for an alpha, > which uses the freshly released d-i alpha. I went ahead and mostly > tested the amd64 images already, i386 still needs to be tested and I > hope to get to those today if no one beats me to it. Amazing, thanks a lot for doing this! Cheers, -- intrigeri
Bug#862562: debian-live: Log Out option don't work
Control: tag -1 + confirmed syl: > The menu on the top right offers an option to log out (in the submenu "Debian > Live user"), it does not work and crash the system. I can reproduce something similar with debian-live-9.1.0-amd64-gnome.iso in a libvirt/QEMU VM with QXL graphics: the graphical session disappears (as expected), and then I very briefly see a GDM login screen and then I'm back to a text mode console. I suspect one can blame either GDM or the way it's configured (for autologin) in our Live systems. A Fedora 26 Live system exposes a similar, but different problem: upon logout I'm back to the GDM login screen, I can click "Live System User", I see a password prompt very quickly followed by the text console, and very quickly again I'm back to the GDM login screen. Cheers, -- intrigeri
Bug#862560: debian-live: GNOME Software in Debian Live lists only installed packages
Hi, [adding Debian GNOME Maintainers in the loop, as it might be a bug in GNOME Software / PackageKit that affects any Debian+GNOME first boot experience, rather than something specific to how we build Debian Live systems] >* What led up to the situation? > Launch GNOME Software in Debian Live. > Only "Installed" tab show packages. > The "All" tab only show "Editor's Picks" on the top, the rest is blank. >* What exactly did you do (or not do) that was effective (or ineffective)? > I launch the command "sudo apt update". >* What was the outcome of this action? > After launch this command, the "All" tab is still blank. >* What outcome did you expect instead? > Show all packages. FWIW on a Fedora 26 live system: 1. After logging into the GNOME session, GNOME Software / packagekitd start downloading stuff from the Internet (presumably package indices but I didn't investigate). 2. If I start GNOME Software, then I see a progress bar that says "Software catalog is being loaded" or "Software catalog is being downloaded" (depending on when exactly I start it), and eventually a list of available packages. … i.e. the right thing happens, so the good news is that it's feasible :) I don't know if they do something special to make this work in Fedora, or if the PackageKit support for APT is lagging behind, or if we do something special in our Live images that breaks this. I wonder if the first boot experience after installation is affected by the same problem. Does anyone know by heart? Otherwise, maybe syl would be happy to try? Cheers, -- intrigeri
Bug#869569: Please install spice-vdagent in the live cd
Hi, Laurent Bigonville: > It would be nice to have spice-vdagent installed by default in the live > cd. Yes, please. > That would allow the users using it in kvm to copy/paste from/to the > host. This + automatic screen resolution updates :) FTR spice-vdagent is shipped in Tails and in the Fedora 26 Live image. Cheers, -- intrigeri
Re: Is Debian Live System Reproducible?
Andres Pavez: > Is Debian Live System reproducible? > ie, can you reproduce the current live images with the same hash from scratch? No, not magically/automatically. But there's WIP to do this for Tails ISO images, and whatever could be fixed upstream / in Debian (mostly stuff generated by postinst scripts) is being fixed there: https://lists.reproducible-builds.org/pipermail/rb-general/2017-August/000596.html We'll report about how exactly we did it to the rb-general mailing list later this year.
Re: Boot option "persistence-read-only" doesn't work on debian live 9.0.1
Ronny Standtke: > Any chances that you are willing to add this feature for overlayfs too? Don't count on Tails people to do this, sorry.
Re: Boot option "persistence-read-only" doesn't work on debian live 9.0.1
giova.esp...@libero.it: > Boot option "persistence-read-only" doesn't work on debian live 9.0.1 I suspect (without having tried myself) that it still works when using aufs, and nobody added support for this feature for overlayfs. Now, FWIW we (Tails) have added this feature to live-boot years ago because we needed it back then, but we don't use/ship it anymore, so at least our use case won't be harmed if it gets removed or deprecated somehow. Cheers, -- intrigeri
Re: Topic of this list
Steve McIntyre: > I don't think we necessarily need to split the list, but at least > making it very clear in the subject line sounds like a good plan. +1 Cheers, -- intrigeri
Bug#857740: live-build: /etc/resolv.conf has unsafe permissions when copied from config/includes.chroot
Package: live-build Severity: normal Version: 1:20170213 Tags: security User: tails-...@boum.org Usertags: misc-reported Hi! when the config/includes.chroot/etc/resolv.conf file exists in the source tree, it is copied into the rootfs with "cp -a". So for example, if I've cloned a lb config source tree using Git as my user, the resulting live system has a /etc/resolv.conf owned by 1000:1000, and thus writable by the default live user. Depending on the exact context in which the live system is used, the security impact can be non-existent or rather severe. Disclaimer: I've only verified this behavior on Tails' patched live-build 2.x. Sorry! But the affected code looks very much the same on the current master branch. Cheers, -- intrigeri
Re: shrinking the squashfs image size
Stefan Baur: > I would like to run > rm -rf squashfs-root/usr/share/doc/* squashfs-root/usr/share/locale/* > squashfs-root/usr/share/man/* > (the files in these directories are not relevant for my use case because > there is only one single application running in full-screen mode, and no > shell access for the user) > before the squashfs is created. > Where would I have to add that? Either use a chroot local hook, or list these files to a SquashFS exclude config file passed to mksquashfs via the -ef in $MKSQUASHFS_OPTIONS. > Also, I would like to run mksquashfs with additional parameters > -b 1048576 -comp xz > as that seems to shrink the image even further, thus reducing transfer > times (even though RAM usage will probably be the same). > Where would I specify that? Use the MKSQUASHFS_OPTIONS environment variable. FWIW, in Tails we determined experimentaly that these settings were the most efficient in our case: -comp xz -Xbcj x86 -b 1024K -Xdict-size 1024K
Re: /usr/bin/env: apt-get: No such file or directory
Federico Bruni: > Il giorno gio 24 nov 2016 alle 14:59, intrigeri > <intrigeri+debian-l...@boum.org> ha > scritto: >> Federico Bruni: >>> /usr/bin/env: apt-get: No such file or directory >> >>> This happened three times in a row, so it doesn't seem a sporadic error. >> >> IIRC this can be fixed by disabling merged-/usr, i.e. >> pass --no-merged-usr to debootstrap. > When was this option introduced? It doesn't seem to be available in Jessie > (debootstrap version 1.0.67). Indeed. So it's another problem you're facing, sorry for the wrong lead!
Re: /usr/bin/env: apt-get: No such file or directory
Federico Bruni: > /usr/bin/env: apt-get: No such file or directory > This happened three times in a row, so it doesn't seem a sporadic error. IIRC this can be fixed by disabling merged-/usr, i.e. pass --no-merged-usr to debootstrap.
Bug#831384: live-config: X.Org driver automatic override for VirtualBox is useless and breaks some use cases
Package: live-config
Version: 5.20160608
Severity: normal
User: tails-...@boum.org
Usertags: virt-guest for-stretch
Hi,
in live-config we have this code:
# xorg-driver automatic override for virtualbox
if [ -e /var/lib/dpkg/info/virtualbox-guest-x11.list ] && echo "${_DEVICE}" |
grep -qs '^80EEBEEF'
then
LIVE_XORG_DRIVER="vboxvideo"
fi
… that forces using the vboxvideo *X.Org* driver if it's installed,
and we're running in VirtualBox.
This breaks starting X when the vboxvideo *kernel* (dkms) driver is
loaded:
(II) vboxvideo: kernel driver found, not loading.
(EE) No devices detected.
In that situation, X starts just fine after removing the xorg.conf.d
snippet added by live-config.
Besides, this code seems to be useless nowadays since when the
vboxvideo kernel driver is not present, X.Org successfully autodetects
and uses the vboxvideo X.Org driver (tested on Jessie + kernel from
jessie-backports), even without that xorg.conf.d custom snippet.
So, it seems to me that dropping the code quoted above would fix one
problem, simplify our code base a bit, and should not break anything.
Thoughts?
Cheers,
--
intrigeri
Re: [Debconf-discuss] dracut BoF
Hi, Thomas Lange wrote (04 Jul 2016 10:49:26 GMT) : > On Thursday there will be a dracut (it's an initramfs-tools > replacement) BoF at 15:00 in Menzies 13. … and some of us want to have a look at how live-boot could use dracut, during this BoF ⇒ Debian Live users might be interested in joining :) Cheers, -- intrigeri
Re: Backports request live-boot
Hi, Kristian Klausen wrote (09 Apr 2016 15:46:06 GMT) : > Overlayfs support was added to live-boot around 5.x. > Without this package you can't create a live image which works with > newer kernel hence also newer hardware like skylake. Building overlayfs -based Jessie images with live-boot 5.x pulled from testing/sid seems to work just fine for me last time I checked, so I'm not sure if/why a backport is really needed here. (In general I'm in favour of such not-strictly-required backports *if* the target userbase is not technical enough to configure APT pinning properly; in this case it seems less clear-cut.) Cheers, -- intrigeri
Re: Possible bug in "Enable write-mode for persistency related devices in readonly/forensic mode"
Hi, Michael Prokop wrote (31 Dec 2015 20:58:15 GMT) : > The grep options should have been '-qw' instead AFAICT. Thanks for looking into it so quickly! JFTR, I'm not sure what's the preferred workflow to make sure this is well tracked and fixed before next upload: given the buggy code only lives in Git and was never uploaded to Debian, I guess that a bug in the BTS is not appropriate. Cheers, -- intrigeri
Re: Possible bug in "Enable write-mode for persistency related devices in readonly/forensic mode"
Evgeni Golov wrote (01 Jan 2016 14:53:30 GMT) : > Indeed, fixed in Git, thanks! :) > On Fri, Jan 01, 2016 at 10:50:49AM +0100, intrigeri wrote: >> JFTR, I'm not sure what's the preferred workflow to make sure this is >> well tracked and fixed before next upload: given the buggy code only >> lives in Git and was never uploaded to Debian, I guess that a bug in >> the BTS is not appropriate. > I'd probably just fill a bug with "+git" or something as > version. Works for me, I'll do that next time. Cheers, -- intrigeri
Possible bug in "Enable write-mode for persistency related devices in readonly/forensic mode"
Hi, in https://anonscm.debian.org/cgit/debian-live/live-boot.git/commit/?id=e3cbd82426f1710dba545ee0f44b0731a45e0b6a, it looks like "if grep -qe persistence /proc/cmdline" will be verified if the 'nopersistence' boot option is used, which may not be on purpose. I didn't actually tested the code myself, so sorry for the noise if this is a false alert :) Cheers, -- intrigeri
Re: 32-bit efi
Hi, FWIW here's Tails' implementation for live-build 2.x, using GRUB2's support for reading syslinux configuration: https://git-tails.immerda.ch/tails/tree/config/binary_local-includes/EFI/BOOT/grub/grub.cfg https://git-tails.immerda.ch/tails/tree/config/binary_local-hooks/50-grub-efi-ia32 Depending on what exactly you need to support from the syslinux config, you might need a fairly recent GRUB2. Cheers, -- intrigeri
Re: [PATCH] Logging a warning when an expected image file is missing
Daniel Baumann wrote (29 Apr 2015 04:39:00 GMT) : On 04/29/15 01:48, intrigeri wrote: Was there any follow-up on this? that seem to have fallen through the cracks, applied now, thanks. Thanks! Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85iocfqm2h@boum.org
Re: [PATCH] Logging a warning when an expected image file is missing
Hi, anonym wrote (16 Dec 2014 13:20:44 GMT) : I've noticed that if a .module file lists an image that doesn't exist, it's silently ignored. I thought that at least a warning is warranted in this situation since it may indicate a mistake when preparing the live system. Also, the fact that this is valid (and not an error) isn't documented in the man page but my patch doesn't deal with that. Was there any follow-up on this? I see that Daniel is in a merging mood these days :) Cheers! -- intrigeri -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85a8xru84e@boum.org
Re: Bug#773881: Bug#773868: Patch to support overlay
Michal Suchanek wrote (05 Mar 2015 11:43:14 GMT) : FWIW I needed these two patches to boot with overlayfs on recent experimental kernels. I think these patches are already included in my branch, thanks to the initial work Steven did, on top of which I've built a bit. More testing would be welcome :) -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85mw3ra5hb@boum.org
Bug#773868: Patch to support overlay
Control: tag 773881 + patch Hi Steven, Steven Shiau wrote (13 Feb 2015 14:25:49 GMT) : I modified live-boot to support overlay from Linux kernel =3.18 a few days ago, by referring to kiwi from OpenSuSE. Attached please find the patch to support overlayfs for live-boot 4. Thanks for working on this! I'm redirecting this discussion to #773881, since #773868 was about a smaller, more specific problem, which has been resolved already. Please send replies to 773...@bugs.debian.org only. This patch doesn't apply on current debian-next branch (live-boot 5.x), which is were overlayfs support should be fixed, since live-boot 4.x is frozen and Jessie won't have overlayfs support anyway. I've imported your patch into Git, on top of debian-next + the other fix I've attached to #773881 a few weeks ago. I've added a few code cleanups and small refactoring bits on top, and the result can be found in the feature/overlayfs branch of the Tails live-boot Git repository: https://git-tails.immerda.ch/live-boot After applying my current patch set to live-boot 5.0~a1-1, I could successfully boot a Tails (Wheezy) system with union=overlay = please review and merge. (Now, after booting our custom GDM Greeter is frozen, so I'll have to investigate deeper, but at least it now mounts the rootfs and boots :) [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=21;filename=0001-Loading-chosen-union-filesystem-s-kernel-module-befo.patch;att=1;bug=773881 Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85egpryofw@boum.org
Re: Cannot load terminal?
Fernando Toledo wrote (09 Feb 2015 15:54:28 GMT) : maybe you can have an error on live-config custom scripts. i found that my custom script failed and then the locales do not set properly We actually set the locales at DM time, after the user has had a chance to pick their preferred one in a GUI, so live-config is not to blame. Thanks for the pointer anyway! -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85lhk6zojp@boum.org
Re: Cannot load terminal?
jnqnfe wrote (08 Feb 2015 18:30:17 GMT) : Does anyone else have trouble loading a terminal in a Debian live image? I've seen that on Jessie when the locales environment was not properly set, IIRC. -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85pp9j5tm3@boum.org
Bug#773881: live-boot: Fails to boot with union=overlayfs
Hi again, The workdir needs to be an empty directory on the same filesystem as upperdir. In our case, upperdir is /live/overlay/, which itself is a tmpfs mountpoint. I assume we can't put workdir *inside* upperdir, so to satisfy the condition quoted above, we probably have to go on mounting a tmpfs on /live/overlay/, but then use sub-directories within this file hierarchy for upperdir and workdir, as opposed to using it directly for upperdir. I assume we can do that, as neither the /live/overlay/ path nor /lib/live/mount/overlay apparently has never been part of the documented live-boot's interface with the rest of the world, so it can be considered to be an internal implementation detail. If we go this way, then code needs to be adjusted accordingly at least in the 2010-remove-persistence, 9990-misc-helpers.sh and 9990-overlay.sh components. Some stuff in live-tools might need adjustments too. Thoughts? Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85a917m4z5@boum.org
Bug#773881: live-boot: Fails to boot with union=overlayfs
Control: reopen -1
Control: found -1 5.0~a1-1
Hi,
intrig...@debian.org wrote (24 Dec 2014 13:56:26 GMT) :
Boots fails and I get dropped into the initramfs emergency shell, for
various reasons:
* first, mount -t overlayfs is called, while it should be
mount -t overlay
* second, we try to mount the ${UNIONTYPE} (aka. overlayfs)
device, which fails: it should be overlay
These two problems are indeed fixed in 5.0~a1-1.
I experience a new blocking bug, though: in 9990-overlay.sh, we check
if the chosen union filesystem's functionality is available in
/proc/filesystems before we load its kernel module, so I always hit:
panic ${UNIONTYPE} not available.
This is fixed for me by the attached (naive?) patch.
Long-term wise, a better fix might be to load the module iff.
/proc/filesystems doesn't know about it, and then check
/proc/filesystems again. And then it would be good to avoid code
duplication by reusing the is_supported_fs function we already have,
and to improve that function a bit to use the stricter (`cut -f2 |
grep') check that's currently used in 9990-overlay.sh. Thoughts?
* third, the call to mount lacks the workdir= option.
This one hasn't been fixed, and I get:
mount: mounting overlay on /root/ failed: invalid argument
+ panic mount overlay on /root/ failed with option -o
noatime,lowerdir=//filesystem.squashfs/,upperdir=/live/overlay/
Indeed, Documentation/filesystems/overlayfs.txt reads:
mount -t overlay overlay -olowerdir=/lower,upperdir=/upper,\
workdir=/work /merged
The workdir needs to be an empty directory on the same filesystem
as upperdir.
Note that in future versions of overlayfs (see the overlayfs-next
branch in Miklos Szeredi's repository [1]), upperdir= becomes
optional, and in that case workdir= is optional too, but then the
overlay will be read-only. So, my understanding is that for Debian
Live systems to work fine, we will still have to pass workdir=.
Now, since Daniel closed this bug, I'm wondering if I did something
wrong, so just to clarify: Daniel, did you ever see live-boot 5.0~a1-1
work for you with union=overlay?
[1] git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git
Cheers,
--
intrigeri
From d2c32b277296f17a9b0e1f0fec2b563a2afeda6e Mon Sep 17 00:00:00 2001
From: Tails developers amne...@boum.org
Date: Sun, 25 Jan 2015 10:02:40 +
Subject: [PATCH] Loading chosen union filesystem's kernel module before
checking for its functionality to be available in /proc/filesystems.
Otherwise, with union=overlay, we always hit:
panic ${UNIONTYPE} not available.
---
components/9990-overlay.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/components/9990-overlay.sh b/components/9990-overlay.sh
index 92d0355..9282276 100755
--- a/components/9990-overlay.sh
+++ b/components/9990-overlay.sh
@@ -8,13 +8,13 @@ setup_unionfs ()
rootmnt=${2}
addimage_directory=${3}
+ modprobe -q -b ${UNIONTYPE}
+
if ! cut -f2 /proc/filesystems | grep -q ^${UNIONTYPE}\$
then
panic ${UNIONTYPE} not available.
fi
- modprobe -q -b ${UNIONTYPE}
-
# run-init can't deal with images in a subdir, but we're going to
# move all of these away before it runs anyway. No, we're not,
# put them in / since move-mounting them into / breaks mono and
--
2.1.4
Bug#773868: live-boot: Does not include overlayfs support in initramfs, due to wrong kernel module naming
Hi, [redirecting to debian-live@, has this seems off-topic on #773868; please drop the bug report from the Cc list on next reply, thanks.] Michal Suchanek wrote (25 Dec 2014 13:45:11 GMT) : 1) is it worthwhile to have support both for the old overlayfs.ko and the new overlay.ko? I am not aware of anyone except myself who was using old kernels patched with overlayfs which produce overlayfs.ko and I am aware of the change now so this might be a non-issue. I don't think it's worth supporting the old out-of-tree patchset now that there's a final version merged in mainline. 2) what is the reasoning behind renaming /cow to /overlay? It the function of /overlay so different that existing tools using /cow cannot work with it when overlayfs is used? I think many tools work with the directory by just packing up the content and do not really care about the details of the union so a needless change in the directory name would needlessly require updating tools. I do not use these directories for anything myself so I would not know. I assume you're refering to Renaming /live/cow to /live/overlay in anticipation of overlayfs., that I see in the live-boot 3.0~a27-1 changelog entry. This change has been released as part of Wheezy, so I expect any tools that rely on such paths have been updated already. (Not to say I'm a fan of the usual renaming rate in the Debian Live codebase.) Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85oaqh4dqn@boum.org
Bug#773868: live-boot: Does not include overlayfs support in initramfs, due to wrong kernel module naming
Package: live-boot Version: 4.0.2-1 Severity: normal Tags: patch Hi, backend/initramfs-tools/live.hook tries to include the overlayfs kernel module in the initramfs. However, that module is called overlay, so it's never included, and then booting with the union=overlayfs parameter can't work out-of-the-box. I've fixed this in the bugfix/overlay-module branch at https://git-tails.immerda.ch/live-boot = please review and merge :) Once Linux 3.18+ reaches sid, with only overlayfs support and no more aufs, Debian Live systems who want/need to ship a kernel newer than the one from Jessie will need to use overlayfs, so it would be good if live-boot in Jessie supported it. I'll let the maintainer judge. Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/857fxhmd9b@boum.org
Bug#773881: live-boot: Fails to boot with union=overlayfs
Package: live-boot
Version: 4.0.2-1
Severity: normal
Hi,
I've tried booting a Wheezy system (live-boot 3.x) with Linux 3.18
from experimental, udev from wheezy-backports (Wheezy's udev isn't
supported by this new kernel), and union=overlayfs.
I'm manually had the overlay module included into the initramfs, to
workaround the other bug I've just reported.
Boots fails and I get dropped into the initramfs emergency shell, for
various reasons:
* first, mount -t overlayfs is called, while it should be
mount -t overlay
* second, we try to mount the ${UNIONTYPE} (aka. overlayfs)
device, which fails: it should be overlay
* third, the call to mount lacks the workdir= option.
I've verified that the source code in the debian-next branch is
affected as well (but not tested in practice, which seemed futile
given the code hasn't changed). I may work on a fix soonish, but don't
hold your breathe.
It seems that the code would be simpler if we accepted union=overlay
instead of union=overlayfs. Can we do that? Non-experimental Debian
kernels have never supported overlayfs yet, so that should be
fine, no?
Cheers,
--
intrigeri
--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85lhlxcfsl@boum.org
Re: Replacing aufs with overlayfs
Hi, Ben Hutchings wrote (21 Dec 2014 23:20:15 GMT) : On Sun, 2014-12-21 at 21:53 +0100, intrigeri wrote: 1. Due to overlayfs' stack depth limit of 2, until support more than one read-only lower layer is completed, overlayfs breaks live-boot's SquashFS stacking feature; Tails automatic upgrades rely on this feature. The current overlayfs maintainer says it is the top feature request, and has been working on it recently (https://www.mail-archive.com/linux-unionfs@vger.kernel.org/msg00079.html). The code lives in git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git (branch overlayfs-next, currently). Should we expect this to be merged in Linux 3.20? I'm not sure: A first formal pull request was send recently: http://news.gmane.org/find-root.php?message_id=20141209103745.GA32280%40tucsk.suse.de The initial review by Al Viro revealed quite a few problems, that Miklos Szeredi later says have been fixed (9 days ago). Nothing happened since then. Is it an option to get aufs back into the Debian kernel until #1 is completed and reaches mainline? (I could understand that you want to add a deadline if you make such a promise, of course :) I would rather apply the overlayfs patches to support multiple lower layers. Works for me :) Once Al Viro is happy with the current state of the code, I'll let you know (I've just subscribed to linux-unionfs). Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85egrsysi6@boum.org
Re: Replacing aufs with overlayfs
Hi, intrigeri wrote (11 Dec 2014 13:13:43 GMT) : Ben Hutchings wrote (09 Dec 2014 19:55:10 GMT) : Please try the Linux 3.18 packages from experimental (they're not there yet, but should be soon) and check that overlayfs does what you need. Thanks. I'll test it for Tails' usecases (that use aufs a bit more than most other live systems, e.g. our incremental upgrades features uses it) once I find the time to. Here are the results of our preliminary investigations: 1. Due to overlayfs' stack depth limit of 2, until support more than one read-only lower layer is completed, overlayfs breaks live-boot's SquashFS stacking feature; Tails automatic upgrades rely on this feature. The current overlayfs maintainer says it is the top feature request, and has been working on it recently (https://www.mail-archive.com/linux-unionfs@vger.kernel.org/msg00079.html). The code lives in git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git (branch overlayfs-next, currently). Later on the same thread, there are also patches (https://www.mail-archive.com/linux-unionfs@vger.kernel.org/msg00088.html) to make the stack depth limit configurable at runtime, but it was deemed risky by the overlayfs maintainer without more work to check that the stack will be safe. So, our best bet right now seems to wait for the 1 read-only lower layer feature. 2. Whiteouts support *should* work when using SquashFS (for non-directories, using a char device; for directories, using a xattr to make them opaque). Not tested yet, though. We also rely on this feature for Tails automatic upgrades. Is it an option to get aufs back into the Debian kernel until #1 is completed and reaches mainline? (I could understand that you want to add a deadline if you make such a promise, of course :) Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85wq5k208r@boum.org
Re: Replacing aufs with overlayfs
hi, [dropping -kernel@ from the Cc list.] Michal Suchanek wrote (11 Dec 2014 16:08:54 GMT) : This might be interesting. Last time I looked at overlayfs it had hardcoded maximum number of stacked filesyetems iirc. If anyone has time to try it out, I'm curious of the results :) -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85zjat6orn@boum.org
Re: Replacing aufs with overlayfs
Hi, Ben Hutchings wrote (09 Dec 2014 19:55:10 GMT) : Please try the Linux 3.18 packages from experimental (they're not there yet, but should be soon) and check that overlayfs does what you need. Thanks. I'll test it for Tails' usecases (that use aufs a bit more than most other live systems, e.g. our incremental upgrades features uses it) once I find the time to. Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85oara5ny0@boum.org
Re: Testing tails-greeter in Wheezy's Debian Live
Hi, I suggest to send the questions aimed at Tails developers to... Tails developers = tails-...@boum.org. adrian15 wrote (23 Nov 2014 15:42:11 GMT) : 1) I did a search in tails repository packages (apt-file) and there was no live-persist executable. What makes it possible that Tails live cd has such a file? It's in our main Git repository: https://tails.boum.org/contribute/git/ 2) Do you have in mind having a variable inside tails-greeter to disable or hide non-specific Debian Live features like persistence or encription (Yes, I know that Debian Live has persistence but I'm pretty sure it's different from the Debian Live one) ? What do you mean with different from the Debian Live one exactly? That would be useful for not having to fork tails-greeter and have a common base code. Sure. I guess we would be happy to take good patches that make our Greeter more generic :) 3) Both: [...] I don't have the answer to these questions on top of my head. 4) When I install tails-greeter apart from tails-greeter package itself there are some packages that are download from tails repository. These are: python-dbus-dev python-dbus Taking a look at: https://git-tails.immerda.ch/greeter/tree/debian/control?id=tails-greeter_0.8.5 I guess this is happening because your repo versions are newer than the wheezy ones. Should I do apt-pinning into these packages so that the I only fetch tails-greeter from your repository? Yes. 5) I suppose no one in Tails is planning on rewriting tails-greeter into QT instead of GTK, isn't it? Indeed. GTK works fine for us, and we're using GNOME, so it's better integrated and looks nicer. 6) (Kind of offtopic) Any reason why your wheezy dist in your repo has no packages? I wasn't aware we had a wheezy suite. If we indeed have one, well, it's not being used. Our APT repo layout is documented there: https://tails.boum.org/contribute/APT_repository/ Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85fvd9g86j@boum.org
Re: Isolinux and Multi language - How do you want it?
Hi, (answering from memory, no time to check in the code right now.) adrian15 wrote (15 Nov 2014 23:52:19 GMT) : I suspect that current tails DM: * Does not recycle code from live-config which already codes how to change keyboard and locales. Indeed. That's because: 1. live-config isn't meant to be run once the graphical login stage is reached = if someone wants to change that, then they'll have to do the same kind of refactoring that we've done in live-boot for the persistence support. 2. live-config has no facility to change the keyboard layout *live* in the greeter (and indeed, given its purpose is to pre-configure, early during boot, stuff that will run later, it seems to be out of its scope). We do need such a facility, so that the user can enter their persistence passphrase using their preferred keyboard layout. * Does not try to parse all the system available keyboard and locales to build its option dropdowns dynamically at boot but it uses an static list. IIRC, the only hardcoded bit is the language - default country mapping, and everything else is dynamically built at runtime. Not sure when I will have time but I will try to use current tails DM in my debian-live build system and see how it goes. Then I will try to implement what, in my opinion is lacking for being integrated into Debian live. \o/ Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85bno3pk41@boum.org
Re: Isolinux and Multi language - How do you want it?
Hi, Ronny Standtke wrote (27 Oct 2014 14:13:16 GMT) : No. We've refactored and extended live-boot's persistence code a few years ago so that we could do that in our greeter. That's very cool. Could you try to bring this change upstream? The changes I was talking of have been implemented upstream in the first place, and are part of live-boot 3.x. We're taking advantage of this refactoring in a script [1] that's run by our Greeter. [1] https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/usr/local/sbin/live-persist Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85mw8hfsno@boum.org
Re: Isolinux and Multi language - How do you want it?
Hi, [again: (please don't Cc me, I read the list.)] adrian15 wrote (25 Oct 2014 22:54:34 GMT) : This is very nice. That's pretty much what I was thinking of for Rescatux. I might reuse it when it's complete or maybe just now :). :) Does your greeter architecture design will allow to have a non graphical frontend, maybe ncurses based ? One can certainly factor out and replace the GDM and GTK bits, but then there won't be much left to reuse. Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85r3xve1uh@boum.org
Re: Isolinux and Multi language - How do you want it?
Hi, Ronny Standtke wrote (26 Oct 2014 13:48:31 GMT) : A custom dm greeter is very nice but doesn't start it too late to ask questions like: Probably yes if one wants to support all possible Debian live options. Not for the usecases we use Tails Greeter. * Do you want to use persistence? And if yes: No. We've refactored and extended live-boot's persistence code a few years ago so that we could do that in our greeter. o What kind of storage device do you want to use for persistence? We don't allow the user to choose that interactively. A GPT partition with label TailsData, on a removable drive, that contains a LUKS volume is considered to be a valid persistence device in our context. o Do you want to use persistence read-only or read-write? Our greeter does offer this choice. o What kind of encryption to you want to use for persistence? We only support LUKS. * What kind of storage device do you want to use for your live-media? * What kernel parameters (we currently have visual support for nolapic_timer, nohz=off, quiet, splash, debug) do you want to enable or disable when booting? * What other kernel parameters do you want to use when booting your system? * Do you want to boot this Debian Live system or o just check the integrity of your live media? o boot from another device? o just show some info about the hardware? Of course a DM greeter is too late for all this. That's not what this thread is about, though :) Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85wq7n7wui@boum.org
Re: Isolinux and Multi language - How do you want it?
Hi, (please don't Cc me, I read the list.) adrian15 wrote (25 Oct 2014 09:25:19 GMT) : I don't discard modifying and improving your greeter (Language, keyboard, and keyboard options should be bigger and in the center of the screen) FYI, that's WIP already: https://tails.boum.org/blueprint/greeter_revamp_UI/ https://mailman.boum.org/pipermail/tails-ux/2014-October/92.html The boot approach seems universal enough to cover both non Xorg systems and Xorg systems this is why I proposed it in the first place. Accessibility support seems important to me, when aiming at being universal. I doubt one gets that in a boot loader. Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85wq7owk4g@boum.org
Re: Isolinux and Multi language - How do you want it?
Hi, adrian15 wrote (20 Oct 2014 07:03:06 GMT) : 5) Are you already doing this in your Debian Live based project ? How do you do it? We at Tails use a custom GDM greeter: https://git-tails.immerda.ch/greeter I suspect it wouldn't be s hard to extract the Tails-specific bits, and make the rest reusable. Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/857fzvq77p@boum.org
Bug#749109: Bug#748679: Add autoconfiguration script for live-config
Hi Gaudenz, meta: * I'm replying on #749109, as this part of the discussion is about code that's being added to live-config, not to broadcom-sta. * Daniel: sorry for the useless ping sent earlier this month on #748679, I was confused by the remaining tags left there after cloning. * I've tried to clarify the status of these two bug reports in the BTS, and the relationship between them, which seemed very confusing to me initially; sorry if I messed something up. Gaudenz Steinlin wrote (12 Jun 2014 19:07:10 GMT) : - In some parts it looks like it should be a general wlan driver selection mechanism. Which would be great, but then overrides are stored in /usr/share/live/config/broadcom-sta/ and the script is called 1190-broadcom-sta. I've seen broadcom-sta support requested quite often on the Tails user support channels, while I don't remember anything similar for other drivers, so I say let's get the ad-hoc support for broadcom-sta in first, hopefully in time for Jessie, and then we'll see if/how it can be generalized. Fair enough? - It uses 14e44 as a first filter in the script. While it's true that the ID of all currently supported devices starts with this string, the broadcom vendor ID is only 14e4. The last 4 is part of the device ID. - The blacklisting logic is the wrong way around. If broadcom-sta is selected as a driver, all entries in /etc/modprobe.d/broadcom-sta-dkms.conf should be blacklisted. If it's not selected, they should NOT be blacklisted. Additionally the wl kernel module should be blacklisted in this case. - checking for a state file makes this script basically useless with persistency on removable media. When moving to live media (ie USB stick) from one system to another you want to rerun this script each time. State files are nice for user preferences, but I don't see a use case for them for hardware configuration. Care to provide a patch that fixes these problems? Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85zjf0933u@boum.org
Re: Debian image failed to boot
chals wrote (05 Nov 2013 12:41:28 GMT) : On Mon, Nov 4, 2013 at 11:00 AM, intrigeri Various USB sticks (especially Sandisk) these days expose themselves as non-removable (which is actually a correct interpretation of the specs). This may be related. https://tails.boum.org/support/known_issues/#problematic-usb-sticks Very interesting, thanks :) I forgot to mention: as a substitute for live-media=removable, we're likely to add an option to live-boot at some point, so that we are able to specify the UUID of the partition the Live system should be loaded from, and allow booting from devices that expose themselves as non-removable, without having to trust whatever might be on the internal drives. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85vc07dn8k@boum.org
Re: Debian image failed to boot
chals wrote (04 Nov 2013 06:40:02 GMT) : I'm going a bit off-topic here, sorry, but I have personally found problems trying to boot debian live systems using sandisk cruzer usb pendrives. I hold nothing against them, they prove to be very reliable when it comes to storing data. However, booting from them proves (in my case, I insist) to be unsuccessful. And since I have not looked into the issue any further nor I have any clue about the possible reasons, I rest my case here. Various USB sticks (especially Sandisk) these days expose themselves as non-removable (which is actually a correct interpretation of the specs). This may be related. https://tails.boum.org/support/known_issues/#problematic-usb-sticks Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85d2mg1o7t@boum.org
Bug#726536: Processed: bts
Debian Bug Tracking System wrote (03 Nov 2013 11:15:13 GMT) :
Bug #726536 {Done: Daniel Baumann daniel.baum...@progress-technologies.net}
[live-config-systemd] live-config-systemd doesnt work at all
Severity set to 'important' from 'serious'
I'm surprised. If $BINARY_PACKAGE does not work at all is not RC,
I wonder what it takes to make a bug RC.
I would be very glad to be explained the rationale behind this change:
this could make it easier for me, and possibly others, to understand
how this team is handling their bugs. Understanding how a team works
is a must to be able to participate.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/85habt62zg@boum.org
Bug#726536: Processed: bts
Hi again, Daniel Baumann wrote (03 Nov 2013 16:05:24 GMT) : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726536#10 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726536#27 Thank you. [...] there will be never any supported backend for systemd in 3.x anyway. Below, I'll assume this is still open to discussion and proposals. If I've missed the discussion that lead to this decision, please be kind enough to point me to it. If I get to implement what I've proposed mid-October [1], then I would happily support this backend under the packaging team umbrella (be it called Debian Live Project, Live Systems Maintainers or whatever) during the Wheezy lifecycle. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726536#15 In case it was not obvious, my goal here is to enable developers and users of Debian Live systems based on Wheezy to use systemd without having to run alpha software from experimental (this includes Tails). I had a quick glance before I proposed this mid-October, and it seems to me that the fixes needed against the current stable version are not too involved (mostly 51b06113 and probably replacing 35ae4486 with something compatible with Wheezy), so I would be sad not to even try. Note that I don't expect you personally to mentor me along the way, and I'll try hard not to cause any additional workload for you. What do you, and others, think? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85k3gph17y@boum.org
Bug#726536: Processed: bts
Daniel Baumann wrote (03 Nov 2013 17:28:38 GMT) : On 11/03/2013 05:57 PM, intrigeri wrote: I had a quick glance before I proposed this mid-October, and it seems to me that the fixes needed against the current stable version are not too involved [...] just adjusting the boot order is not enough. OK, thanks for the hints. i'm strongly against having half-backed systemd support in 3.x that users are supposed to use/is supposed to work. Perfectly makes sense. we're always making sure that live-* works on the previous stable version. we do encurage people to use it that way, and we do support them doing that. Hmm. An explanation of how things look from my PoV, and how it impacts me both as a user and a (potential) contributor, might be helpful for the live-* project and its users. First, I acknowledge the efforts put into making the debian branches compatible with Debian stable. I think it's important to do it so that contributors have a chance to use their code without waiting for the next Debian stable, even more so since it's often too painful to backport anything non-trivial from debian to debian-old-* (Git is clever with file renaming, but still). However, with my live-* user hat on, with my fair share of experience trying to do so, I must say I've personally given up a while ago on the idea of using the non-stable branches in production. (Nor would I recommend anyone to do so. Everyone has their own needs in terms of where the cursor should be between constantly usable and constantly broken, and surely others have different experiences than me. I would be curious to hear how other live-* downstreams feel about it, but I'm not the one who will draw consequences of such a survey, so I don't intend to start it myself.) A sad consequence of giving up on this, added to the fact that backporting features is a pain, is that it's hard for me to usefully contribute to live-* nowadays. I admit it's not purely a consequence: this is free software, and I'm told I'm welcome to express my thoughts and give a hand. Likely, if I put much more effort into the live-* project, then it could become manageable for me to run non-stable (I would start with a. setting up QA processes and tools to ensure the debian branch doesn't break anything I care about too often; b. helping bootstrap processes to make important decisions collectively; c. thinking the roadmap through together, and more importantly, updating it regularly to get a clearer sense of how we're doing and what others can reasonably expect from us; d. reviewing and testing code from others before it lands into the Debian archive). Unfortunately, these days I have no time to do any substantial part of this, and TBH I'm discouraged by the amount of energy I would need to put in just to make this project a pleasing one for me to feel part of. Hoping it helps. Take care, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85bo21ba35@boum.org
Bug#726536: live-* development release process: making contributions easier [Was: Bug#726536: Processed: bts]
Hi again, (Moving the discussion to the ML as I'm moving it far away from the original topic. Please drop #726536 from the Cc list on next reply.) Daniel Baumann wrote (03 Nov 2013 19:32:31 GMT) : while we do support running the next stable of live-* on the current stable distribution (which is what i've said, not the implication to run 4.x alpha versions), we only recommend people using alpha versions for development/testing purposes. that's why they are marked alpha and currently in experimental only. Fair enough. I'm sure the current development release process has its advantages, but in my experience the result isn't so useful in practice for contributors from downstreams who have a much shorter dev/release/feedback loop than Debian stable. So, I have two proposals that would address my needs and possibly others'. How about making it easier for contributors to backport new features they develop against version N+1 (currently 4.x) to their own (presumably unofficial) version N (currently 3.x) tree they're using in production? As a bonus, I suspect it would make it easier to forward-port into N+1 fixes people develop on version N (e.g. GRML fixes; sure, ideally they would do it in N+1 proper, but I've already explained why it's hard to cover both N and N+1 at the same time, so I understand why they're doing it the way they do). Alternatively, we could ensure the N+1 version in Debian testing is in good shape and usable in production (that's the point of the testing suite anyway): each feature would independently flow into Git, be released as alpha in experimental, and once the most obvious bugs are discovered and fixed, then a given feature could be merged into some other branch, be uploaded to unstable and migrate to the beta version in testing eventually. Of course, the delta would have to be kept as small as possible, else we're just re-introducing the problems that I mentionned earlier. Going this way implies to systematically use topic-branches that can be tested, reviewed and merged independently. That's basically what we do at Tails, and we're putting a release out every six weeks. I'm conscious this adds some overhead, and one loses the linear Git history, but it could avoid the once feature A is stabilized, there's feature B that comes break other things, and as a result the product seen as a whole is not that often usable for a given complex usecase effect. Thoughts, other ideas to fix this annoying situation? wrt/ #726536, clearly, the place to do development is in 4.x and not in 3.x (or even 3.x within wheezy), which is why i emphasised earlier to do systemd stuff in 4.x. after all, we do not want to have a 3.x branch having more features/fixes/$whatever than 4.x. There seems to be a misunderstanding here: I've never proposed to add more features/fixes/$whatever to 3.x than 4.x has. A few weeks ago, you wrote that live-config-systemd 4.x worked, so I was merely proposing to backport these fixes for Wheezy. Anyway, now it appears to be more complicated and I'm giving up. No big deal. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85iow92gh3@boum.org
Re: Bug in USB Live Tails-i386-0.20.1 installation
Hi Karl, Karl Hakmiller wrote (27 Oct 2013 01:53:28 GMT) : Error report was Unable to find a medium containing a live file system insmod /lib/modules 3.10-3-686-pae/kernel/drivers/usb/host/uhci-hcd.ko insmod /lib/inmodules 3.10-3-686-pae/kernel/drivers/hid/hid.ko insmod /lib/modules 3.10-3-686-pae/kernel/drivers/hid/usbhid/usbhid.ko I installed Tails on a DVD disk and ran it live with no problem. Please report Tails issues to the Tails team: https://tails.boum.org/support/found_a_problem/ Thanks! -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85iowjnjsk@boum.org
Bug#726536: live-config-systemd doesnt work at all
Hi, Holger Levsen wrote (16 Oct 2013 14:49:43 GMT) : according to Daniel in https://lists.debian.org/debian-live/2013/10/msg00019.html live-config-systemd 3.0.23-1 is completly broken on wheezy, thus I'm filing this bug, to make users aware and probably remove it from wheezy. FWIW, I plan to try and backport the systemd-related fixes to the live-config Wheezy branch in 2014Q1, so perhaps we could wait a bit before removing the package, now that the problem is documented. Hölger: thanks for filing this bug! Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85li1tw7cf@boum.org
Re: Someone else's customized live build - config options not in the docs
Hi, Zack Weinberg wrote (09 Jul 2013 14:25:15 GMT) : I am trying to customize an already-customized live CD (Tails: https://tails.boum.org/contribute/build/ ) and getting stuck on errors which suggest a version-skew issue, but I can't prove it. For the record, Zack asked on the tails-dev mailing-list too, and I've replied there (as questions about Tails' use of live-build 2.x are better suited there I believe): https://mailman.boum.org/pipermail/tails-dev/2013-July/003253.html Cheers! -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8561wjmwv4@boum.org
Re: Bug#678731: linux-2.6: Please build dummy_hcd and g_mass_storage modules
Hi, Moritz Mühlenhoff wrote (08 Jul 2013 16:22:52 GMT) : How's the state of affairs with libvirt 1.1 from unstable? We (at Tails) have submitted a patchset upstream to add the support we need to libvirt and virt-manager. It's waiting for their review. So, I think we won't need the functionality we've asked for in this bug report. I wouldn't mind if the maintainers closed it. Thanks for caring! Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85fvvnle67@boum.org
Bug#713957: live-config: manpage is wrong about LIVE_NOCONFIGS usage
Package: live-config Severity: normal Version: 3.0.23-1 X-Debbugs-Cc: tails-...@boum.org Hi, TL;DR: live-config(7) pretends that LIVE_NOCONFIGS equals live-noconfig=, which is not the case. As explained in message #45 on #712232, live-config(7) gives these directions about LIVE_NOCONFIGS usage: Everything but the shortcuts that can be configured with a boot parameter can be alternatively also be configured through one or more files. [...] LIVE_NOCONFIGS=SCRIPT1,SCRIPT2, ... SCRIPTn This variable equals the 'live-noconfig=SCRIPT1,SCRIPT2, ... SCRIPTn' parameter. [...] Removing existing config scripts [...] To avoid to always need specifing disabled scripts through the boot parameter, a configuration file should be used, see above. These directions don't work, which is kind of expected (at least for those who wrote the code) as it completely contradict the intended behavior that Daniel was kind enough to explain in message #40 on that same bug report: if you want to have all scripts run except a few, and doing that with variables, then you need to specify both LIVE_NOCONFIGS and LIVE_CONFIG_SCRIPTS in your config file, see the 'live-noconfig=*|noconfig=*)' case in /lib/live/config.sh. Note that the manpage has no mention of _SCRIPTS (LIVE_CONFIG_SCRIPTS' name in 3.0.x), so there's no way one can guess they should set it, just by reading the manpage. In earlier versions of live-config, the documentation previously used to match the actual behavior of the program (I believe the documentation update was forgotten when the behavior changed in commit b018878). So, this is a regression in the documentation, which is why I dare setting normal severity. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/857ghjyhdr@boum.org
Re: install packages persistently on a Debian live system.
Hi, Ronny Standtke wrote (22 May 2013 16:08:37 GMT) : unfortuantely, the persistence feature works only for files I create but not for new packages I install. what should I do in order to retain the new packages I install? We have some proof-of-concept code for this in Tails: Why are you not just using full persistence, i.e. a persistence partition and the persistence kernel parameter? I'm glad you're asking. Tails is the *amnesic* incognito Live system by design, and our users rely on its amnesic property, so any bit of persistence we add must be very targeted. Making the full system persistent is thus not an option for our usecases. Also, as far as I understand it, full persistence may be hard to maintain over system upgrades, and we happen to release every 6 weeks. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85vc6a3y95@boum.org
Re: install packages persistently on a Debian live system.
Hi, atar wrote (21 May 2013 15:28:01 GMT) : unfortuantely, the persistence feature works only for files I create but not for new packages I install. what should I do in order to retain the new packages I install? We have some proof-of-concept code for this in Tails: - design documentation: https://tails.boum.org/contribute/design/persistence/#additional-software-packages - end-user documentation: https://tails.boum.org/doc/first_steps/persistence/configure/#additional_packages There's quite some room for improvement, though. We've recently got some good ideas on how to make this more user-friendly and more secure. I expect these ideas to be dumped to the relevant ticket within the next few days: https://tails.boum.org/todo/remember_installed_packages/ Hopefully this stuff gets good and generic enough, some day, to be added to Debian Live somehow. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85a9nol3m4@boum.org
zram in live systems [Was: zram Usage as Default in Debian (?)]
Hi Daniel, (Moving to -live since I'm going to focus on the Live aspects only.) Daniel wrote (Sun, 08 Jan 2012 22:30:33 +0100): yet another aol from me; i've tested it quite a bit with the idea of enabling it automatically on debian-live systems if the machine as not a certain amount of physical ram available. had only bad experiences with it, so far (worse than without it). Thanks for your insight. The fact that ChromeOS is going to enable zram by default makes me wish to reconsider this topic briefly. I'd rather not start from scratch, so do you remember: * what kind of bad experiences it was? (what metrics?) * what kernel version you were using? * how much memory the test system had? * if the system under test had some disk swap enabled? * how much of the system memory you gave to zram? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85bo9qsdi5@boum.org
Bug#700920: Immediately detect medium from live-media parameter
Hi, Gaudenz Steinlin wrote (19 Feb 2013 10:19:30 GMT) : If no removable or removable-usb device is found after the timeout expires, just boot any live medium available instead of panicing. In Tails [1], we rely on live-media=removable to avoid trusting the content of internal drives. So it's critical for us to have live-boot *always* obey live-media=removable. I've not looked at the details of the proposed patches, so I may be totally wrong about what the exact proposed behaviour would change for us, though. [1] https://tails.boum.org/ Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85wqu41s0q@boum.org
Bug#700920: Immediately detect medium from live-media parameter
Hi, Daniel Baumann wrote (19 Feb 2013 13:21:29 GMT) : On 02/19/2013 01:28 PM, Ronny Standtke wrote: How about a priority list, e.g. live-media=removable-usb,removable,any sounds good. Looks good to me too :) -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85obfgwgoc@boum.org
Bug#700597: Re: live-config-systemd: fails to install: post-installation script returned error exit status 1
Hi, Daniel Baumann wrote (15 Feb 2013 11:19:09 GMT) : On 02/15/2013 11:49 AM, Andreas Beckmann wrote: It's the only package with such a requirement (i.e. host is running systemd, just depending on systemd is fine) making it untestable by piuparts :-( unavoidable with current systemd it seems. I believe that checking for /sys/fs/cgroup/systemd existence is enough to know if the system is currently running systemd. Is it an option to wrap such a check around the systemctl enable call? Digression: does this bug mean that the build system must itself be running systemd in order to successfully build a Debian Live system that uses systemd? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85wqu9hkw1@boum.org
Re: isohybrid-acritox
Hi, (Debian Live readers -- see Andreas' original post there for some context: https://mailman.boum.org/pipermail/tails-dev/2013-February/002587.html) Andreas Loibl wrote (08 Feb 2013 00:43:12 GMT) : So you see this incorporates quite some hacks and is woven into our modified debian-live [6] build-process, so I'm not sure how reusable it is for your purposes, but there is certainly more to do than just typing isohybrid filename.iso with ISOLINUX... ;-) Thanks a lot for all this useful information! We're also using Debian Live here at Tails, and the hacks don't look that scary, but the fact we're not using GRUB2 as our bootloader is probably a blocker. If the first iteration of Debian Live UEFI support uses GRUB2, then it's possible that some of your stuff is re-used. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85sj57ul7m@boum.org
[PATCH] Improving test for /etc/fstab.d support by testing for its existence instead of /run's one.
From: Tails developers amne...@boum.org
E.g. when running Squeeze + initramfs-tools from sid, one has /run in the
initramfs but no /etc/fstab.d, so testing for the (not necessarily correlated)
presence of /run makes live-boot think it's running on Wheezy, and mistakenly
try to use /etc/fstab.d.
---
scripts/boot/3020-swapon |2 +-
scripts/boot/9990-fstab.sh |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/boot/3020-swapon b/scripts/boot/3020-swapon
index 7541c26..e7aed6c 100755
--- a/scripts/boot/3020-swapon
+++ b/scripts/boot/3020-swapon
@@ -29,7 +29,7 @@ Swap ()
LIVE_SWAP_DEVICES=${LIVE_SWAP_DEVICES:-/dev/sd* /dev/vd*}
- if [ -e /run ]
+ if [ -e /root/etc/fstab.d ]
then
# wheezy
_FSTAB=/root/etc/fstab.d/swap
diff --git a/scripts/boot/9990-fstab.sh b/scripts/boot/9990-fstab.sh
index dc3f07b..abc7b23 100755
--- a/scripts/boot/9990-fstab.sh
+++ b/scripts/boot/9990-fstab.sh
@@ -13,7 +13,7 @@ Fstab ()
return
fi
- if [ -e /run ]
+ if [ -e /root/etc/fstab.d ]
then
# wheezy
_FSTAB=/root/etc/fstab.d/live
--
1.7.10.4
--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1359826306-7221-1-git-send-email-intrig...@boum.org
Re: Encrypted persistent partition for Live Wheezy
Hi, debmail...@safe-mail.net wrote (25 Jan 2013 16:14:25 GMT) : + probe_for_fs_label live-rw home-rw persistence Loading /etc/boottime.kmap.gz /dev/mapper/sdb2 + local overlays dev + overlays=live-rw home-rw persistence + dev=Loading + /sbin/blkid -s LABEL -o value Loading It looks like some script has been eating some output it shouldn't have (Loading /etc/boottime.kmap.gz) and passes it through to probe_for_fs_label. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/854ni4bvg5@boum.org
Bug#693250: live-build: wrong copy of files from config/archives/repo.pref.chroot
Hi, Thanatermesis wrote (14 Nov 2012 18:07:05 GMT) : The attached patch solves this problem, which seems to be made by a wrong copy-paste This was applied in Git, thanks. -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85txsnw41d@boum.org
Bug#685791: support apt.conf.d in lb_chroot_apt
Thanatermesis wrote (13 Nov 2012 18:43:42 GMT) : Updated patch for the SID version Looks good to me. I've no live-build 3.x ready to test it (shame on me), so I'll refrain from pushing to Git, though. -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85k3tjw3nh@boum.org
Re: Some decisions on naming and conventions ahead
Hi, Daniel Baumann wrote (03 Oct 2012 07:28:04 GMT) : the following mails are about deciding on some things naming and convention wise. FWIW, I'm reading these threads right now; for every such thread, unless I reply to it before the end of the week, that means I'm fine with the proposed changes. -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85a9vvedim@boum.org
Re: Decision 2 - Name and number of /live/filesystem.* on live media
Hi, Daniel Baumann wrote (03 Oct 2012 08:48:32 GMT) : * read-write live media be 'upgradeable' easily: a user with a big enough live medium can, rather than re-download and re-write an entirely new image, just download the partial squashfs and put it on his stick and change by that the desktop. One thing to be aware of when discussing this kind of feature: it may happen that a desktop environment pulls stuff in that changes what is installed into the initramfs, compared to what standard would (e.g. drm modules were in that case, at some point). And the initramfs is not shipped by those *.squashfs files. Cheers! -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85391nec9v@boum.org
Re: Decision 3 - Name of /lib/live/mount/image
Daniel Baumann wrote (03 Oct 2012 09:21:34 GMT) : assuming nobody else comes up with a perfect generic but suitable name, i'd go with 'medium'. I agree. -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85txu3cxk6@boum.org
Re: live-boot_3.0~b4-1_i386.changes ACCEPTED into unstable
Hi, Debian FTP Masters wrote (27 Sep 2012 11:32:32 GMT) : Changes: live-boot (3.0~b4-1) unstable; urgency=low . * Switching to final name for the persistence configuration file 'persistence.conf' in line with boot parameter. [...] Is this change really meant for the 3.x series, or is this the result of some unfortunate mistake? If it is really meant for 3.x: I wonder what the reason for this switch is, given the Git commit message is voiceless on the matter, which was discussed and decided upon months ago. I'm quite surprised this change happens *now*, because IIRC, the deadline that Daniel set for user interface changes in the 3.x series is now quite far in the past, and that change breaks already deployed persistent volumes that use the old agreed upon name. FWIW, as far as Tails is concerned, either backward-compatibility is ensured, or we'll have to ship a patched live-boot (again), or we'll have to add some custom logics to rename existing deployed configuration files :( Daniel, what about supporting the old filename as well as the new one? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/854nmjfytm@boum.org
Re: speed up boot, faster boot
Hi, Malic Zilyas wrote (30 Aug 2012 07:10:37 GMT) : 2) Is there anyone able to use fedora-readahead on a squashfs? When I try to profile it does not find a good device and gives an empty list. As alternative I use e4rat. (sourceforge). Disabled the ext4 restriction. Profiled and started the preread. This works. Here is how we do it in Tails: * SquashFS files order section on https://tails.boum.org/contribute/release_process/#index4h1 * https://tails.boum.org/todo/improve_boot_time_on_cd/ * config/chroot_local-includes/lib/live/config/-boot-profile and config/chroot_local-includes/lib/live/config/-readahead in our Git repository (bugfix/fix_background_readahead branch) -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85mx1cltjv@boum.org
Bug#685445: Exploring the possibility of an l10n upload of live-build to fix pending po-debconf l10n bugs
Hi, Daniel Baumann wrote (21 Aug 2012 05:12:50 GMT) : On 08/20/2012 11:10 PM, David Prévot wrote: I noticed they are actually fixed in unstable, but the 3.0~a57-1 version contains changes that are not in line with the freeze policy, and I couldn't find any trace of pre-approval or unblock request, thus the intent to fix them via t-p-u. the current live-* stuff will migrated to testing eventually when ready, do *not* touch any of these packages. David: AFAIUI, the rationale is that live-* depends much on the rest of Debian, so some things have to be adapted at the last minute, i.e. after the freeze. This special relationship between live-* and the freeze may be worth discussing for Jessie+1, but I think it's too late as far as Wheezy is concerned. Daniel: given live-* is a special case in a way that makes the standard timeline of l10n work non-applicable, what about providing them l10n with some kind of custom timeline (a bit more detailed than eventually) that helps them schedule their work? Perhaps I'm wrong and it would not help, in which case, David please correct me :) Thank you all for working hard on Wheezy. Cheers! -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85sjbgbozi@boum.org
Bug#681176: live-boot: persistence mounting fails if live-persistence.conf contains source=. stanza
tags 681176 + pending thanks Hi, Nemo Inis wrote (11 Jul 2012 06:13:53 GMT) : I believe the bug is a typo at line 1307 of lib/boot/misc-helpers.sh, which reads: [...] but should read instead: [...] Fixed in Git, thanks! -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85ehog8svn@boum.org
Re: live-boot todo for wheezy
Daniel Baumann wrote (12 Jun 2012 13:53:28 GMT) : what i got from you: * interesting message that in some other combination (squeeze + 'unbackported' initramfs-tools from sid), the current versions of live-boot and live-config from experimental don't work. FWIW, that unsupported combination works well with live-boot 3.0~a35-1 -- case close :) -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85d34bqchl@boum.org
Re: Bug#678731: linux-2.6: Please build dummy_hcd and g_mass_storage modules
Hi, berta...@ptitcanardnoir.org wrote (27 Jun 2012 11:00:22 GMT) : On Wed, Jun 27, 2012 at 04:32:31AM +0100, Ben Hutchings wrote: Yes, but I think it would make more sense to emulate a USB storage device in qemu rather than the host kernel. I do agree. bertagaz and I have spent a bit more time testing and comparing the available options. Our results are summed up there: https://tails.boum.org/todo/automated_builds_and_tests/USB/ tl;dr -- as far as Wheezy is concerned: * qemu-kvm emulates just fine a USB 2.0 mass storage device, and knows how to boot from it; personally, I'd rather use that than a dedicated kernel module. * with qemu-kvm on the command-line: no need for an additional kernel module * with a libvirt stack: a missing interface in some abstraction layer makes it a pain to use the qemu-kvm USB emulation of removable mass storage devices. We are going to request the missing interface to upstream libvirt, but it's unlikely the result thereof is ready in time for Wheezy. So, with my Tails developer hat, we would be happy to use g_mass_storage at least from now to the Wheezy+1 release. I don't know; would be interested to hear other people's opinions on this. I'd be interested too! Cc'ing the Debian Live mailing-list, as there may be folks there who have experience on this topic. Perhaps debian-boot and/or debian-installer should be added to the mix as well, what do you think? -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/851ukzxloc@boum.org
Re: live-build 3.x + fail-safe vs. syslinux
Hi, Daniel Baumann wrote (30 Apr 2012 21:03:19 GMT) : On 04/29/2012 03:14 PM, intrigeri wrote: Is the cleanup of the syslinux templates task described in more details, and perhaps tracked somewhere? basically, the menu should look properly and have dedicated menues for d-i and live, with a set of options. there are a few bugs/wishlists etc. in the bts on live-build and syslinux-themes-debian. Did anyone undertake this task already? If yes, any ETA? ETA end of may; for failsafe, this is supposed to work since the commits in debian-next from yesterday. Any news on this? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85d34tet4i@boum.org
Re: Continuous Integration Testing
Hi Julian, Julian Pawlowski wrote (20 Jun 2012 13:03:36 GMT) : I was wondering if anybody has a working concept to use Jenkins-CI for building and testing live-build ISO images? If yes, how do you handle your build in Jenkins? Do you use OS-Autoinst for automated QA integration tests? We at Tails are in the process of setting up automated builds (using Vagrant) and tests. Some pointers: * we have a long summary of pointers to tools, ideas, and pointers to how others do there: https://tails.boum.org/todo/automated_builds_and_tests/ * automated tests thread on tails-dev mailing-list, that started a few days ago https://mailman.boum.org/pipermail/tails-dev/2012-June/ -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/857gv1eszt@boum.org
Re: live-boot todo for wheezy
Hi,
Daniel Baumann wrote (12 Jun 2012 13:53:28 GMT) :
what i like:
* feedback if current live-boot and live-boot from experimental
work as expected (in particular wrt/ persistency) in (otherwise)
unmodified wheezy and/or sid live-systems (built with live-build
3.x)
I doubt I will find time before DebCamp to test this,
since I have no such test setup ready.
misunderstanding solved?
OK.
To clarify on my side: when asked for regression testing, I tested
things that I've seen working previously. And I've never tested the
sid + live-build 3.x kind of setup. That's why I tested for
regressions against (something very close to) a setup that previously
worked, and reported the regression I found.
This being said, I fully understand that, once I've reported
a possible regression, someone must now check if the regression can be
reproduced in cleaner environments. This is the simplest way to see
if the regression was introduced into live-boot by your recent recent
refactoring etc. work, or into my unclean test environment by
external changes.
If I used a proper initramfs-tools backport to do my tests of the
live-boot you pushed to experimental, would you care about my report,
or am I just wasting my time trying to help you test and debug your
latest work?
absolutely; the squeeze + backports (kernel, initramfs, klibc) is a
priority - we do support and encurage people to use live-{boot,config}
from stable+1 on stable.
This is close enough to what we use at Tails to allow me, I hope, to
test this before DebCamp.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8562apq1si@boum.org
Re: live-boot todo for wheezy
Ian Geiser wrote (15 Jun 2012 15:27:12 GMT) : Can I do the following workflow: 1) Boot up in no persistence mode. 2) Take snapshot of current running system. What do you mean exactly here? 3) Reboot the system with the snapshot in read only mode, and make changes only in the tmpfs overlay. 4) Make further modifications and take a snapshot of these changes. 5) Reboot the system with the aggregate of the prior two snapshots in an overlay and make chances only in the tmpfs overlay. Does that make sense? I'm not sure this very solution applies to the custom mounts paradigm, but there may be another solution, in this paradigm, to the actual problem you are trying to solve :) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85wr38tvrm@boum.org
Re: live-boot todo for wheezy
Ian Geiser wrote (15 Jun 2012 01:59:40 GMT) : I am probably late to the party on this one, but we use snapshots for a mode that the customer can configure the live session and then lock it in. Is that something we can do with custom mounts? Custom mounts have a read-only mode. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85k3z9kyzp@boum.org
Re: live-boot todo for wheezy
Hi, Daniel Baumann wrote (12 Jun 2012 10:41:39 GMT) : first of all, i personally care about three usages: * squeeze with unmodified[0] live-boot/live-config from sid * squeeze plus backports of kernel, klibc, initramfs-tools, with unmodified[0] live-boot/live-config from sid * sid If this was intended to clarify anything, I'm sorry but it did not work that well: the specific stuff you explicitly asked us to give some feedback/testing (which I tried to do) is not part of this list, so I'm now more confused than before. If I used a proper initramfs-tools backport to do my tests of the live-boot you pushed to experimental, would you care about my report, or am I just wasting my time trying to help you test and debug your latest work? wrt/ to initramfs-tools, the 0.106 version from sid will not work properly on squeeze, backporting it needs a few adjustments, see: Thank you. We will look into it. Can you please provide any example of what would fail with 0.106 from sid on Squeeze? (In our tests, it looked like it works, so it would be great to have a failing testcase we can reproduce, to see if we're affected.) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85lijsbrkc@boum.org
Re: live-boot todo for wheezy
Daniel Baumann wrote (06 Jun 2012 17:19:24 GMT) : On 06/06/2012 05:57 PM, Daniel Baumann wrote: i'll look into that later today and upload to experimental, it would be nice if you and anonym could then give some feedback/testing whetever i haven't broken it too much :) done and uploaded. As reported on IRC, I see a regression, on current Tails (which is based on Squeeze), between live-boot 3.0~a27-1 and 3.0~a32-1. The former works fine, while the latter dies in initramfs land: Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... /init: line 218: mountroot: not found done. Begin: Running /scripts/init-bottom ... mount: mounting /dev on /root/dev failed: No such file or directory done. Target filesystem doesn't have requested /sbin/init. Daniel, is that enough to put you on the right track to hunt this regression down? If you want to check it yourself, the working branch is testing, and the failing one is feature/live-boot-3.x, both in Tails Git repository (git://git.immerda.ch/amnesia.git). FTR, both tests are using initramfs-tools 0.106, live-config 3.0~a39-1, and the image was built using the most recent flavour of live-build 2.x. -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85fwa12u4y@boum.org
Re: live-boot todo for wheezy
Hi, Daniel Baumann wrote (04 Jun 2012 16:05:26 GMT) : these are iirc the only things that needs to be done before we can move current live-boot (and live-config) from experimental to unstable: I'm happy to see we are this close! :) * persistency code for overlay and snapshot should be unified so that the mode of operation (snapshot and overlay) is deduced by live-boot from looking at the live-persistence.conf. If we drop snapshots, there's nothing to do here. See bellow. I haven't the big picture in mind right now, so I may be missing something obvious, but even if we do not drop snapshots, it's unclear to me why unifying both modes of operation should be a release blocker for 3.x, given 2.x was happily put out with snapshots and union mounts implementations that were far from unified. Anyway, we don't need to spend any more time discussing this any further before we decide whether we want to drop snapshots. tails people, any takers? *puppy eyes* I don't expect to personally have time to work on live-boot snapshots in the foreseeable future. (On the happy side of things, I will probably have time to work on Tails vs. live-build 3.x at DebCamp.) * what's the last stance on snapshot, do we want to drop it completely? AFAIK, last thing that happened on this front was a discussion about relative flash medium wear, by anonym on May 9 4faa2d13.6070...@lavabit.com: I guess where I'm headed with all this is that snapshots seems obsolete to me. In most cases binds are the better choice. Maybe we don't need snapshots any more? Or have I missed some realistic use case where binds actually wear out flash-based storage quicker than snapshots? This was left unanswered to this day, so I do agree: let's drop snapshots for the time being. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85sje9irbq@boum.org
Re: live-boot todo for wheezy
Hi Ed, Ed Dixon wrote (05 Jun 2012 00:22:09 GMT) : This is easy to say as I am not the one doing the work but, the snapshots feature opens up worlds of possibilities and could definitely be useful in the future. I'd be happy to read about the possibilities you're thinking of, and that are not covered by the new custom mounts implementation :) -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85zk8hirzy@boum.org
Re: Any Idea?
Rui Miguel P. Bernardo wrote (14 May 2012 17:11:28 GMT) : Line 256 in /usr/share/live/build/package-lists/rescue list #enif should be #endif Fixed in Git, thanks. -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85sjf2brxm@boum.org
