5

I have several separate installs of Linux on my machine, and reboot to whichever one is appropriate. I'm wondering if it is possible to switch from one to the other without a full reboot by doing something like, say, copying over fstab with the partitions for the new install listed and then mount -a.

Obviously, the kernel would not change, but that's OK, I'm hoping to just change the working partitions. I also take it as obvious that this would have to be done from the command line with nothing running (if that's even possible). Or is the idea null and void and sheer madness from the get-go?

The reason for this is that I normally experiment with radical changes (like moving to the 'amd64' kernel in Debian) in a separate 'experimental' install. Rebooting to start it up is of course just fine, but it would be cool if I could sorta jump over to that install without an entire reboot. You could think of this as just changing the root partition on the fly, but maybe that is not possible at all.

Yup, it's possible, as I learn below. If you don't need to swap out the kernel itself use 'chroot'. If you want to simulate a complete reboot use 'kexec'.

2
  • Have you separated out all of / /usr, /var /dev /tmp /proc, /sys etc onto different partitions? – Mike Diehn Oct 5 '14 at 15:56
  • 4
    What exactly do you want to do? What do you expect to change when you do this? Do you just want to have access to the data or boot into the other distro? Since you understand that the kernel won't be changing, what is it that you actually want to have change? You mean you want your / to be something else? What for? I am asking to avoid what sounds very much like an XY problem – terdon Oct 5 '14 at 16:29
6

I don't think this is possible.

Theoretically what you'll want to do is:

  1. Move the system to the "single" run level by using init 1, where theoretically you only have init and bash running.
  2. Unmount all the partitions except / . at this point your system may stop working, depending on whether /usr is on the root partition.
  3. Mount your other os's root somewhere.
  4. pivot_root to change the root to the new partition.
  5. Tell init to start the new system by running init 5 (or 2 or a whatever is appropriate).

The problem is that pivot_root only change the root partition for the current process, which means it will not affect init and when you tell init to start the system, it will start your old one. You'd need some way to tell init to do the pivot_root, which I don't think is possible.

Oh, and let's not get into what happens when your other OS uses a different init service (e.g. Fedora uses systemd while Ubuntu has upstart). You'd need to replace the init process (pid 1) under the kernel and this is really a no-go.

4
  • 1
    Ok then, it's not possible, or at least it's so complex that I may as well just reboot. I'm not surprised to hear that, but I thought I'd make sure. Thanks ... unless there is some way to restart the kernel from scratch, pointing to a new root partition, without needing the full reboot. – Ray Andrews Oct 5 '14 at 19:37
  • 2
    @ray That's a different question, but that's doable. Look into kexec. – hvd Oct 5 '14 at 20:05
  • That looked like exactly the thing. Tried it with '-l ...' and nothing at all happened. Tried it with '-e' and it hung the system. On reboot, the entire system was useless :( Rebooting another disk, it turns out that 'kexec' had trashed my 'initrd' file !!! Fixed, but that was awfully rude. Thoughts? – Ray Andrews Oct 5 '14 at 23:29
  • 2
    Well, edited /etc/default/kexec: "LOAD_KEXEC=true", and tried again, and it works. This is exactly what I'm looking for, however I'll be experimenting with 'chroot' and bind mount as well. Thanks all. – Ray Andrews Oct 6 '14 at 16:04
1

If you want to experiment with different kernels, you'll have to either reboot or run them in a virtual machine. Virtual machines are more convenient, but then you can't test the kernel on your real hardware.

If you want to have different setups with different sets of installed programs, you can also use a virtual machine. If you want to avoid the overhead of a virtual machine, you can install a distribution in a chroot. I often do that to have easy access to 32-bit programs on a 64-bit installation, or to have the latest stuff (like Debian unstable) in addition to a stable relase (like Debian stable). I wrote a guide to setting up a chroot for alternate Debian/Ubuntu releases. See also Lightweight isolated linux environment

1
  • a fine doc. Over my head right now, but I'll be back. – Ray Andrews Oct 6 '14 at 3:47
1

If you don't want/need to change kernels, but just want to use the other filesystem(s), as you seem to indicate here:

Obviously, the kernel would not change, but that's OK, I'm hoping to just change the working partitions.

Then perhaps you just need (mount and) chroot, which, to use your words,

You could think of this as just changing the root partition on the fly

I use chroot all the time from rescue systems (like clonezilla) to interact with a filesystem that would normally be used be a different kernel. I don't expect to be able to do things like loading new kernel modules, but it's fine for reading and writing files (fixing fstab, adjusting grub.conf, etc.).

You can use bind mounts to make the chroot environment more useful. I use this all the time to replicate mounted filesystems inside a chroot target:

mount /dev/sda1 /mnt
for d in dev sys proc; do mount -obind /$d /mnt/$d; done
chroot /mnt
4
  • chroot is useful but I'm sorta not 'really' there. All my other mounted systems aren't found (because their mount points are empty) and each shell must be started separately. Nope, kexec would be fine, if it worked and didn't trash my boot. – Ray Andrews Oct 6 '14 at 2:09
  • You can use bind mounts to make the chroot environment more useful. I use this all the time to replicate mounted filesystems inside a chroot target: mount /dev/sda1 /mnt; for d in dev sys proc; do mount -obind /$d /mnt/$d; done; chroot /mnt; – Nick Russo Oct 6 '14 at 2:16
  • If there are other aspects that bind-mounts and chroot don't cover, let me know, as we may have have run into them too. Otherwise, is it worth accepting as the answer? – Nick Russo Oct 6 '14 at 3:55
  • As the user who asked a question, you can select one of the answers as the accepted or preferred answer. meta.stackexchange.com/questions/5234/… To mark an answer as accepted, click on the check mark beside the answer to toggle it from hollow to green. – Nick Russo Oct 6 '14 at 16:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.