Announcement

Collapse
No announcement yet.

Fedora Workstation Brainstorming A Possible GUI-Based Linux Recovery Environment

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Neat. Finally they've come up with a real-world application of Gnome

    Comment


    • #32
      Originally posted by alem View Post

      Sure, but user data locations are know, especially for non tech user. Moreover, how a non expert user can know if a certain application have stored files outside his home?
      The default user data location is known but we can't assume that user would be ok with doing an automatic reset back to a snapshot without even being asked. When you are dealing with user data, you must always ask first. Packaging guidelines cover where applications within the distro are allowed to store configuration and system resets aren't about preserving application configuration anyway.

      Comment


      • #33
        Originally posted by RahulSundaram View Post

        The default user data location is known but we can't assume that user would be ok with doing an automatic reset back to a snapshot without even being asked. When you are dealing with user data, you must always ask first. Packaging guidelines cover where applications within the distro are allowed to store configuration and system resets aren't about preserving application configuration anyway.
        I totally agree, in fact I'm not talking about resetting data but restoring the system.
        Usually you can't break the OS with your user data but with kernel or driver updates.
        If the system was able to try to reset back to a snapshot of the core software and configuration (without touching user's data) the process could be automated.

        If before every update the OS packed the current working core software and configuration (kernel version, drivers, ...) and the boot loader added a new entry to his list, the user would be able to just choose one of the latest working configuration. No GUI or CLI commands required.
        This is something similar to transactional approaches used in nixOS or coreOS (now Fedora CoreOS)

        Comment


        • #34
          Originally posted by alem View Post
          Usually you can't break the OS with your user data but with kernel or driver updates.
          If the system was able to try to reset back to a snapshot of the core software and configuration (without touching user's data) the process could be automated
          It is certainly possible to mess up your desktop login with user data misconfiguration. Even if you are only talking about system configuration, you still want to prompt the user before you take such actions. If something goes wrong with it or now the system behaves differently because it was reset, they would atleast be aware of what caused it. You cannot just do it in the background. This are a wide variety of recovery scenarios where you want to prompt users through a series of steps before you take any action, a boot loader configuration works for some recovery tasks but not everything.

          Last edited by RahulSundaram; 05 April 2022, 08:21 AM.

          Comment


          • #35
            I do many Distro reviews for my needs (I write some utilities in C). I also reformat, validate, and decorate a /etc/fstab or equivalent file, so that a reboot will function. However, on some occasions, the fstab gets rejected by systemd and Fedora loads with all partitions but /tmp, in read-only mode.
            Recovery is a tedious, long effort.

            The error recovery is not about the graphics interface for video, but is about SELinux being set because a user forgot to issue a command systemctl daemon-reload, or because systemd was unhappy about the fstab.

            The promoted Fedora "workstation live" ISO does not have the proper repair software, but fortunately, the Fedora "Everything.iso" does have it.
            Here are a few lines of a validated/formatted /etc/fstab...
            Code:
            # /etc/fstab
             
            #<file system> <mount> <type> <options> <dmp pass> <xref> <label/uuid>
            UUID=302a5faf-180d-47c0-94f7-5cbe2eaaef0c /nvme1avail ext4 defaults,noatime,noauto,user 1 2 #/dev/nvme0n1p1
            UUID=AAD5-7B0E /boot/efi vfat umask=0077,shortname=winnt 0 2 #/dev/nvme0n1p2 F36EFI
            UUID=380b22ab-5a09-4101-acab-276be08e6183 /boot ext4 defaults,noatime 1 2 #/dev/nvme0n1p3 F36boot
            UUID=0bbd3f52-6d7a-456d-8475-e35137d6932f /Development xfs defaults,noatime 0 0 #/dev/nvme0n1p4 Development
            UUID=50ed96c9-b5b8-452f-ad9c-9b5e59168f0b /LinuxStuff xfs defaults,noatime 0 0 #/dev/nvme0n1p5 LinuxStuff
             o-o-o-o-o-o- etc
            The output is column formatted, easy to maintain.
            The formatting program is gpl3 available, just send me a request. I wrote it in 2016 and I have been using it and tweaking it for improvements for a few years.
            Last edited by lsatenstein; 06 April 2022, 10:41 AM.

            Comment


            • #36
              The link to the tar file with the formatting source.

              https://drive.google.com/file/d/1958...ew?usp=sharing

              Comment


              • #37
                GUI = more moving parts = much more error prone = horrible idea for RECOVERY, where things already WENT wrong.

                Comment


                • #38
                  Originally posted by anarki2 View Post
                  GUI = more moving parts = much more error prone = horrible idea for RECOVERY, where things already WENT wrong.
                  In my experience, that's never usually an issue. As long as the recovery system is an isolated atomic system in itself, separate from the other parts of the system that can be upgraded, added or removed, then it's usually fine. Windows can get along just fine with a GUI recovery because you can't modify or uninstall the display stack or critical "packages" like you can in Linux (even if it's the package manager's fault and not yours). As long as the recovery system is outside of the grasp of the package manager's ability to mangle the system, it'll be fine. Worse case scenario is the hardware itself is damaged, in which case I think a GUI recovery is even better because then it becomes extremely obvious what's wrong.

                  Comment


                  • #39
                    Originally posted by anarki2 View Post
                    GUI = more moving parts = much more error prone = horrible idea for RECOVERY, where things already WENT wrong.
                    Plan 9 was built with a GUI in mind.

                    Comment

                    Working...
                    X