Tag: linux

Posted on

Save Linux state, boot other OS and resume later ChatGPT response

Model: ChatGPT-5 Thinking

Question:
Is it possible to save a Linux machine state to disk, kind of like a sleep, boot a different system and when booting the system with the saved state resume from that saved state?

Short answer: yes, but only with strict caveats.
Linux “hibernate” (aka suspend-to-disk) writes RAM to swap, powers off, and later restores that exact state. You can boot another OS in between as long as the other OS does not touch anything the hibernated Linux had mounted or its swap. If that rule is broken you risk data loss or a failed resume. In practice, doing this repeatedly is fragile; using a VM is the robust alternative.

What must be true for dual-boot hibernate

Boot back into the same Linux (ideally the same kernel build) that created the image.

Do not mount or write (even accidentally) any partition that the hibernated Linux had mounted. Safer: don’t mount them at all from the other OS.

Use separate swap: the other OS must not use the swap partition/file that holds the hibernation image. (Per-OS swap is best.)

Encrypted swap: don’t use a random key. Use a persistent LUKS mapping so the initramfs can read the image.

No firmware/hardware changes between hibernate and resume (BIOS updates, GPU mode flips, moving disks, etc.).

Minimal setup (bare metal)

1. Ensure swap ≥ RAM (or configure compression).

2. Configure resume:

If using a swap partition: add to kernel cmdline, e.g.
resume=UUID=

If using a swapfile: also set the physical offset:
resume=UUID= resume_offset=

3. Rebuild initramfs (varies by distro) and update bootloader.

4. Test: systemctl hibernate → power on → confirm resume without booting another OS first.

5. Only then try booting the other OS, don’t mount the hibernated Linux’s partitions, then reboot back to the original Linux to resume.

Common pitfalls

Some distros disable hibernate by default or when swap is on a random LUKS key.

Shared swap between two Linux installs will clobber the image—use distinct swap per OS.

Windows Fast Startup/hibernation: turn it off; likewise don’t mount a hibernated Windows volume from Linux, and don’t let Windows write Linux filesystems.

Safer alternatives

Virtual machine snapshots/suspend (QEMU/KVM, VMware, VirtualBox): pause/save the VM state, run any other OS on the host, then restore—this is reliable and fast.

CRIU checkpoint/restore for specific services/containers (not full-machine state).

kexec is for switching kernels quickly, not for saving state across a full reboot.

If you tell me your distro, swap layout (partition vs file, encrypted or not), and whether the “other OS” is Windows or another Linux, I can give you exact commands for the resume parameters and initramfs steps.

Posted on

Using Logitech G915 X G-Keys (Macro keys) on Linux (Cinnamon)

I’m running arch linux with the Cinnamon Desktop Environment.
I have recently bought a Logitech G915 X keyboard and I’m missing the macro key to launch the gnome-terminal program.

Lucky Cinnamon has custom shortcuts.

Go to System Settings.
Keyboard.
Shortcuts.
There are 2 options for you.
1. Launchers
Under Launchers, there’s “Launch terminal” and you just assign the G key to that action.
2. Custom Shortcuts
Under Custom Shortcuts you have to define a custom shortcut, providing the path to the binary.

Posted on

sshd sftp chroot jail howto

Problem description:

You would like to jail users to their home directories and not allow shell access, only sftp access.

Solution:

SFTP chroot jail

1. Create a system group. Here I call it sftponly.

2. edit the sshd_config file, usually residing in /etc/ssh/sshd_config
(in weird opensuse it’s in /usr/etc/sshd/ )
and append (it needs to be appended at the end):

and restart sshd.

PasswordAuthentication No means, users can only login with their ssh key, no passwords allowed.

3. create the skeleton structure for each new user

we create .ssh htdocs and log dirs.

4. add a user and chown its home directory to root:root and set the login shell to nologin.
Also add this user to the sftponly group and set proper access octals.
On Rocky 9 it’s in /usr/sbin/nologin .

5. add the client’s ed25519 public key to /home/username/.ssh/authorized_keys

Where AAAA… is replaced by the actual public key from the client’s machine.
Check your /home/username/.ssh/id_ed25519.pub file or that of your customer/friend/etc.

And that’s it.
Yes, that’s all there is to it.

The user will be able to transfer files via SFTP in the sub directories you created in step 3, but not write or create directories in the root directory.