Adding an Entry to the oSUSE BootLoader

[d_hinds]

I installed another OS to a different hard drive on the same computer. It wanted to installed a boot loader to that hard drive, which I didn’t let it do. So the boot loader in service is the oSUSE v. 13.1 boot loader, which boots to oSUSE by default. I took a look at the boot loader app in Yast but saw no way to add another entry. I would also like to remove a few OS entries for systems I no longer use.

I searched the archives for info to do that but found nothing relevant, so I am posting this.

TIA

[robin_listas]

On 2013-12-28 03:36, d hinds wrote:
> I installed another OS to a different hard drive on the same computer.
> It wanted to installed a boot loader to that hard drive, which I didn’t
> let it do.

It is easier if you do.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” (Elessar))

[d_hinds]

@robin_listas

On 2013-12-28 03:36, d hinds wrote:
> I installed another OS to a different hard drive on the same computer.
> It wanted to installed a boot loader to that hard drive, which I didn’t
> let it do.

It is easier if you do.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” (Elessar))

How so? Would it have included all the entries listed on the Bootloader found on the sda drive? Why would I want boot loaders installed to both disks when all the OS’s except 1 are on sda? Also, most distros will ask you where you want the boot loader. This one didn’t. I can’t allow that.

IAC, I want to add an entry to the oSUSE boot loader menu and delete others. If you know how to do that, why don’t you say so? Out with it, Carlos.:shame:

[robin_listas]

On 2013-12-28 04:06, d hinds wrote:

>> It is easier if you do.

> How so? Would it have included all the entries listed on the Bootloader
> found on the sda drive?

Of course not. Or maybe yes, because grub 2 finds them all, if it works correctly.

The idea is that the second system is “happy” having its own boot system, which is in fact called
from the first boot system. This way you do not need to add entries to the first grub each time you
change options on the second.

> IAC, I want to add an entry to the oSUSE boot loader menu and delete
> others. If you know how to do that, why don’t you say so? Out with it,
> Carlos.:shame:

Barely. I have the automatic entries. There is a custom section, though.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” (Elessar))

[d_hinds]

@robin_listas

On 2013-12-28 04:06, d hinds wrote:

>> It is easier if you do.

> How so? Would it have included all the entries listed on the Bootloader
> found on the sda drive?

Of course not. Or maybe yes, because grub 2 finds them all, if it works correctly.

The idea is that the second system is “happy” having its own boot system, which is in fact called
from the first boot system. This way you do not need to add entries to the first grub each time you
change options on the second.

> IAC, I want to add an entry to the oSUSE boot loader menu and delete
> others. If you know how to do that, why don’t you say so? Out with it,
> Carlos.:shame:

Barely. I have the automatic entries. There is a custom section, though.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” (Elessar))

Thanks anyway. What I need to know then, is how do I edit the grub.cfg file found in Computer > boot > grub2?

It’s a binary file (as are others named device.map, there) and nautilus says they all are of an unknown type.

(I am trying to maintain openSUSE as the default boot choice, and take a look at another distro, that way. If I install the other distro with it’s boot manager, that would change the menu and openSUSE would no longer be at the top, with it’s openSUSE graphics).

TIA

[robin_listas]

On 2013-12-29 02:06, d hinds wrote:

> Thanks anyway. What I need to know then, is how do I edit the grub.cfg
> file found in Computer > boot > grub2?

It is /boot/grub2/grub.cfg. There is no point in editing it directly (although it is a text file,
not binary), because it is automatically generated from others. You can edit it, of course, but it
will not survive long.

> (I am trying to maintain openSUSE as the default boot choice, and take a
> look at another distro, that way. If I install the other distro with
> it’s boot manager, that would change the menu and openSUSE would no
> longer be at the top, with it’s openSUSE graphics).

You probably edit these:

/etc/grub.d/40_custom
/etc/grub.d/41_custom

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” (Elessar))

[deano_ferrari]

@d_hinds

Thanks anyway. What I need to know then, is how do I edit the grub.cfg file found in Computer > boot > grub2?

It’s a binary file (as are others named device.map, there) and nautilus says they all are of an unknown type.

(I am trying to maintain openSUSE as the default boot choice, and take a look at another distro, that way. If I install the other distro with it’s boot manager, that would change the menu and openSUSE would no longer be at the top, with it’s openSUSE graphics).

TIA

Here’s a guide on this

https://wiki.archlinux.org/index.php/GRUB#GNU.2FLinux_menu_entry

