Dual booting SuSE42.3 problems

English Install/Boot/Login
1

Hello - I have hit an unexpected snag that I strongly suspect is due to the OpenSuSE 42.3 installer messing up and I need some expert guidance on Grub, Initrd etc to resolve. (Grub and the bootloader remain beyond my ability to grok, how I wished it followed a KISS principal!)

Anywise, I had installed OpenSuSE 42.3 on my server with the root partition / mounted on /dev/sdd2 and a few other mount points defined such as for /home and /srv. on different partitions All was happy in server land until I decided I wanted to do a total reconfiguration of all my services. For this I decided to install a second version of OpenSuSE 42.3 into a different partition at /dev/sdd5. In effect I wanted to have two slightly different versions of OpenSuSE42.3 that I could boot to and use one for a test and development environment in which to play with new configurations of my services. So I proceeded to install a second copy of OpenSuSE 42.3 and I imported the fstab settings in the disk partitioner from my first copy of OpenSUSE42.3. I then made a couple of changes so that the root directory / was set to /dev/sdd5 and /srv was also set to a new partition. Upon rebooting up the new version of OpenSuSE42.3 all seemed well and the new installation worked as expected.

Trouble arose however when I tried to boot up my original version of OpenSuSE 42.3 from the /dev/sdd2 partition. I selected it in the GRUB boot menu but when I got the system up and running it was as if it had read the wrong /etc/fstab file and I ended up with the mount configuration as defined for the /dev/sdd5 version of OpenSuSE 42.3! I have no idea why this shouldn’t have simply worked as expected but my research on it seems to lead me into the quagmire of Grub and initrd and my confusion level has exceeded my capacity to comprehend what to do about this mess. My guess is that I have to do something with mkinitrd but I don’t understand how to tell it to use the correct version of fstab for booting up each system.

So can some kind guru tell me how to get the proper version of fstab to associate with the corresponding version of the / root directory for each version of OpenSuSE 42.3 that I want to be able to dual boot? Sorry if I am not asking these questions in a proper way or miscommunicating. Would it help if I copied and pasted the two versions of fstab here or is this enough info to go on?

Thanks in advance, Marc…

2

It sounds like this could be a boo-boo in the “couple of changes to the fstab”. However, fstabs are read according to the / location in the initrd as a fallback that is usually overridden by the kernel cmdline submitted by grub. Grub2 in a normal openSUSE installation mounts native partitions by UUID, not device names like sdd5 or sdd2. This also depends on the bootloader location selected for each installation. If both include the MBR, the last installed or updated is providing the Grub boot menu, the other’s totally being ignored. One of the two need to be reconfigured to only have its Grub on the / partition, and not write anything to any MBR.

Probably best to start by showing us the two fstabs, and the two grub.cfgs.

3

Thanks mrmazda for you reply and yeah I suspect I am doing something “wrong” due to my inability to grok the model behind Grub and bootloading… I will comply with your wish to show what I can, hope it is not overwhelming!

I am using the device names rather than the UUID because it is both shorter and much easier for me to use in communication here. I am not using them in fstab and rely completely on the YaST partitioner to generate the content of these files.

/dev/sdd2 contained my original version of OpenSuSE42.3 and the fstab defined there was as follows -

bigbang:/SuSE42.3/etc # cat fstab
UUID=25cb1647-baef-4e16-8472-d029cfad9fa6 swap                 swap       defaults              0 0
UUID=a8d49639-7e0b-4cdd-b4ec-a464bcf578fd /                    ext4       acl,user_xattr        1 1
UUID=9241a80a-1670-4f08-b475-c0c7a769095d /SuSE12.3            ext4       defaults              1 2
UUID=277b7114-e703-4ac6-a621-c076305b151e /SuSE42.1            ext4       defaults              1 2
UUID=8db6a5e9-592e-45a2-a5e5-55f30914cb69 /SuSE42.2_var        ext4       defaults              1 2
UUID=c96ec6ab-ba90-42f1-b05f-2d9f71fdbee2 /boot                ext4       acl,user_xattr        1 2
UUID=585ba71e-3f31-4b07-9100-c3997311738e /data                xfs        defaults              1 2
UUID=c8c10691-6447-4bfc-a3cf-2a91a2490129 /data1               ext4       defaults              1 2
UUID=bb3a7d35-cdfb-464b-9c4f-2b562e13d7d7 /home                ext3       defaults              1 2
UUID=d0947373-48e3-4ede-bc5f-8d210bb525d5 /mail                xfs        defaults              1 2
UUID=c35dc661-eedb-454d-a895-401eca223be0 /sdb1                xfs        defaults              1 2
UUID=4819e0f7-7085-45ce-bb2b-15e3cf7b1d20 /sdb2                xfs        defaults              1 2
UUID=9ea1620f-7c9b-4159-835b-133ce0f7cadd /srv                 xfs        defaults              1 2
UUID=fa5ace2a-d722-4e10-8000-2efafd8e6891 /tmp                 ext4       acl,user_xattr        1 2
UUID=0ea9ed96-6dc7-46f4-8720-5c7b83381557 /websites            ext4       acl,user_xattr        1 2

