1. 10 Jul, 2020 3 commits
  2. 19 Oct, 2019 1 commit
    • segfault's avatar
      Fix escape sequence in tails-gdm-failed-to-start.service (refs: #17166) · f27236ef
      segfault authored
      The command works, but produces this message:
      
          /lib/systemd/system/tails-gdm-failed-to-start.service:11: Ignoring
          unknown escape sequences: "MAX_LENGTH=254 ;       PREFIX="Error starting
          GDM with your graphics card: " ;       SUFFIX=". Please take note of
          this error and visit https://tails.boum.org/gdm for troubleshooting." ;
                MAX_VIDEO_CARD_LENGTH=$(($MAX_LENGTH - $(echo -n "$PREFIX$SUFFIX"
          | wc -c))) ;       VIDEO_CARD=$(lspci -d::0300 -nn | sed -E "s,.* VGA
          compatible controller \[0300\]: *,," | cut -c
          "1-$MAX_VIDEO_CARD_LENGTH") ;       /bin/plymouth display-message
          --text="$PREFIX$VIDEO_CARD$SUFFIX"      "
      
      Adding a backslash fixes that and the command still works.
      f27236ef
  3. 10 Aug, 2019 1 commit
  4. 11 Jul, 2019 2 commits
  5. 18 Feb, 2018 3 commits
  6. 08 Feb, 2018 1 commit
  7. 03 Jan, 2018 1 commit
  8. 11 Dec, 2017 2 commits
    • intrigeri's avatar
      Also display a hopefully useful message with plymouth when GDM has failed to... · 7f1d753b
      intrigeri authored
      Also display a hopefully useful message with plymouth when GDM has failed to start Xorg 5 times (refs: #14521)
      
      This ugly hack is needed because we have to keep count of the failures and kill
      GDM ourselves, otherwise the gdm3 process is still running and the service is in
      "active (running)" state, so OnFailure=tails-gdm-failed-to-start.service does
      not take effect.
      7f1d753b
    • intrigeri's avatar
      Display a hopefully useful message with plymouth when the GDM service fails (refs: #14521) · 2d669b71
      intrigeri authored
      This sets up the foundations for displaying a useful error message, but it does
      not cover the case when GDM repeatedly tries to start Xorg and fails, which is
      the most interesting one wrt. #14521: when this happens the gdm3 process is
      still running and the service is in "active (running)" state, even once GDM
      manages to put itself in a bad enough shape that it can't even retry starting
      Xorg anymore.
      
      One way to trigger such a failure is:
      
         systemctl kill --signal=9 gdm
      2d669b71