Just remember, that grub.cfg lives in /boot/grub2/ directory with openSUSE (and UEFI-GPT is different again), so the ‘grub-mkconfig’ command gets run like this

grub-mkconfig -o /boot/grub2/grub.cfg

[arvidjaar]

@deano_ferrari

Here’s a guide on this

https://wiki.archlinux.org/index.php/GRUB#GNU.2FLinux_menu_entry

It tells to use hardcoded drive names (hdX,Y) which is in general wrong with grub2. What you should really do in almost all cases is to search for drive name at runtime using file name or filesystem UUID. Like

bor@opensuse:~/src/grub> sudo /usr/sbin/grub2-probe -t fs_uuid /boot/vmlinuz
root's password:
427a8168-dbd2-430d-9d3b-adbdf5189015
bor@opensuse:~/src/grub> sudo /usr/bin/grub2-mkrelpath  /boot/vmlinuz
/vmlinuz-3.11.6-4-desktop

and then put in grub.cfg

search --fs-uuid --set 427a8168-dbd2-430d-9d3b-adbdf5189015
linux /vmlinuz-3.11.6-4-desktop

Which is exactly what grub2 does when you run grub-mkconfig. If filesystem does not offer UUID, it can also generate one and create file with unique name which serves as label to identify this filesystem.

[user]

On 29/12/13 12:47, Carlos E. R. wrote:
> On 2013-12-29 02:06, d hinds wrote:
>
>> Thanks anyway. What I need to know then, is how do I edit the grub.cfg
>> file found in Computer > boot > grub2?
>
> It is /boot/grub2/grub.cfg. There is no point in editing it directly
> (although it is a text file, not binary), because it is automatically
> generated from others. You can edit it, of course, but it will not
> survive long.
>
>
>> (I am trying to maintain openSUSE as the default boot choice, and take a
>> look at another distro, that way. If I install the other distro with
>> it’s boot manager, that would change the menu and openSUSE would no
>> longer be at the top, with it’s openSUSE graphics).
>
> You probably edit these:
>
> /etc/grub.d/40_custom
> /etc/grub.d/41_custom

Though I am only an ordinary user who is neither an IT or software
professional, as many of the regular helpers and mods on these forums
are, I have just recently installed openSUSE 13.1 (XFCE) in a triple
boot mode (with Win XP & openSUSE 11.4 Gnome on other partitions on same
hdd) with grub2 to MBR and was easily able to modify the default boot
order (which, IMHO, is also very good as is because it defaults to the
last booted selection) by reading the following info:
10.2.2 The File /etc/default/grub #
http://activedoc.opensuse.org/book/opensuse-reference/chapter-10-the-boot-loader-grub2

and manually editing ‘/etc/default/grub’ file as follows:

Original - GRUB_DEFAULT=saved
Modified - GRUB_DEFAULT=3

Added - ‘GRUB_SAVEDEFAULT=false’ (this entry was not there in the
original file as it was not needed by the default settings).

---

Modified by YaST2. …2013

THIS FILE WILL BE PARTIALLY OVERWRITTEN by perl-Bootloader

For the new kernel it try to figure out old parameters. In case we are

not able to recognize it (e.g. change of flavor or strange install order
) it it use as fallback installation parameters from
/etc/sysconfig/bootloader

If you change this file, run ‘grub2-mkconfig -o /boot/grub2/grub.cfg’

afterwards to update

/boot/grub2/grub.cfg.

GRUB_DISTRIBUTOR=“openSUSE 13.1”
GRUB_DEFAULT=3
GRUB_SAVEDEFAULT=false

…]

Secondly, I was also able to boot from an old floppy grub bootdisk (I
use ext3 on my linux partitions and I have no idea if it will work with
ext4…I remember inode 128 BD would not boot an ext3 inode 256
formatted partition) using a usb floppy dive by using the the default
menu.lst entry below (which can be made even shorter by using
“/dev/sda10” (dev by device) option instead of ‘/dev/disk/by-id/…’).

title openSUSE 13.1 (Default Kernel)
root (hd0,9)
kernel /boot/vmlinuz root=/dev/disk/by-id/xxxx-part10
resume=/dev/disk/by-id/xxx-part1 splash=silent quiet showopts vga=0x317
initrd /boot/initrd

Cheers

[arvidjaar]

@jmartini

grub2 … defaults to the
last booted selection

It should not do it unless you explicitly told it to do it. If you are absolutely sure grub2 in openSUSE suddenly defaults to last booted menu entry - it is a bug.

