tell me the most ass over backward shit you do to keep your system chugging?
here’s mine:
sway struggles with my dual monitors, when my screen powers off and back on it causes sway to crash.
system service ‘switch-to-tty1.service’

[Unit]
Description=Switch to tty1 on resume
After=suspend.target

[Service]
Type=simple
ExecStart=/usr/local/bin/switch-to-tty1.sh

[Install]
WantedBy=suspend.target

‘switch-to-tty1.service’ executes ‘/usr/local/bin/switch-to-tty1.sh’ and send user to tty1

#!/bin/bash
# Switch to tty1
chvt 1

.bashrc login from tty1 then kicks user to tty2 and logs out tty1.

if [[ "$(tty)" == "/dev/tty1" ]]; then
    chvt 2
    logout
fi

also tty2 is blocked from keyboard inputs (Alt+Ctrl+F2) so its a somewhat secure lock-screen which on sway lock-screen aren’t great.

  • cizra@lemm.ee
    link
    fedilink
    arrow-up
    10
    ·
    4 months ago

    Mounting a Samba share and moving my LVM pvolumes of / onto a losetup’ed file on it, while running the system. Bass ackwards.

    • tibi@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      4 months ago

      Did it work? There’s a huge chance of data corruption if you are copying the disk of a running system.

      • cizra@lemm.ee
        link
        fedilink
        arrow-up
        1
        ·
        4 months ago

        It didn’t, but due to unrelated reasons. The root FS was mounted r/w, so the regular IO eventually overwhelmed the network’s ability to copy stuff.

        But no worries, a reboot later, with unmounted FS, I finished the same thing.

        Copying the disk of a running system appears to be fine in LVM. Copying is done block-by-block, and the only thing it has to do to make it atomic is: in case of a conflict (writing into a block that’s being copied right now), postpone writing to a block until it’s copied, then finish the write in the new location. Or else, abort the copy, finish the write, then copy again.