/dev/sdd5 contained the newest version of OpenSuSE42.3 that I installed to experiment with new server configurations. The fstab for it is shown below -

bigbang:/etc # cat fstab
UUID=25cb1647-baef-4e16-8472-d029cfad9fa6 swap                 swap       defaults              0 0
UUID=a7d9d58a-ee05-4f36-8f11-02bf3f6a8cd4 /                    ext4       acl,user_xattr        1 1
UUID=9241a80a-1670-4f08-b475-c0c7a769095d /SuSE12.3            ext4       defaults              1 2
UUID=277b7114-e703-4ac6-a621-c076305b151e /SuSE42.1            ext4       defaults              1 2
UUID=8db6a5e9-592e-45a2-a5e5-55f30914cb69 /SuSE42.2_var        ext4       defaults              1 2
UUID=a8d49639-7e0b-4cdd-b4ec-a464bcf578fd /SuSE42.3            ext4       acl,user_xattr        1 2
UUID=9ea1620f-7c9b-4159-835b-133ce0f7cadd /SuSE42.3_srv        xfs        defaults              1 2
UUID=c96ec6ab-ba90-42f1-b05f-2d9f71fdbee2 /boot                ext4       acl,user_xattr        1 2
UUID=585ba71e-3f31-4b07-9100-c3997311738e /data                xfs        defaults              1 2
UUID=c8c10691-6447-4bfc-a3cf-2a91a2490129 /data1               ext4       defaults              1 2
UUID=bb3a7d35-cdfb-464b-9c4f-2b562e13d7d7 /home                ext3       defaults              1 2
UUID=d0947373-48e3-4ede-bc5f-8d210bb525d5 /mail                xfs        defaults              1 2
UUID=c35dc661-eedb-454d-a895-401eca223be0 /sdb1                xfs        defaults              1 2
UUID=4819e0f7-7085-45ce-bb2b-15e3cf7b1d20 /sdb2                xfs        defaults              1 2
UUID=e8aeb98b-9075-4b70-b61d-1b247f944080 /srv/www  ext4  acl,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0        1 2
UUID=fa5ace2a-d722-4e10-8000-2efafd8e6891 /tmp                 ext4       acl,user_xattr        1 2
UUID=0ea9ed96-6dc7-46f4-8720-5c7b83381557 /websites            ext4       acl,user_xattr        1 2
/var/log/ispconfig/httpd/marcchamberlin.com /srv/www/clients/client1/web1/log    none    bind,nobootwait    0 0

I have a separate partition set up for mounting /boot on and it is common to both versions of OpenSuSE42.3. /boot/grub2/grub.cfg is rather long
so I have posted it on Pastebin - https://pastebin.com/hTuF1VBK

As I mentioned the problem I now am having is that when I boot up my original version of OpenSuSE 42.3 for /dev/sdd2 I am getting the disk partition
set up as described in the fstab for /dev/sdd5. I need to fix this…

4

That would be the cause of your problem.

Do you even need a separate “/boot”?

5

Looks like you only provided 3/4 of what I asked for (only one grub.cfg). http://susepaste.org/ is another option. :slight_smile:

Combing through fstabs full of UUIDs is hard for everyone. Please show the device names for the partitions by posting output of

blkid

You can make fstabs easier to deal with by assigning unique volume labels to each filesystem, and rebuilding fstabs using the labels instead of UUIDs.