Original - GRUB_DEFAULT=saved
Modified - GRUB_DEFAULT=3

For the benefit of future readers … GRUB_DEFAULT refers to entries in grub.cfg. grub.cfg is re-generated dynamically every time you e.g. install/remove kernel. Which means that absolute numbers may well be off next time.

If grub-mkconfig is used, it tries to generate unique identifiers (similar to UUID) for each menu entry. Algorithm tries to ensure that the same IDs will be generated every time for the same kernel name on the same partition. This looks like

menuentry 'openSUSE 13.1' --class 'opensuse-13-1' --class gnu-linux --class gnu --class os $menuentry_id_option **'gnulinux-simple-bf08b064-2753-45b5-9af1-4fab01c9cca5'** {

Those menu entries should preferably be used in GRUB_DEFAULT instead of hardcoded numbers. Alternatively you could use menu entry titles (like “openSUSE 13.1” above) but they are not guaranteed to be unique.

If you create custom entries, it is highly recommended to come up with some scheme for unique IDs.

And if you want to refer to entry in submenu, you need to put full “path” to this entry. E.g. in the case of

submenu 'Advanced options for openSUSE 13.1' $menuentry_id_option 'gnulinux-advanced-bf08b064-2753-45b5-9af1-4fab01c9cca5' {
        menuentry 'openSUSE 13.1, with Linux 3.11.6-4-desktop' --class 'opensuse-13-1' --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.11.6-4-desktop-advanced-bf08b064-2753-45b5-9af1-4fab01c9cca5' {

full path to menu entry would be

GRUB_DEFAULT="gnulinux-advanced-bf08b064-2753-45b5-9af1-4fab01c9cca5**>**gnulinux-3.11.6-4-desktop-advanced-bf08b064-2753-45b5-9af1-4fab01c9cca5"

i.e. IDs separated by “>” character. Of course you can also use numbers here (like “2>1”) with the same caveats that numbers are not stable.

Oh, and you can also continue to use GRUB_DEFAULT=saved and set default using “grub2-set-defaul <menuentry>” (where menuentry follows the same syntax). This makes re-creating of grub.cfg unnecessary.

Added - ‘GRUB_SAVEDEFAULT=false’ (this entry was not there in the
original file as it was not needed by the default settings).
This is default anyway, it should not be needed.

[user]

On 29/12/13 17:06, arvidjaar wrote:
>
> jmartini;2612192 Wrote:
>> grub2 … defaults to the
>> last booted selection
> It should not do it unless you explicitly told it to do it. If you are
> absolutely sure grub2 in openSUSE suddenly defaults to last booted menu
> entry - it is a bug.
‘GRUB_DEFAULT=saved’
The above was the default entry in /etc/default/grub and I changed that
to 2 and 3 and made no difference and defaulted to the top opeSUSE 13.1
menu entry.

>> Original - GRUB_DEFAULT=saved
>> Modified - GRUB_DEFAULT=3
> For the benefit of future readers … GRUB_DEFAULT refers to entries in
> grub.cfg. grub.cfg is re-generated dynamically every time you e.g.
> install/remove kernel. Which means that absolute numbers may well be off
> next time.
True if you add or remove additional kernels in your various multi-boot
systems but probably no problem for simple single kernel options like mine.

> If grub-mkconfig is used, it tries to generate unique identifiers
> (similar to UUID) for each menu entry. Algorithm tries to ensure that
> the same IDs will be generated every time for the same kernel name on
> the same partition. This looks like
> Code:
> --------------------
> menuentry ‘openSUSE 13.1’ --class ‘opensuse-13-1’ --class gnu-linux --class gnu --class os $menuentry_id_option ‘gnulinux-simple-bf08b064-2753-45b5-9af1-4fab01c9cca5’ {
> --------------------
>
> Those menu entries should preferably be used in GRUB_DEFAULT instead of
> hardcoded numbers. Alternatively you could use menu entry titles (like
> “openSUSE 13.1” above) but they are not guaranteed to be unique.
>
> If you create custom entries, it is highly recommended to come up with
> some scheme for unique IDs.
>
> And if you want to refer to entry in submenu, you need to put full
> “-path-” to this entry. E.g. in the case of
> Code:
> --------------------
> submenu ‘Advanced options for openSUSE 13.1’ $menuentry_id_option ‘gnulinux-advanced-bf08b064-2753-45b5-9af1-4fab01c9cca5’ {
> menuentry ‘openSUSE 13.1, with Linux 3.11.6-4-desktop’ --class ‘opensuse-13-1’ --class gnu-linux --class gnu --class os $menuentry_id_option ‘gnulinux-3.11.6-4-desktop-advanced-bf08b064-2753-45b5-9af1-4fab01c9cca5’ {
> --------------------
> full path to menu entry would be
> Code:
> --------------------
> GRUB_DEFAULT=“gnulinux-advanced-bf08b064-2753-45b5-9af1-4fab01c9cca5*>*gnulinux-3.11.6-4-desktop-advanced-bf08b064-2753-45b5-9af1-4fab01c9cca5”
> --------------------
> i.e. IDs separated by “>” character. Of course you can also use numbers
> here (like “2>1”) with the same caveats that numbers are not stable.
>
> Oh, and you can also continue to use GRUB_DEFAULT=saved and set default
> using “grub2-set-defaul <-menuentry->” (where menuentry follows the same
> syntax). This makes re-creating of grub.cfg unnecessary.
>
>> Added - ‘GRUB_SAVEDEFAULT=false’ (this entry was not there in the
>> original file as it was not needed by the default settings).This is default anyway, it should not be needed.

You just gave me a headache.

I will do a bit more checking on what I observed and report back to
confirm what I notice.

I followed the guide below to do my mods:

10.2.2.1 General Options #

This section details some of the options commonly used in the
/etc./default/grub file. For their complete list, see GNU GRUB manual.

GRUB_DEFAULT

Sets the default menu entry that will be booted next time the
computer is rebooted. It can be a numeric value, a complete menu entry
quotation, or “saved”. A few examples follow:

GRUB_DEFAULT=2 boots the third (counted from zero) boot menu entry.

GRUB_DEFAULT=“2>0” boots the first submenu entry of the third top
level menu entry.

GRUB_DEFAULT=“Example boot menu entry” boots the menu entry whose
title matches the quotation.

GRUB_DEFAULT=saved boots the entry specified by the grub2-reboot or
grub2-set-default commands. While grub2-reboot sets the default boot
entry for the next reboot only, grub2-set-default sets the default boot
entry until changed.

GRUB_SAVEDEFAULT

If set to true, it will automatically choose the last selected OS
from the boot menu as the default boot entry on the next boot. For this
to work, you also need to specify GRUB_DEFAULT=saved.

…]

http://activedoc.opensuse.org/book/opensuse-reference/chapter-10-the-boot-loader-grub2

[arvidjaar]

@jmartini

‘GRUB_DEFAULT=saved’
The above was the default entry in /etc/default/grub

It does not mean it will save anything as was implied by your description. It means it will use whatever is saved in environment file, but you can set it once using grub2-set-default and it will not be changed even if you select different entry in menu. Unless you also set GRUB_SAVEDEFAULT=true

and I changed that
to 2 and 3 and made no difference and defaulted to the top opeSUSE 13.1
menu entry.
Did you run grub2-mkconfig after that? Just to be sure. Also if it cannot find menu entry, it defaults to the very first one. And because by default there is just a single menu entry and a single submenu, entries number 2 and 3 simply do not exist. 0 is the first (and default) entry and 1 is submenu.

True if you add or remove additional kernels in your various multi-boot
systems but probably no problem for simple single kernel options like mine.

Well … even without multiboot you still get kernel updates every now and then. Also it ensures future compatibility should grub2 implement more run time detection (and possibly skip some menu entries).

GRUB_DEFAULT=saved boots the entry specified by the grub2-reboot

No more true for 13.1. grub-reboot was reimplemented to not depend on “saved”.

[user]

On 29/12/13 19:16, arvidjaar wrote:
>
> jmartini;2612206 Wrote:
>>
>> ‘GRUB_DEFAULT=saved’
>> The above was the default entry in /etc/default/grub

> It does not mean it will save anything as was implied by your
> description.
OK, I see know how and why I assumed things that are not true and I
apologise for that and credit be to your expertise for pointing it out.

> It means it will use whatever is saved in environment file,
> but you can set it once using grub2-set-default and it will not be
> changed even if you select different entry in menu.
I admit that I did not read and comprehend this option below fully:

GRUB_DEFAULT=saved boots the entry specified by the grub2-reboot or
grub2-set-default commands. While grub2-reboot sets the default boot
entry for the next reboot only, grub2-set-default sets the default
boot entry until changed.

>Unless you also set GRUB_SAVEDEFAULT=true
I have it set to false and it is working now.
GRUB_DEFAULT=3
GRUB_SAVEDEFAULT=false

What is the problem with the above setting as it seems to be working OK
for me (for now)?

>> and I changed that
>> to 2 and 3 and made no difference and defaulted to the top opeSUSE 13.1
>> menu entry.

>> Did you run grub2-mkconfig after that? Just to be sure.
Yes, several times.

>Also if it
> cannot find menu entry, it defaults to the very first one. And because
> by default there is just a single menu entry and a single submenu,
> entries number 2 and 3 simply do not exist. 0 is the first (and default)
> entry and 1 is submenu.
It found XP and openSUSE 11.4 with no problems and they were part of my
boot menu options.

>> True if you add or remove additional kernels in your various multi-boot
>> systems but probably no problem for simple single kernel options like
>> mine.
> Well … even without multiboot you still get kernel updates every now
> and then. Also it ensures future compatibility should grub2 implement
> more run time detection (and possibly skip some menu entries).
I generally use one kernel and one openSUSE version for everyday use and in
rare occasions I used a second kernel, I just manually selected my OS until
I was sure the new one was stable and then removed the old or alternative
one and my default selection was back to normal.

>>
>> GRUB_DEFAULT=saved boots the entry specified by the grub2-reboot
> No more true for 13.1. grub-reboot was reimplemented to not depend on
> “saved”.
OK and thank you for your expertise again.

Cheers

[d_hinds]

Although this thread shows a number of helpful comments I am still unclear about the best course of action and am hoping to define the alternatives better as a result of this post.

The subject is: Adding an Entry to the oSUSE Bootloader. I also wanted to to eliminate the listings for some of the OS’s I no longer use.

Apparently, Yast’s Bootloader Utility can not be used to resolve these issues (add some &/or subtract other OS’s from the boot menu). And as I now understand it, grub2 generates a new list every time it boots.

So maybe what I need to do is eliminate the partitions on which these unused (or seldom used) OS’s are located.

Otherwise, what can be done must occur via a terminal (as I understood the comments kindly provided).

I am also considering the realization of more radical changes. To date, I have been installing my Linux distros on logical partitions within an extended partition and have considered btrfs as an experimental file system and format that offers some benefits, but not as being something that is fundamentally different.

That may be incorrect. For example: Someone on the forum of the OS I installed without a bootloader (Fedora 20 Gnome 62bit - Fedora is an OS I have never installed), recommended dedicating an entire disk to btrfs, which made some sense because I recently tried to install Debian kFreeBSD (but was unable to complete the installation, presumably due to a problem with my NVidia card). IAC, the k stands for kernel and the file system is ZFS, which (AIUI), shares various goals and attributes with btrfs.

And during the installation, ZFS takes over to do whatever it does. (Whether that is good or bad is another matter - time will tell - if it works, that’s good. If it breaks, not so much).

In short: I am thinking about transferring the two systems I’ve been using (openSUSE and a Debian derivative) to a disk used previously for backups, along with this new installation, which would be the first on that disk.

The question is, how difficult would it be for me to clone my openSUSE installation to the other drive, afterwords? (This was originally an 11.3 net installation that was successfully upgraded to 13.1 via zypper dup, following instructions. My Debian Testing derivative broke recently and oSUSE is performing better than ever. (I have formed no opinion about Fedora, since I have never installed it - just Funduntu, once which was highly configurable -like oSUSE- but was KDE, which is not what I prefer - it’s fine but I have found it to be is a bit fancy and slower than Gnome and Mate, which I am more familiar with). The Fedora folks on the forum are very helpful, with some from RedHat intervening (as do SUSE Enterprise persons here)?

As things stand, I want move ahead on this carefully and protect my oSUSE installation. (The Debian derivative now requires log in as Root and that prevents me from using the data it saves in other OS’s, unless I change the Permissions, from there). So oSUSE is my main installation, at present. V. 13.1 doesn’t slow down as previous versions did after a couple of days without rebooting - so far.

Do oSUSE veterans share the opinion that brtfs is best implemented as a full disk installation? Are the benefits worth it? And would I be able to install other OS’s on that same disk?

I assume that an extended partition can not be used. Is that correct? (My openSUSE has two btrfs partitions within an extended partition at present, so maybe it isn’t - but we may be talking about a different implementation of btrfs). I was hoping to get this resolved today, but that may not be possible.

TIA

[gogalthorp]

IMO at least right now BTRFS is not worth the hassle. Also all the bells and whistles that are promised are not thee yet.

I suppose you could have one huge partition but you can do that without btrfs. Putting things on separate file systems is a safety net of sort. Putting all your eggs in one basket makes it difficult to migrate your data to new versions and new OS.

[d_hinds]

@gogalthorp

IMO at least right now BTRFS is not worth the hassle. Also all the bells and whistles that are promised are not thee yet.

I suppose you could have one huge partition but you can do that without btrfs. Putting things on separate file systems is a safety net of sort. Putting all your eggs in one basket makes it difficult to migrate your data to new versions and new OS.

That too makes sense.

I should have asked about the alternative boot loaders: Yast’s Boot Loader Setting provides the choice of ELILO, Grub, Grub2, Grub2-EFI and LILO.

Perhaps one of the others would be easier to configure. I’m thinking about removing the partitions and entries for all except 2 or 3. (This computer has been a test bed since mid 2010 and some of the distros installed don’t even exist any more).

Thanks for the input.

[user]

> I will do a bit more checking on what I observed and report back to
> confirm what I notice.
>
> I followed the guide below to do my mods:
>
> 10.2.2.1 General Options #
>
> This section details some of the options commonly used in the
> /etc./default/grub file. For their complete list, see GNU GRUB manual.
>
> GRUB_DEFAULT
>
> Sets the default menu entry that will be booted next time the
> computer is rebooted. It can be a numeric value, a complete menu entry
> quotation, or “saved”. A few examples follow:
>
> GRUB_DEFAULT=2 boots the third (counted from zero) boot menu entry.
>
> GRUB_DEFAULT=“2>0” boots the first submenu entry of the third top
> level menu entry.
>
> GRUB_DEFAULT=“Example boot menu entry” boots the menu entry whose
> title matches the quotation.
>
> GRUB_DEFAULT=saved boots the entry specified by the grub2-reboot or
> grub2-set-default commands. While grub2-reboot sets the default boot
> entry for the next reboot only, grub2-set-default sets the default boot
> entry until changed.

---

> GRUB_SAVEDEFAULT
> If set to true, it will automatically choose the last selected OS
> from the boot menu as the default boot entry on the next boot. For this
> to work, you also need to specify GRUB_DEFAULT=saved.
I tested this option (booted a couple of times each into my three OS
options)
and can confirm that it works as it says above and, IMO,
is a very good choice for people who dual or triple boot and
predominantly use one of those OS installs and this will be what I will
now use. It is a simple and elegant option!

Secondly, ‘grub2-select-default’ command can also be used with this
option to manually choose your next boot option as well.

Cheers

> …]
>
> http://activedoc.opensuse.org/book/opensuse-reference/chapter-10-the-boot-loader-grub2
>

[robin_listas]

On 2013-12-29 21:06, d hinds wrote:

> extended partition and have considered btrfs as an experimental file
> system and format that offers some benefits, but not as being something
> that is fundamentally different.

Oh, yes, it is very different.

> That may be incorrect. For example: Someone on the forum of the OS I
> installed without a bootloader (Fedora 20 Gnome 62bit - Fedora is an OS
> I have never installed), recommended dedicating an entire disk to btrfs,

It has something akin to volumes which you can use instead of partitions. Don’t ask me to explain, I
don’t really understand it.

> Do oSUSE veterans share the opinion that brtfs is best implemented as a
> full disk installation? Are the benefits worth it? And would I be able
> to install other OS’s on that same disk?

It has both benefits and dangers. You have to understand what it has to offer and then consider
using it. Using it as any other filesystem is pointless, confusing, and even dangerous.

> I assume that an extended partition can not be used. Is that correct?

Why not?

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” (Elessar))

[d_hinds]

A new listing now appears at the end of oSUSE’s Grub2 Boot Menu and boots Fedora v. 20 (Heisenberg), which was installed to a different hard drive without installing Grub, since the installation insisted on installing on the same drive, which I didn’t want or want to allow.

What did I do? Nothing. This thread served to illuminate the dynamic nature of Grub, which is generated anew each time the computer boots on searching existing partitions. Fedora never wrote to Grub but oSUSE’s Grub installatig correctly identified its presence and (surprisingly to me) said "here it is, Fedora - on sdb3 where you installed it with so much of a hassle - but it did install and is now bootable).

Thanks to all for your comments, suggestions and links. 2014 is almost here and will hopefully be better than this one was.

[gogalthorp]

AFAIK Grub does not scan disk on each reboot. But it does after some updates like a Kernel updates. Also in Yast-boot section you can check scan for other OS box which should trigger a grub2-mkconfig