• 0 Posts
  • 23 Comments
Joined 4 months ago
cake
Cake day: April 7th, 2026

help-circle
  • mlfh@lm.mlfh.orgtoLinux@programming.devInstant boot Linux?
    link
    fedilink
    English
    arrow-up
    21
    ·
    edit-2
    1 day ago

    I was really curious about the possibilities here for a re-usable “saved hibernation state”, and did a lot of digging around and testing in exploration of that idea. Please note that the following is wacky as hell and is not a good way to run a server at all, but is possible:

    1. Set up a swap partition that can fit your full system memory.
    2. Enable swap and set up hibernation (https://wiki.archlinux.org/title/Power_management/Suspend_and_hibernate#Hibernation )
    3. Hibernate your system to the swap partition in the state you want to use as your perpetual checkpoint.
    4. Boot from a live usb, NOT your regular system (when the linux kernel boots with the resume=uuid=xxxx parameter which enables hibernation/resume, it checks that partition for a hibernation signature and immediately clears it, preventing multiple boots of the same hibernated state. You need to preserve this signature).
    5. From the live usb system, copy the swap partition that contains your main system’s hibernated state to an .img file on a filesystem mounted from one of your main disks.
    6. Reboot into your main system.
    7. Set up a scheduled job that triggers every time your system resumes (could use a systemd service with After=hibernate.target and WantedBy=hibernate.target) that does the following:
      1. Disables swap on the swap partition you set up (keeping the resume=uuid=xxxxx kernel parameter that points to it).
      2. Writes the .img file to that partition
    8. Use your system as you want, and power it off when done (do not suspend or hibernated again).

    The next time you boot, the kernel will load the saved hibernation state from the partition specified in the resume= parameter, as if it had just been hibernated instead of halted.

    Now for the downsides:

    • It’s very dangerous to resume a system’s memory to one state with storage in a different state (the official kernel docs for this have a giant red warning banner saying “If you touch anything on disk between suspend and resume… …kiss your data goodbye.” https://docs.kernel.org/power/swsusp.html ).
    • Resuming from hibernation isn’t really that much faster than cold booting a lean system, if speed is your primary goal.
    • The scheduled write job will hit you with a bunch of heavy io every time you boot/resume, probably negating any speed benefits of the whole thing anyway.

    Anyway, now that we know it’s possible, if you really can’t suspend/resume in a non-wacky way I recommend instead just booting normally and trying to make the boot process as fast as possible. A good guide here: https://wiki.archlinux.org/title/Improving_performance/Boot_process

    If booting quickly to a static state is the goal, alpine diskless mode might be a good option: https://wiki.alpinelinux.org/wiki/Diskless_Mode


  • You’re interacting with a server managed by someone else - everything that flows through it is ultimately under their control, and you’re trusting them with it. They could log everything, or nothing. Even if storing passwords hashed is the default, an admin can replace any part of the code they want, so they could grab and store raw passwords if they really wanted to, or take over your account and impersonate you, or any number of other unlikely but possible things.

    So use a unique password, and only provide data (your real source ip, your saved posts, views, votes, etc) that you trust the admins of your server with.



  • The one recurring unsolveable problem I run into is not being able to kill a process that’s stuck in D state. If something has broken in the layers between that process and hardware (not uncommon when working with old cheap “box of scraps” hardware, as I like to do), it can get stuck forever and you have to kill the whole system, sometimes forcibly. Not the end of the world, but it sucks when it happens.





  • I run the immich container stack on a vm with 4GiB memory and 2 cores, with db on local disk and external libraries over smb, and it runs perfectly fine. I offload the machine learning jobs to another sometimes-on machine, sometimes, but don’t really need to unless I’m dumping thousands of new images into the external library at a time and want it all to process quickly.


  • Looks like both of your vms probably have the same mac address - the 172 ip address is likely a self-assigned fallback when the dhcp server replies to the second vm that it can’t give it an address. Double-check and make sure the mac address in each vm’s proxmox network adapter settings match your pfsense dhcp reservations, and let me know if that resolves it.






  • You have enough failures on each disk to make me suspect an issue with the usb-connected drive bay. I ran into similar issues with a cheap pci-e sata adapter, where little hiccups and latency in the communication layer would cause zfs to take disks offline randomly. Read, write, and checksum errors would slowly accumulate across all of the disks. Switched that machine to a proper enterprise hba, the issues vanished, and the disks are all healthy 3-4 years later.


  • That’s the problem, unfortunately - being comparably secure to Debian isn’t very secure at all. The state of linux desktop security is very much a nightmare (madaidan’s insecurities is a good primer everyone points to, though you should take it with a grain of salt and it’s a few years old), and without security you’re an exploit away from having no privacy either.

    So we’re left with few options, none of them ideal, while the world becomes increasingly more difficult to be participate in without making android or ios a part of your life:

    1. Use a stock android phone, which is just straight up and unabashedly a spying device meant to milk you for value like a dairy cow. Sacrifice privacy for convenience.
    2. Use an iphone, which is the same thing shrouded in a layer of niceness. Sacrifice privacy for convenience and a bit more security.
    3. Use an android variant that focuses on freedom, like lineageos. Sacrifice a bit of convenience for some freedom and some privacy.
    4. Use grapheneos. Sacrifice a bit of convenience for security, some freedom, and some privacy.
    5. Use a linux phone, running something like postmarketos. Sacrifice security for freedom and privacy.

    Read up on the options, understand the realities, and choose the tradeoff that best fits your preferences and lifestyle.




  • I (mostly jokingly, but also a little bit really and sentimentally) believe that physical baremetal computers/servers have souls, and must therefore have hostnames that are names, because names are powerful and soulful and you should have respect for things that have souls. Which is why I kind of hate the “cattle, not pets” model in my own practice.

    Stick identifying categorizing prefixes on it, of course, and you can group clusters under the same name with a numeric suffix, but it’s gotta have a real name in there somewhere.



  • A friend of mine was once the organist at a cathedral with a grand pipe organ. He invited me to see it one day and hear him play, and for the finale he had me climb up into the forest of towering pedal pipes, crouching between the rows, dwarfed by their looming height, while he played Bach’s Toccata and Fugue in D Minor.

    The sound hit me like a wave, so vast and tremendous and perfect. I felt utterly annihilated - tiny and shaken apart into nothing, a speck swept away in a cascading ocean of music, like the whole world was exploding in cataclysm and fractal rebirth all around me. Dazzling and enormous.

    And when the fugue peaked, I think that’s the closest to nirvana I’ve ever been. Just blown clean off the face of the earth.