Multi-Boots and Swap

[BasilDazz]

More an exercise in technical correctness, but thought I would post my findings anyhow.

Made a multi boot system with Kubuntu 15.10, Linux Mint and Debian 8.0.

Kubuntu went on 1st, then Mint and finally Debian 8.0.

Now when installing Linux OS's the partitioner always formats swap and gives it a new UUID, ok, just update fstab with the new UUID. IF YOU REMEMBER TO DO THIS!! WHERE'S MY HAIR GONE.

elseif new fstab=0, kubuntu 15.10 -> mount swap (lordoftheunderworldknows);

Linux Mint handily will just find any swap partition and use that, kubuntu 15.10 just drops you to a terminal. I believed the issue was directly proportional to kubuntu alone.

so BasilDazz, check you UUID's in fstab in future.

[Rod J]

Interesting, I hadn't realise this would be an issue for multiple Linux installs.

I've only got Kubuntu 14.04 on the bare metal here just now, but intend to install something else in the future as a dual-boot. I have other Linux's in Virtualbox though.

I must remember the swap UUID may change. Thanks for pointing this out!

[Qqmike]

Made a multi boot system with Kubuntu 15.10

the issue was directly proportional to kubuntu alone

I don't buy this at all. I've never seen this--not at all, not even with many OSs and complex setups. This must be a catch/bug in the NEW 15.10. Multi-boots with Kubuntu, Mint, Debian have always worked fine. Not that it matters really, but you didn't say whether the booting is UEFI+GPT or BIOS+MBR.