6

For sure. One or the other needs to have the /boot entry removed from its fstab, its (and only its) content moved to its / filesystem in the /boot directory, and its bootloader reconfigured (most easily in YaST2) to / only.

7

Why? And I am not being flippant with this question because I think this goes to the heart of why I think Grub is so poorly designed. It is difficult to understand/grok the model that is being used to represent the boot loading process and related activities such as how disk partitions are actually set up. Browsing the internet for answers gives one the feeling that setting up the boot loader borders on religious occult theories where there are almost as many different opinions on how to do it as there are writers writing on the subject.

To a simple layman’s mind, such as mine, what I want to do is to boot up one of two separate operating systems and each comes with it’s own view of how it wants to see the disk partitioning environment. So fstab should be an attribute of the operating system but what you are implying is that the Grub model has it the other way around. Otherwise why shouldn’t two separate fstab definitions be honored based upon which operating system got selected to be booted up? Until this model gets resolved in a way that makes logical sense to us poor users, I think this is going to be a source of endless confusion.

I don’t know, nothing in the YaST GUI for setting up either partitions or the Boot Loader tells me what is the best approach. As a GUI it fails to guide me to a satisfactory solution. Internet searches gives me both answers, some say it is a good idea to have a separate /boot partition, others say it is not. See my above comment about religious cults… :wink:

I know that OpenSuSE did not design Grub or the boot loading process, but OpenSuSE did design YaST which is the tool I assume I should be using. It is also part of the very installation disks I get when I install OpenSuSE itself. A good GUI is suppose to guide a user to make good choices, or at least explain the tradeoffs in an understandable fashion. If I, and other users, are making mistakes in using YaST to set up boot loaders, then I think it is high time to take a serious look at why YaST is failing to prevent such mistakes. It comes down to how the boot loader model is being presented… And please, don’t tell me to RTFMs either, I have tried, and it just makes it worse. A lot of the documentation is out of date, refers to old ways of doing things, or uses inconsistent terminology.

So I invite you to try and explain and justify, in simple layman terms, why having a separate /boot partition leads to a failure such as what I am experiencing.

8

.

I don’t know where there would be another grub.cfg file, the only one I could find was under /boot/grub which is a common partition mounted for both versions of the OS.

.

I will try to remember that, I am familiar with PasteBin is all.

.

bigbang:/boot/grub2 # blkid
/dev/sdd1: UUID="c96ec6ab-ba90-42f1-b05f-2d9f71fdbee2" TYPE="ext4" PTTYPE="dos" PARTLABEL="primary" PARTUUID="f8eeb8d5-baf5-47d8-b0f9-e0ad132abdd3"
/dev/sdd2: UUID="a8d49639-7e0b-4cdd-b4ec-a464bcf578fd" TYPE="ext4" PARTLABEL="primary" PARTUUID="403cf8ee-e4e4-4b20-863c-45aef1dcdcad"
/dev/sdd3: UUID="fa5ace2a-d722-4e10-8000-2efafd8e6891" TYPE="ext4" PARTLABEL="primary" PARTUUID="0aebd5dc-90c7-4b28-bc30-39d5d476bb7d"
/dev/sdd4: UUID="0ea9ed96-6dc7-46f4-8720-5c7b83381557" TYPE="ext4" PARTLABEL="primary" PARTUUID="7ab38e14-cbb0-47ab-b76d-74e256d62ba0"
/dev/sdd5: UUID="a7d9d58a-ee05-4f36-8f11-02bf3f6a8cd4" TYPE="ext4" PARTLABEL="primary" PARTUUID="fa44937b-4477-437c-8048-f2a0d35bb51b"
/dev/sdd6: UUID="e8aeb98b-9075-4b70-b61d-1b247f944080" TYPE="ext4" PARTLABEL="primary" PARTUUID="0cb9ba07-a5ed-45e6-80f8-b1b9968f9150"
/dev/sda1: UUID="25cb1647-baef-4e16-8472-d029cfad9fa6" TYPE="swap" PARTUUID="0001f1ae-01"
/dev/sda2: UUID="c8c10691-6447-4bfc-a3cf-2a91a2490129" TYPE="ext4" PARTUUID="0001f1ae-02"
/dev/sda3: UUID="8db6a5e9-592e-45a2-a5e5-55f30914cb69" TYPE="ext4" PARTUUID="0001f1ae-03"
/dev/sdb1: UUID="c35dc661-eedb-454d-a895-401eca223be0" TYPE="xfs" PARTUUID="00064ae9-01"
/dev/sdb2: UUID="4819e0f7-7085-45ce-bb2b-15e3cf7b1d20" TYPE="xfs" PARTUUID="00064ae9-02"
/dev/sdb3: UUID="9ea1620f-7c9b-4159-835b-133ce0f7cadd" TYPE="xfs" PARTUUID="00064ae9-03"
/dev/sdb5: UUID="585ba71e-3f31-4b07-9100-c3997311738e" TYPE="xfs" PARTUUID="00064ae9-05"
/dev/sdb6: UUID="d0947373-48e3-4ede-bc5f-8d210bb525d5" TYPE="xfs" PARTUUID="00064ae9-06"
/dev/sdb7: UUID="63b3e0f5-681c-4d76-9999-144ee3c2f5ac" TYPE="xfs" PARTUUID="00064ae9-07"
/dev/sdc1: UUID="9241a80a-1670-4f08-b475-c0c7a769095d" TYPE="ext4" PARTUUID="000c0544-01"
/dev/sdc2: UUID="bb3a7d35-cdfb-464b-9c4f-2b562e13d7d7" TYPE="ext3" PARTUUID="000c0544-02"
/dev/sdc3: UUID="277b7114-e703-4ac6-a621-c076305b151e" TYPE="ext4" PTTYPE="dos" PARTUUID="000c0544-03"

