# Big picture We want to decrease the number of dimensions of the matrix of what a Tails USB stick can look like, in particular when deviations from the norm are likely to cause problems later on, both to the user, to our bug triaging efforts, and for future development work. We want to avoid the user starting to rely more on a USB stick that is in a poor shape (regardless of whether said poor shape is caused by failing hardware, software bugs, or user's habits to unplug the USB stick). Rather than trying harder to make corrupted Tails USB sticks limp along and pretend to work for longer (which can cause all sorts of problems for the user, that are hard to predict for us and for them), we will prioritize predictability and data safety. To achieve this, when booting from a USB stick, when some sort of MBR or GPT corruption is detected, or when the system partition was not resized, or when the filesystem on the system partition was not resized, we will replace the way !1611 reported such errors to the user with this logic: * if there's no Persistent Storage: * if case 3 (from https://gitlab.tails.boum.org/tails/tails/-/issues/20163#note_234914, currently reported as `partitioning-corruption` in the Journal, but not to the user; note that we now know that in practice, it's not a given that we will be able to create a Persistent Storage on an affected USB stick): report in the session with zenity, at least until we convince ourselves that we should treat those errors as fatal too * else: report in Welcome Screen, don't allow login * if there's a Persistent Storage: report and strongly encourage the user to clone to a new USB stick Original idea: https://gitlab.tails.boum.org/tails/tails/-/issues/20505#note_242379 # Design See https://gitlab.tails.boum.org/tails/tails/-/issues/20531#note_246290 # To Do Different cases: * [x] Case A: There is no Persistent Storage → forbid login * [x] Design the UI in the Welcome Screen * This might build upon what we shipped in !1611, whose strings are documented in https://gitlab.tails.boum.org/tails/tails/-/issues/20505#note_242373 * [x] Decide whether we want to do A/B testing in this case (e.g. don't allow login 10% of those USB sticks, and increase by 10% in each following release?); if we do that, make the A/B decision in a deterministic manner purely in function of a stable hardware identifier of the USB stick * Case B: There is a Persistent Storage → recommend migrating * [x] Design the Zenity dialog * This might build upon what we shipped in !1611, whose strings are documented in https://gitlab.tails.boum.org/tails/tails/-/issues/20505#note_242373 * Case 3: There is no Persistent Storage; we might be able to create a Persistent Storage on an affected USB stick but this can cause trouble later on → recommend migrating * [x] Design the Welcome Screen changes and Zenity dialog Other To Do's: * [x] Reference these errors message in the installation doc? * [x] Implement the design * [x] Check if there's useful code to salvage from tails/tails!1529 * [x] Implement handling of Case A * [x] Implement handling of Case B * [x] Implement handling of Case 3 * [x] Verify that the filesystem on the system partition was resized (some of the main failure modes on tails/tails#20163 lead to the partition being resized but not the FS, but it seems we're not checking that yet) * [x] Track follow-ups elsewhere * [x] Analyze user feedback about Case 3: either convince ourselves that we should treat those errors as fatal too, i.e. prevent login entirely, or go back to the drawing plate → tails/tails#20705 # Timeline - October: UI design - don't start coding before good progress is made on #20524+ and on the after-sales service for #15451+ - December: get it ready and merged - January: release in 6.11 - January: after-sales service - 2025: context-switch away from Persistent Storage robustness