In the fstab shown above, the last swap (UUID=f9ae5…) doesn’t exist in your system according to previous posts and so it is good to leave it commented (or even have that line deleted).
For the first one (UUID=6f309…) I would like to see the last two parameters as “0 0” as already written.
As a side note, there is nothing wrong in having multiple swap spaces listed in fstab (as long as they exist in the system of course).
I changed channels on the last post, previously I was in sdb9 TW and then the next day I was in sdb8 Gecko rolling . . . but, as before I didn’t find either of the swap UUIDs listed in running “blkid” in sdb8 . . . . It could be a video issue, but for the most part I’m either in “default” or “nouveau” for my video drivers, as I have found the proprietary nvidia drivers don’t seem to keep pace with rolling distros.
Anyway, it was seemingly a continuation of some tweak that took place with a new install or two in the machine . . . I’m about done with adding systems . . . for awhile. Now I just have to go back through each of them to try to get them to boot quickly, etc.
Last question, when you said “It could be several /fstabs” . . . I’m assuming that each install in OpenSUSE has their own individual /etc/fstab directory, there is no “master” or “active” /etc/fstab . . . as there is with grub?? The other systems are not influenced or messed with by an /fstab adjustment in another distro as they may be with grub???
Thanks for flying over the time zones . . . I tried to “add reputation” but, seems like I have to “spread it around” . . . .
Yes, there are as many /etc/fstab as there are root directories in the system: think /etc is a subdirectory of / (root), so several / (roots) means several /etc/ directories each holding its own fstab to tell each installed distro which filesystems to mount and use.
GRUB is a different beast, it tells the machine which partition in which disk to use as / (root) and where to find one (or more) bootable kernels on it.
In a modern system the UEFI subsystem chooses where the “active” GRUB is to be found, so you can have one or several GRUB bootloaders installed and choose which one to enable via the UEFI menu, or even chain-load them so that one menu line in the “active” GRUB may in fact point to another installed GRUB which in turn effectively finds the kernel to boot and so on (but bootloader experts might object to my short simplified description).
Long story short, you must be careful when multi-booting if you want to know which GRUB configuration to edit and not switching to another the next time you update one of the installed systems, since default installers usually assume that there is only one system and one GRUB to take care of (but this is beyond the scope of this thread).
Thanks for flying over the time zones . . . I tried to “add reputation” but, seems like I have to “spread it around” . . . .
Thanks for the explanations . . . so in my case I generally have one root per distro . . . but, now, more and more distros for GRUB to handle . . . .
Anyway, I think I have rifled through a couple of my OpenSUSE installs and played with their /etc/fstab directories and boot performance is better . . . and, for now I have to boot sdb8 with recovery . . . . I have enough installs to keep me very busy . . . if they can be booted with some speed I’m “OK” with it.
I couldn’t help a lot as I don’t have mulit-boot. But FWIW, as it might not have come clear in my post:
Your boot to rescue issue might be a missing target in fstab. That’s what I have encountered once a disk that was entered in fstab was missing. For trouble shooting on your sdb8 better first check carefully if all listed disks are physically and in /dev/* existing.
Cheers!
kasi
Thanks for your efforts . . . sometimes a comment will spark an idea that willo in fact help out with troubleshooting . . . . In my case I never heerd tell of “/etc/fstab” . . . so now there is that . . . . It seemed like in the recent round of troubles I believe that doing some Debian installs is where Debian re-wrote the UUID numbers for the swap partitions, in one install it seemed to take over all four of them from the 4 different drives.
It seems like they didn’t mess with the “/” and/or “/home” UUIDS . . . jes the swap. Debian takes itself pretty serious . . . it doesn’t mind bulling the other kids around, etc.
Unless recently changed, all Debian installers, which includes *buntu and Mint, will format any existing swap partition they will include in their fstabs. They don’t offer a choice not to, except if you choose to install without any swap. You can add a swap to an fstab later easier than you can edit all other fstabs after doing a Debian installation, or afterward reconfigure swap using the UUID present in the other fstabs.
There is another workaround for Debian usurpation - mount any swap by device name instead of UUID in all fstabs that share any swap partition.
This all applies to any resume= present on any Grub kernel command line. When multibooting and sharing swap partition(s), you really don’t want to be trying to remember which OS you booted last in order for resuming to take place. If you let it, and don’t remember, you could get a filesystem damaging result. It’s better to include noresume on all the kernel command lines instead of a resume=.
Thanks for the confirmation . . . I hadn’t played with Debian since perhaps '12 . . . so I wasn’t working from a totally informed position . . . as usual.
Thanks also to you for the details . . .and, indeed, the usurption and /fstabing damages have been well done . . . more or less across the board of my installs. I do recall the Debian installer seemed to automatically mount the swap, whereas in other installers that doesn’t seem to be automatic OR even necessary.
I will have to look into the “mount by device name rather than by UUID” at some point. I was in something yesterday, one of the numerous but not that many distros, and I did check the /etc/default/grub file and I didn’t see anything about “resume=” . . . as it also was in the TW install that prompted this thread, it didn’t seem like grub per se was messed with, just the swap . . . which then made the boot up very slow for those affected distros.
Historically, in the dark times, running a fresh install of OpenSUSE would restore “order” to grub . . . but this “fstab” thing was apparently where the damages have been wrought. Seemingly in this case running TW os-prober didn’t reach over and fix fstab . . . or all of them, no silver bullet in this case.
Yes, os-prober looks for available kernels in all mounted partitions and adjusts grub accordingly but doesn’t mess with configurations of those installed systems, including fstab.
Not specific “mounted partitions”. Simply because it is very unusual to mount root file systems (or, if they are separate, /boot file systems) from not running systems on a a running system (the one you run os-prober on). That would thus find almost nothing. I assume it looks in all available partitions and possibly Logical Volumes, etc. to see if there can be booted from it.
This fits with my experience as well, as I have run quite a few ubuntu installs ans usually that would go well as far as the other players are concerned, although in the last year plus they did something to grub or shim that seemed to wipe all other contestants from grub, because “what else would you need to boot?” and the devs didn’t seem to see that as a problem . . . hence my drifting away from ubuntu toward Debian to provide some variety to my daily driving . . . . Only to find that Debian wants to be the only kid playing on the block, etc.
More or less have things re-ordered . . . all I have to do now is clean grub out of all of the non-TW distros and let TW coordinate the grub show . . . right now one of the Gecko’s has cut in front of TW
. . . not super-critical at this point now that it is a known behavior that Deb messes with swap UUIDs . . . more or less done installing Debian stuff. I wanted to run something “Sid” . . . and so I have.
“The price of freedom is high . . . I have paid that price, and I am now ‘free.’” --famous quote from M. Ali
Ah, OK . . . I’ll check that when I get back to the master blaster cMP . . . that is “EFI” based machine/mobo??? It’s not pressing issue right now, I’ll just have to clean grub out of the Gecko install and then let TW run os-prober whenever it upgrades grub . . . look Ma, no hands, etc.