How? If the partitioner in YaST will do that for me it must be buried somewhere in the GUI and not easily discoverable. And if that would lead to a better comprehension of fstab why doesn’t the YaST partitioner write out fstab with volume labels by default and prompt the user to enter such labels (or chose some human friendly default labels) rather than use those awful UUIDs?

9

For historical reasons grub2 configuration is located in /boot, so last operating system that updates it wins. Another consideration (unrelated to bootloader) is that one instance of operating system does not know anything about another instance and so can overwrite files even if you managed to keep bootloader configuration separated. Just think about two identical openSUSE versions using the same kernel but one using root on iSCSI and another on NFS, so each requiring different initrd … which will have identical names for the same kernel version.

10

Thanks again mrmazda, but when I tried to follow your advice I ran into a question and problems… First my question -

There is a lot of documentation that refers, like you have here, to moving the boot loader to the / filesystem yet the YaST boot loader settings GUI only gives me 3 options to choose from.

  1. Boot from Boot Partition
  2. Boot from Master Boot Record
  3. Custom Boot Partition

None of these options suggest that I can configure the boot loader to boot from the / partition. So either there is a terminology issue or I simply don’t understand how to do what you are asking me to do. Is the / partition considered a “Custom Boot Partition” and is that what you are asking me to select? Seems rather odd way of referring to the / partition and highly confusing!

I decided to uncheck the Boot from Boot Partition option but that lead to a rather ominous error message saying I had a configuration error and asking me if I really wanted to do it? (the error message implies that it is a dangerous thing to do) So I canceled and await further instructions on how to change/remove the boot partition.

11

In YaST this actually means “partition where /boot is located”.

12

I hadn’t thought all the way through to there being only the one shared filesystem mounted as /boot/ on both. There should have been two, but the subsequent usurped the original instead of adding one.

How? If the partitioner in YaST will do that for me it must be buried somewhere in the GUI and not easily discoverable. And if that would lead to a better comprehension of fstab why doesn’t the YaST partitioner write out fstab with volume labels by default and prompt the user to enter such labels (or chose some human friendly default labels) rather than use those awful UUIDs?

The powers that be decided that UUID is preferable to LABEL. It really is best for the admin to be the one to choose the volume labels. Labels can be created with either e2label or tune2fs for EXTx filesystems. YaST can create labels as well, as a part of the process of specifying mount points and mount options. YaST also can be changed from its default of mounting by UUID to mounting by LABEL.

Note that I was in the middle of writing an answer to post #7 when #8 quoted here arrived, and in the middle of writing this, #s 9-11 have arrived. I’m still working through the #7 answer, which duplicates #9 in large part. I’m not going to try to answer #10 before finishing the one previously started.