(fwiw, currently: UEFI, 1 HDD, 3 ESPs, an instance of separate EFI sub-directories for multiple ubuntu-based's, 6 OSs: three Kubuntu's, two Mint's, one Debian. And I just took down an instance of all that PLUS a full installation of Kubuntu on flash drive (left permanently installed). With this and with many previous examples, no problems.)

[BasilDazz]

Interesting, I hadn't realise this would be an issue for multiple Linux installs.

I've only got Kubuntu 14.04 on the bare metal here just now, but intend to install something else in the future as a dual-boot. I have other Linux's in Virtualbox though.

I must remember the swap UUID may change. Thanks for pointing this out!

I have only successfully installed debian based distro on my system, in the past. Since 14.04, I have found a couple of niggles with getting a boot past the desktop login screen, I believe most have them wrinkles have been ironed out since the latest 15.10 betas. But if your in the AMD crowd and have a taste for windows games and like command-line you may want to install 15.04, how much hair do you have?

[BasilDazz]

I don't buy this at all. I've never seen this--not at all, not even with many OSs and complex setups. This must be a catch/bug in the NEW 15.10. Multi-boots with Kubuntu, Mint, Debian have always worked fine. Not that it matters really, but you didn't say whether the booting is UEFI+GPT or BIOS+MBR.

(fwiw, currently: UEFI, 1 HDD, 3 ESPs, an instance of separate EFI sub-directories for multiple ubuntu-based's, 6 OSs: three Kubuntu's, two Mint's, one Debian. And I just took down an instance of all that PLUS a full installation of Kubuntu on flash drive (left permanently installed). With this and with many previous examples, no problems.)

with mbr+bios

it's not worth me trying to reproduce this issue, all distros are installed now and dandy, but before I changed the UUID of swap in fstab for kubuntu which is the distro that i installed first and was tested working, kubuntu boot dropped me to journalctr commandline - I dislike this command-line.

[oshunluvr]

IME, The Kubuntu installer (Ubiquity) always reformats and applies a new UUID to swap partition, but this hasn't ever caused a failure to boot when booting into the older install. It does delay the boot for a time, then announces the UUID can't be found and continues booting - without swap.

Of course, since I am aware of this behavior, I edit the fstab of the previous installs and either insert the new UUID or use the the partition device name instead of the UUID in all the fstab's. The latter choice prevents the re-occurrence of the issue and further need to edit fstab's.

[BasilDazz]

IME, The Kubuntu installer (Ubiquity) always reformats and applies a new UUID to swap partition, but this hasn't ever caused a failure to boot when booting into the older install. It does delay the boot for a time, then announces the UUID can't be found and continues booting - without swap.

Of course, since I am aware of this behavior, I edit the fstab of the previous installs and either insert the new UUID or use the the partition device name instead of the UUID in all the fstab's. The latter choice prevents the re-occurrence of the issue and further need to edit fstab's.

This has been my experience in the past with Multi-boot as well. Linux Mint exhibited this behaviour after the third distro install of debian, however, reverting back to booting kubuntu produced a failed boot to the command line. I have 3 HDD's in the system. HDD1 contains 4 partitions, roots (/) for kubuntu, mint & debian and a spare partition should I ever will to re-join the dark side. HDD2 is 1 ext4 formatted drive mounted as /storage on all distros. HDD3 contains 4 partitions - seperate HOME (/home) folders for linux mint and kubuntu, ext4 formatted part and a swap partition.

I believe that when the boot is unable to find swap by UUID that it just uses the 1st partition of the sda1 for swap, which in my case is the /home folder of kubuntu distro. Presumably this is why Mint will boot but kubuntu will proceed to boot but then drop to command line.

Under this assumption the swap is just overwriting my /home directory, does this pose any danger to the data stored there? (Everything would appear to be in order for me, but there is little to no data stored there as yet).

[oshunluvr]

I believe that when the boot is unable to find swap by UUID that it just uses the 1st partition of the sda1 for swap, which in my case is the /home folder of kubuntu distro. Presumably this is why Mint will boot but kubuntu will proceed to boot but then drop to command line.

Under this assumption the swap is just overwriting my /home directory, does this pose any danger to the data stored there? (Everything would appear to be in order for me, but there is little to no data stored there as yet).

What evidence do you have to support these conclusions? Operating systems don't make "decisions" for themselves and that's sort of what it sounds like you're supposing. Kubuntu does not, nor any Linux distro that I've every heard of, randomly select a partition and decide for itself that's it's going to use it for swap. It doesn't even attempt to use swap unless it finds a swap partition in fstab. Swap is not required for the OS to boot or run.

Again, IME, having a file system (swap or otherwise) that's in fstab go missing has never caused any of my systems to fail to boot. It does delay things and then offer a message telling me that it can't find UUID <whatever> and then offers the option of skipping that mount during the boot process or waiting longer for it to come on-line.

Let's assume the swap UUID is indeed the cause of what you're seeing: It's easy enough to prove. Simply boot to Kubuntu with a valid swap UUID in fstab, turn off swap and re-format the swap partition giving it a new UUID, and reboot. If it fails to boot, boot into another distro or live USB, mount the failed Kubuntu install and read the log files - saving any showing the error messages from the boot failure. At this point, you could also re-format the swap partition again using the former UUID from your fstab and reboot again to prove that having the correct UUID allows the system to boot. Then you'd have real evidence of a bug and could report it, with 2 sets of log files to help trace the bug.

As I tried to say before, even if you're correct that the reason for the boot failures is the swap partition, a simple edit to all your fstabs would fix the issue permanently. Just remove the UUID in all the fstabs and replace it with /dev/sdc<whatever partition number> and be done with it. Then, everytime you do a new install - and it changes the swap UUID - simply edit the fstab of the new install the same way. That way, the next time you install, all your other installs will still have access to swap.

[BasilDazz]

What evidence do you have to support these conclusions? Operating systems don't make "decisions" for themselves and that's sort of what it sounds like you're supposing. Kubuntu does not, nor any Linux distro that I've every heard of, randomly select a partition and decide for itself that's it's going to use it for swap. It doesn't even attempt to use swap unless it finds a swap partition in fstab. Swap is not required for the OS to boot or run.

Again, IME, having a file system (swap or otherwise) that's in fstab go missing has never caused any of my systems to fail to boot. It does delay things and then offer a message telling me that it can't find UUID <whatever> and then offers the option of skipping that mount during the boot process or waiting longer for it to come on-line.

Let's assume the swap UUID is indeed the cause of what you're seeing: It's easy enough to prove. Simply boot to Kubuntu with a valid swap UUID in fstab, turn off swap and re-format the swap partition giving it a new UUID, and reboot. If it fails to boot, boot into another distro or live USB, mount the failed Kubuntu install and read the log files - saving any showing the error messages from the boot failure. At this point, you could also re-format the swap partition again using the former UUID from your fstab and reboot again to prove that having the correct UUID allows the system to boot. Then you'd have real evidence of a bug and could report it, with 2 sets of log files to help trace the bug.

As I tried to say before, even if you're correct that the reason for the boot failures is the swap partition, a simple edit to all your fstabs would fix the issue permanently. Just remove the UUID in all the fstabs and replace it with /dev/sdc<whatever partition number> and be done with it. Then, everytime you do a new install - and it changes the swap UUID - simply edit the fstab of the new install the same way. That way, the next time you install, all your other installs will still have access to swap.

I have now "decided" with "computed evidence" that swap file was not the culprit. As suggested reformatting swap and trying a reboot DID NOT reproduce the bug.

This thread is marked as solved and a reminder to check swap ID's after a swap format may be valid onboard this forum if not I would not be disappointed if this thread is removed.

[oshunluvr]

Glad you tested it out so we know that wasn't the cause.

I would never advocate removal of such a thread as others reading through will learn of both the potential issue and of a solution to the stated problem: swap UUIDs changing for multi-booters.

[claydoh]

We don't delete threads, anyway, except in extreme cases. This is far from that

Sent from my LG G4

[Qqmike]

Nope, the thread is good, worth it. Your experiments are good. Sometimes, experiments are better than "predictive theory" (which in complex cases usually is fraught with uncertainty). And experiments usually lead to other new, neat ideas. You never know where things might lead. That's why Linux is fun. Your experiments are welcome here.

[vsreeser]

More an exercise in technical correctness, but thought I would post my findings anyhow.

Made a multi boot system with Kubuntu 15.10, Linux Mint and Debian 8.0.

Kubuntu went on 1st, then Mint and finally Debian 8.0.

Now when installing Linux OS's the partitioner always formats swap and gives it a new UUID, ok, just update fstab with the new UUID. IF YOU REMEMBER TO DO THIS!! WHERE'S MY HAIR GONE.

elseif new fstab=0, kubuntu 15.10 -> mount swap (lordoftheunderworldknows);

Linux Mint handily will just find any swap partition and use that, kubuntu 15.10 just drops you to a terminal. I believed the issue was directly proportional to kubuntu alone.

so BasilDazz, check you UUID's in fstab in future.

Never had this problem. Have installed and reinstalled Kubuntu 14.04, 15.10 (didnt like it, got rid of it). hades blue, BHS, Kali2, and backbox. Share the swap and /tmp partitions. I just never let the os format them. Works fine. My system never touches the swap file, just have it there cuz some os's get upset if you try to install without it. /tmp is garbage data, so it doesn't matter anyway