Re: [Tails-dev] An outside of the box proposal re persistence backups
intrigeri, Just an update to share that I: - created a new Tails flash drive with persistence - converted the new persistence to btrfs - booted my usual Tails flash drive and backed up it's persistent volume to the newly created Tails drive - installed btrfs-progs on the new Tails drive At this point, everything about this btrfs persistence volume appears to work normally. I can create subvolumes there and snapshot them. Tails appears happy and, from a user's perspective, nothing appears to have changed. Instead of creating a folder named "Persistent", a production-ready Tails with btrfs could create a subvolume named "Persistent". Snapshots of this subvolume would then capture the state of the user's data at modest cost to storage space. Backing up the user's data would involve a Tails backup drive and one btrfs send / receive operation*. I intend to put some miles on this new Tails btrfs flash drive. regards, alienpup * Using snapshots, a single Tails "backup" drive could accommodate as many backups as space permits. ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] An outside of the box proposal re persistence backups
intrigeri, > Hi alienpup, > > alienpup (2021-08-02): > > The now rather lengthy (lengthy is good) discussion regarding Tails > > persistence backup has not considered the benefits of an alternative > > persistence file system, one designed with fast, easy backups in > > mind. Of the several such file systems that come to mind, btrfs is > > perhaps the easiest to implement. […] > > > > If the Tails persistence volume were a btrfs file system, any backup > > application could be employed to copy data there. The btrfs > > "snapshot" feature would then make what are in effect incremental > > backups simple and fast. These snapshots require very little > > additional storage space, and rather than being something special to > > the btrfs file system, snapshots are basically subvolumes which can > > be browsed and/or mounted. Importantly, any backup application > > running on any other Linux file system can move data into and out of > > a btrfs file system. No walls, no fences, and no special backup file > > formats required (though optional). > > The way I understand your suggestion: > > - This would not, in itself, solve the problem we focused on so far, > that is having backups in the first place (S1 on the blueprint): we > still need $something to copy data to that (btrfs) filesystem on > another storage device. > > - Instead, this could be an optional follow-up step to implementing > backups via the "Clone Persistence in Tails Installer" solution > we've picked so far. It would solve S4 via incremental backups. > > - The implementation draft we have on the blueprint for the "Clone > Persistence in Tails Installer" solution, based on rsync, is > entirely compatible with your suggestion. It does not prevent us > from switching to a different filesystem for Persistent Storage > later, and taking btrfs snapshots before/after updating the backups, > if/when we identify S4 as a priority. > > Correct? Absolutely. Sorry for not being more specific in my last post. Btrfs snapshots would allow us to efficiently preserve data backups already written to the persistence volume. The content of all snapshots, hence a history of user data, would remain accessible to the user. I've long employed rsync in conjunction with btrfs snapshots to facilitate backups. Each of my backup media is formatted btrfs, Each of my computers has user data (/home) on a separate partition formatted btrfs. Boot and system partitions remain ext4. Come backup time, I: - use rsync to copy the contents of the boot and system partitions to a subvolume on the backup drive. - create a snapshot of this subvolume. - create a snapshot of user's data in /home. - use btrfs send/receive to copy this snapshot to the backup drive. Rsync and btrfs each rock. In combination, they're hard to beat. alienpup > ___ > Tails-dev mailing list > Tails-dev@boum.org > https://www.autistici.org/mailman/listinfo/tails-dev > To unsubscribe from this list, send an empty email to > tails-dev-unsubscr...@boum.org. > ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] An outside of the box proposal re persistence backups
All, The now rather lengthy (lengthy is good) discussion regarding Tails persistence backup has not considered the benefits of an alternative persistence file system, one designed with fast, easy backups in mind. Of the several such file systems that come to mind, btrfs is perhaps the easiest to implement. Recent Linux kernels support btrfs fully, and most distros come with btrfs tools installed. If the Tails persistence volume were a btrfs file system, any backup application could be employed to copy data there. The btrfs "snapshot" feature would then make what are in effect incremental backups simple and fast. These snapshots require very little additional storage space, and rather than being something special to the btrfs file system, snapshots are basically subvolumes which can be browsed and/or mounted. Importantly, any backup application running on any other Linux file system can move data into and out of a btrfs file system. No walls, no fences, and no special backup file formats required (though optional). The btrfs wiki at kernel.org documents just about everything there is know about btrfs: https://btrfs.wiki.kernel.org/index.php/Main_Page regards, alienpup ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Question: Tails in undercover mode?
All, A quick follow-up to suggest that clearing the Tails screen saver/slide show require the key-press combination used to invoke it. A passer-by could otherwise restore the screen and reveal Tails with a single key press. This should perhaps be the case even when an admin password is set, as Tails' password entry screen doesn't look very "Windows". regards, alienpup alienpup wrote: > All, > > I believe hiding Tails' UI would prove too resource intensive and > ultimately futile. It just can't be done and maintained well enough to > fool sharp-eyed observers. After all, the first thing a passer-by does > is study your screen. It's human nature and very hard to resist. > > Tails users could however benefit greatly from a simple slideshow > screen saver that can be invoked instantly. Tails could ship with a few > uninteresting "stock" images and provide users the option of adding > more. Once invoked, Tails could not be distinguished from Windows. > Screen locking would remain dependent upon setting an admin password. > > regards, > alienpup > > > geb wrote: > > Hello, > > > > Hans: > > > Dear list, > > > > > > I am wondering, why tails no more get an undercover mode. IMO it is very > > > dangerous for users, if their window manager is not looking like the > > > normal > > > window manager used everywhere, especially in countries, where any > > > "strange" > > > desktop might cause attention on authorities. > > > > > > This problem could be easily solved. Most users are running either > > > windows or > > > MacOS. For windows you can just use XFCE + kali-undercover, for > > > Mac-design > > > there are several windowmanagers available (there is coming ElementaryOS > > > in my > > > mind). > > > > > > As you do only need the window-manager design, there should be no risk > > > change. > > > > > > I might remember, tails got this option some years ago, but somehow this > > > is > > > gone. Dunno why > > > > This camouflage option has been removed because the theme that proposed > > this feature was not working anymore, and because of lack of resources > > to work on it. You can read a bit more about that here : > > > > https://gitlab.tails.boum.org/tails/tails/-/issues/10830 > > > > https://gitlab.tails.boum.org/tails/blueprints/-/wikis/update_camouflage_for_jessie/ > > > > Unfortunately, the problem is not that easy to solve. As you can see on > > the previous links, reintroducing this feature using gnome themes would > > requires lot of work (at least at the moment these links were updated). > > > > Proposing other desktop-environments may looks simpler, but it would > > requires even more work, for UX, documentation, testing, ensuring > > everything works fine, keeping the image small enough etc, not only when > > integrating these desktop environments, but also for every releases. > > > > That said, maybe things have improved since last updates on the previous > > links. So if you are interested to give a deeper look of how it could be > > done in practice, that may be a small but important step :-). I did a > > quick testing of https://www.gnome-look.org/p/1216281/ (which is nice > > also because it has been maintained since a few years now). It seems the > > menus are only for Cinnamon, but maybe I did not tested it enough. > > > > -- > > geb > > ___ > > Tails-dev mailing list > > Tails-dev@boum.org > > https://www.autistici.org/mailman/listinfo/tails-dev > > To unsubscribe from this list, send an empty email to > > tails-dev-unsubscr...@boum.org. > > > ___ > Tails-dev mailing list > Tails-dev@boum.org > https://www.autistici.org/mailman/listinfo/tails-dev > To unsubscribe from this list, send an empty email to > tails-dev-unsubscr...@boum.org. > ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Question: Tails in undercover mode?
All, I believe hiding Tails' UI would prove too resource intensive and ultimately futile. It just can't be done and maintained well enough to fool sharp-eyed observers. After all, the first thing a passer-by does is study your screen. It's human nature and very hard to resist. Tails users could however benefit greatly from a simple slideshow screen saver that can be invoked instantly. Tails could ship with a few uninteresting "stock" images and provide users the option of adding more. Once invoked, Tails could not be distinguished from Windows. Screen locking would remain dependent upon setting an admin password. regards, alienpup geb wrote: > Hello, > > Hans: > > Dear list, > > > > I am wondering, why tails no more get an undercover mode. IMO it is very > > dangerous for users, if their window manager is not looking like the normal > > window manager used everywhere, especially in countries, where any > > "strange" > > desktop might cause attention on authorities. > > > > This problem could be easily solved. Most users are running either windows > > or > > MacOS. For windows you can just use XFCE + kali-undercover, for Mac-design > > there are several windowmanagers available (there is coming ElementaryOS in > > my > > mind). > > > > As you do only need the window-manager design, there should be no risk > > change. > > > > I might remember, tails got this option some years ago, but somehow this is > > gone. Dunno why > > This camouflage option has been removed because the theme that proposed > this feature was not working anymore, and because of lack of resources > to work on it. You can read a bit more about that here : > > https://gitlab.tails.boum.org/tails/tails/-/issues/10830 > > https://gitlab.tails.boum.org/tails/blueprints/-/wikis/update_camouflage_for_jessie/ > > Unfortunately, the problem is not that easy to solve. As you can see on > the previous links, reintroducing this feature using gnome themes would > requires lot of work (at least at the moment these links were updated). > > Proposing other desktop-environments may looks simpler, but it would > requires even more work, for UX, documentation, testing, ensuring > everything works fine, keeping the image small enough etc, not only when > integrating these desktop environments, but also for every releases. > > That said, maybe things have improved since last updates on the previous > links. So if you are interested to give a deeper look of how it could be > done in practice, that may be a small but important step :-). I did a > quick testing of https://www.gnome-look.org/p/1216281/ (which is nice > also because it has been maintained since a few years now). It seems the > menus are only for Cinnamon, but maybe I did not tested it enough. > > -- > geb > ___ > Tails-dev mailing list > Tails-dev@boum.org > https://www.autistici.org/mailman/listinfo/tails-dev > To unsubscribe from this list, send an empty email to > tails-dev-unsubscr...@boum.org. > ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Call for testing: USB image second boot failure
u wrote: > Hi! > > some time ago, we started distributing USB images alongside our ISO > images, so that the installation process would get easier (especially > for Windows and macOS users) and faster (by getting rid of the need to > install an intermediary Tails device). > > Using the USB image, on first boot the system partition is resized > automatically. This seems to fail on some computers, but we have very > little data about the usefulness of a proposed fix. > > You can help > > > This is why we ask you today to help us test a fix, even and > _especially_ if you did _not_ encounter this bug of a Tails device not > booting a second time. The idea is that we want to see if our fix > results in regressions for users for whom it initially worked. [1] > > Interested? > === > > - Please download the .img file from > https://nightly.tails.boum.org/build_Tails_ISO_bugfix-16389-recompute-chs/builds/lastSuccessfulBuild/archive/build-artifacts/ > > - Install the image to a USB key, following the procedure indicated > here: > > - from Windows https://tails.boum.org/install/win/usb/ > - from macOS https://tails.boum.org/install/mac/usb/ > - from Linux https://tails.boum.org/install/linux/usb/ > > - Boot your computer with this Tails device once. Shut down. > - Boot your computer with this Tails devide again. > > - Please report back in reply to this email (public mailing list): > > - Brand and model of the USB stick and the computer used for testing > - Did the device boot a second time? > - If not: did you see an error message on boot? What did it say? > > Thank you for your help! > u. > > [1] If you're interested in the details: > https://redmine.tails.boum.org/code/issues/16389 u. tails-amd64-bugfix_16389-recompute-chs-3.14-20190516t1708z-a620eccd12+sta...@a7a5403a86.img successfully installed to a 16GB Kingston Data Traveler flash drive using dd under Arch Linux, booted and re-booted on all three of the systems available to me. None of these systems previously experienced the second boot failure: HP Pavillion dm4 laptop Lenovo Thinkpad T410 laptop Mintbox Mini AMD APC desktop L The output of lspci -nn executed on each system is attached. regards, alienpup lspci-nn-hp-pavilion-dm4.out Description: Binary data lspci-nn-lenovo-thinkpad-t410.out Description: Binary data lspci-nn-mint-box-mini.out Description: Binary data ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release schedule for Tails 3.12
anonym wrote: > anonym: > > Testers, please let me know if you are available on: > > > > * 2019-01-19, to test Tails 3.12~rc1. > > Testers, how bad would it be for you if I tell you on the 18th that I > will need another day to prepare the release, so testing will happen on > 2019-01-20 (and maybe evening/night of 19th)? > > Cheers! anonym, Not a problem here, but I wonder if an RC deserves more than 24-48 hours of testing. Time zones and the fact that (ideally) half of our testers are asleep at any given moment also eat into a small testing window. Over to you to determine how much testing is enough, but FWIW. alienpup ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] GDM
rajer bosho wrote: > Hi > > i appreciate the good work of all buddies for all the humans around the > word by respecting privacy.-good work. > > 1. trying to start version tails amd 64_3.11 recently upgraded from 3.10. > > 2. secondly,the error stated as " Error starting GDM with your graphics > card: Intel corporation core processor Integrated Graphics Controller > [8086:0046] (rev 02). > > 3. i tried the workaround adding xorg-driver=intel to the startup option, > nothing worked. > > 4. in the version 3.10 i had no such problem. Tails went smooth. > lastly, i downloaded 3.11 version and followed usual procedures but > failed > stating the above (2) > message. > please, do the needful to start tails again.i below attach image for > your > reference. Sadly, I must report the same problem with 3.11 on my Lenovo T420 laptop. v3.11 boots to a blank screen. The "xorg-driver+intel" boot switch (and removal of "quiet") reveals the same warning regarding the failure to launch GDM. The T420 reports the same graphics controller as rajer's computer does ([8086:0046] (rev 02)). I must report also that while booting 3.11 on my HP DM4 laptop is successful, Tails does not detect the laptops internal WiFi card. All other Tails releases since 3.9 have detected the internal card on the DM4. Tails 3.10.1 runs fine on both of the above computers. regards, alienpup ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] inclusion of xinput in the main build of Tails
intrigeri wrote: > Hi, > > HumMy: > > i need this software in the main build because i have a laptop with > > accupoint that keeps the mouse moving all the time making touchpad > > impossible to use. > > Could you please point me to what this "accupoint" thing is? > A DuckDuckGo search yields many results that seem unrelated. > > > via persistence options, you can have it installed, but not > > available at login time and so you can't really use the dotfiles > > feature to script your way through because the program won't be > > installed when the scripts are run. > > One way to solve this is to have your post-login script wait for > tails-additional-software-install.service to have started. Once this > is done, the Additional Software are installed. intrigeri, This provides some info. See the "Naming and brands" table for affected laptops: https://en.wikipedia.org/wiki/Accupoint regards, alienpup ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release schedule for Tails 3.9
intrigeri, I will be pleased to reserve the time required to test both the 3.8 RC build(s) and tentative release builds. I'm in a position to use each more or less exclusively while testing. Other available distros include Debian and Arch derivatives. alienpup you wrote: > Hi! > > it's not clear who will be the release manager for Tails 3.9 yet but > we're well into its development cycle and lots of great, intrusive > work has to land in time for that release, so I figured we need at > least a fallback release schedule to provide guidance to everyone who > needs it. > > If you're the lead/manager for a team that's affected by this > schedule, please ensure your team-mates are planning their > work accordingly. > > So, in case I end up playing the role of backup RM for Tails 3.9, > here's how it's going to happen: > > - August 15: feature freeze > >Everything you want to see in Tails 3.9 must be merged into our >devel branch by 17:00 CEST that day. > >Particularly for big chunks of work, please do submit them for >review to the foundations team ahead of this date: as the deadline >approaches, quite a few of us will be busy completing their own >work, so let's be excellent to each other by not assuming they're >available for last minute reviews or post-super-late-review fixes. >Better talk to each other in advance to schedule time for these >things ♥ > >If all this is very nice but too vague, as a rule of thumb: > > - if you're a developer, better submit your large chunks of work by >August 5 and schedule enough time for post-review fixes during >August 5-12 > - if you're a reviewer, please consider scheduling time for >reviews during August 5-15 > > - August 16: build tentative 3.9~rc1 > > - August 17: test and release 3.9~rc1 > >→ manual testers: please tell me privately if you can make it. > > - August 18-30: small, targeted, not too risky fixes may be granted >freeze exceptions > >Reviewer time will be a very scarce resource during that period so >please anticipate. If you can already guess that you'll need >a bigger freeze exception that does not fit into these rules, talk >to me ASAP. > >Please try hard to avoid changing user-visible strings during that >period: I'd like translators to have a couple weeks to do the great >amount of work I'll drop on their plate on August 17, so we release >our fancy new features in 3.9 with the best localization they can >get :) > > - September 4: build 3.9 tentative ISO > > - September 5: test and release 3.9 \o/ > >→ manual testers: please tell me privately if you can make it. > > Cheers, > -- > intrigeri > ___ > Tails-dev mailing list > Tails-dev@boum.org > https://mailman.boum.org/listinfo/tails-dev > To unsubscribe from this list, send an empty email to Tails-dev- > unsubscr...@boum.org. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