13

Thanks arvidjaar for responding but I am not sure I am groking your answer correctly. Are you telling me that a copy of the fstab, from the last OS that sets up the bootloader, is actually copied into the configuration of grub2 and the boot loaders? And it is this copy that actually gets used in setting up the disk partitions, no matter what OS actually gets booted up??? I am really stretching here and guessing but if so then that kinda makes sense as to why I am being told not to have a single boot partition… If so, then I would think that even allowing a single boot partition to be created is really bizarre and can easily become a dangerous user trap! Apparently is has for me? This would be a pretty serious flaw in the design of Grub and bootloaders, IMHO!

14

Oh! OK Got it! That IS a terrible label in YaST! No wonder I got confused by it…

15

To #7 primarily:

There are various perfectly valid reasons for having /boot on a separate filesystem. Just because that is so doesn’t invalidate the necessity of the content of /boot/ be under exclusive control of a single operating system. /boot/ absolutely must be just as exclusive to one installation as any of /bin/, /etc/, /lib/, /sbin/, /sys/ or /usr/lib/. Your second installation usurped control of the boot process in a manner marginally distinguishable from when a Windows reinstallation replaces Grub on the MBR with its own legacy boot code.

You do have a repairable situation. I did see, as would normally be expected from every openSUSE installation that finds any other already installed Gnu/Linux installation that will be kept intact, a Grub stanza that appears it should boot the other installation. If so, then it can be used to reconfigure itself with what should be the content of /boot/ on its own / filesystem in the /boot/ directory (assumes Grub configured to MBR for both installations):

1-Boot to the old using a stanza that includes UUID=…78fd on the kernel cmdline
2-unmount the /boot/ partition
3-mount the old /boot/ partition elsewhere, such as /mnt/
4-copy the content from the temporary location to /boot/
5-eliminate the /boot/ line from fstab
6-reinstall kernel
7-reinstall grub
8-boot to the newer installation
9-repeat 2-7 for the currently booted newer installation
10-reconfigure bootloader to write nothing to MBR and install only to /boot/

OR

1-Boot the installation media, and perform a repair bootloader process on the original installation
2-Boot the repaired original installation
3-modify fstab on the second installation to eliminate the /boot/ line
4-clone the content of /boot/ to /boot/ on the second installation’s /
5-boot the second installation
6-reinstall kernel
7-reinstall grub
8-reconfigure bootloader to write nothing to MBR and install only to /boot/

At this point I’m puzzled which of 7 & 8 should go first. Maybe arvidjaar and/or nrickert should weigh in on this proposal before you consider to try.

I don’t use Grub2 at all except on one installation that uses UEFI and GPT. All my many PCs are multiboot with IBM BM or IBM BM and Grub Legacy, with generic code on all MBRs, and with a master Grub Legacy that I manage manually on a partition that is never mounted to /boot/. The master Grub Legacy optionally loads the installed systems’ symlinked kernels and initrds, or chainloads them, or loads their configfiles.

16

Bootloader and fstab have nothing directly to do with each other. There is overlap in the data each uses, but neither must rely on the other, or copies from any of the other’s files.

I am really stretching here and guessing but if so then that kinda makes sense as to why I am being told not to have a single boot partition… If so, then I would think that even allowing a single boot partition to be created is really bizarre and can easily become a dangerous user trap! Apparently is has for me? This would be a pretty serious flaw in the design of Grub and bootloaders, IMHO!
The trap is multiboot, which is art as much as science. There are too many possible permutations to expect an installer to foresee, much less QA before distribution release. The installing admin must play an active and informed role in selecting installation steps.

17

Because what is in “/boot” controls the booting. If two systems share “/boot” they will both boot into the same system.

“/boot” contains the kernels, the boot menu (which specifies what will be the root partition), and the “initrd” which is used in the early stages of booting. You are sharing that.

Browsing the internet for answers gives one the feeling that setting up the boot loader borders on religious occult theories where there are almost as many different opinions on how to do it as there are writers writing on the subject.

It never seemed that way to me.

Keep in mind that the term “booting” comes from the expression “pulling your self up by the bootstraps”. And in ordinary life, pulling yourself up by the bootstraps is something that you could never do.

The point of that name, is that the booting has to work in a very minimal environment where most things don’t work because you don’t even have an operation system running at that stage. So booting depends on whatever scraps the hardware designer made available to get something into memory and running.

To a simple layman’s mind, such as mine, what I want to do is to boot up one of two separate operating systems and each comes with it’s own view of how it wants to see the disk partitioning environment.

Fair enough. But much of that “it’s own view” is in “/boot” because it has to be part of the booting process.

So fstab should be an attribute of the operating system but what you are implying is that the Grub model has it the other way around.

However “fstab” cannot do anything until the kernel is loaded and the root file system is mounted. Until then, “fstab” is not available. So the early stages of booting have to depend on what is on the kernel command line (in the boot menu) and on what is in the “initrd”.

Otherwise why shouldn’t two separate fstab definitions be honored based upon which operating system got selected to be booted up?

The boot menu tells the kernel where to find the root partition. And the root partition is where “fstab” sits. So the boot menu controls which “fstab” will be seen.

When you run “grub2-mkconfig” to update the boot menu, it looks in “/boot” for each system to get hints on what to put on the kernel command line. And you are sharing “/boot” so it uses the same hints.

Until this model gets resolved in a way that makes logical sense to us poor users, I think this is going to be a source of endless confusion.

Booting is very much a pragmatic “seat of the pants” operation – do whatever you have to do get the system up and running. There really isn’t a choice of doing this in a completely clear and orderly way. It has to be done with whatever the hardware manufacturer/designer provided.

I don’t know, nothing in the YaST GUI for setting up either partitions or the Boot Loader tells me what is the best approach.

The original reason for a separate “/boot” partition, is that in early PCs the BIOS could only access the first 32M of the hard drive. So you could have a bigger hard drive, but everything you needed for booting had to be within the first 32M.

The original BIOS has since been redesigned many times to accomodate larger disks and other changes. So most of those early limitations are gone.

You can usually manage without a separate “/boot” with any computer built in the last 10-15 years. You might still want a separate “/boot” for some special reason, but it usually isn’t needed.

I do use a separate “/boot”. That’s because I like to encrypt most everything. So “/boot” is not encrypted, and contains enough that is not encrypted to get the system up and running to the point where it can handle the cryptography. But even in that case, you can manage without a separate “/boot” if you boot from the MBR (which is not encrypted) or you use UEFI booting (the EFI partition is not encrypted).

In any case, to solve your problem you need to either have

  • a separate (not shared) “/boot” for each of your systems, or
  • no “/boot” at all for at least one of those systems.

The simplest approach would be to manage without the separate “/boot” for one of your two systems.

If you need help changing to that, we can go through the steps in future posts to this thread.

18

Also the boot partition is simply a place where you put the /boot directory. It can be any partition in theory but default is to use the root partition to be also the boot partition and put the /boot files there. It is a bit confusing for mainly because different things use the same name and you have to know the context. Example there is a root partition and a root file system and a root user who owns a /root directory.

19

On to the repair question.

Yes, as mrmazda has said, your system can be repaired without a reinstall.

I’m not sure what’s the easiest way to do that. Personally, I would just boot from a live CD or similar, and do the repairs that way. But that’s harder to explain to you.

Step 1: Boot into your system.
Step 2: Provide us the output from:

df

so that we can see what is mounted for that system.
Also provide us the output from

fdisk -l

(run that as root).

After seeing that, we can probably come up with a simple repair plan.

The overall plan I would suggest:

“/boot” is kept by whatever system you just booted into. And your other system goes without a separate “/boot” partition (it just uses “/boot” as a directory in the root file system).

That way, the system that you just booted into will stay as it is. And we will use that as a platform to repair the other of your two 42.3 systems.

20

Hi mrmazda and many thanks for your detailed reply, I know it took you some time to write up and much appreciate the effort. I think I am following you for the most part, only need help with steps 6 and possibly 7. How does one reinstall the kernel, this I have never done and I don’t see an option for doing it in the YaST2 Boot Loader app? As for step 7 won’t grub be reinstalled automatically if I open up the YaST2->System->Boot Loader application, configure it to not write anything to the MBR and then click on the OK button to write out and exit from the Boot Loader app?

Also, I am thinking that to clone the /boot directory I will use rsync to do the following -

rsync -av /boot/ /newboot