[opensuse] Leap + Tumbleweed + boot partition
I bought a computer with Leap 15.0 preinstalled on an SSD, and I also wanted to install Tumbleweed on the disk. For reasons detailed below, I did this without installing a bootloader for Tumbleweed, but since Tumbleweed is frequently updated, including grub2, I think it would be better to install the bootloader in Tumbleweed. Due to my lack of knowledge, I would be grateful for advice on how to do that safely. Some specifics follow about the disk and what I did to install Tumbleweed. The SSD had three partitions: /boot, / (root) and swap. I shrank the root partition (formatted as ext4) and added a btrfs partition for Tumbleweed. I first left /boot and swap as is, but the Tumbleweed installer said there was no bootable partition (I don't remember the exact wording, something like no BIOS boot table). I then tried deleting the /boot partition and adding it again, selecting "BIOS Boot" as the partition ID, but the installer still said there was no bootable partition. I also tried different file systems to format /boot -- originally it was FAT and I also tried XFS and ext3 -- but that made no difference. So finally, I left the /boot partition unchanged but unmounted it and proceeded with the installation. At the summary I then changed the boot setup to prevent any boot loader being installed and any changes made to the MBR. The installer said I might end up with an unbootable system, but I went ahead anyway. The installation completed and on rebooting the boot screen showed only Leap 15.0 as before, but after running grub2-mkconfig in Leap, Tumbleweed was found and I could boot it and it seems to be fine. The disk has GPT with protective MBR. As noted the /boot partition is formatted as FAT and also contains a directory efi, which is populated in the running Leap, which mounts /boot/efi, but in the running Tumbleweed, where /boot is not a separate partition, after mounting the partition Leap sees as /boot/efi, the efi directory is empty (in the running Tumbleweed). I do not plan to install any MS-Windows system, but I do plan to install other Linux-based systems besides Tumbleweed, and possibly a *BSD system. How can I install the bootloader in Tumbleweed -- either from the currently installed Tumbleweed or by reinstalling it -- without risking making both Tumbleweed and Leap unbootable? If that requires deleting the existing /boot partition and add it anew, is it necessary, given the systems I plan to install, to have the efi directory, and if so, do I just have to make /boot/efi a mountpoint, and if not, what else to I need to do to make sure it exists and gets populated as required (if it's required)? And if the efi directory is not needed, what would be the recommended file system for the boot partition? I also have a question concerning having a separate /boot partition shared by Leap, Tumbleweed and any other systems I install: in each system the directory /boot contains versioned files of the kernel, config, etc., but there are also symlinks vmlinuz and initrd pointing to the latest version installed in the system; if Leap and Tumbleweed (and other Linux-based systems) populate the same /boot directory, the last one installed would override existing symlinks, so I don't see how this can work. Is it possible for different systems to use the same /boot directory, installed on a separate partition, and if not, where do the files used for booting different systems need to go, when a separate /boot partition is used? Thanks, Steve Berman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/05/2019 19.58, Stephen Berman wrote:
I bought a computer with Leap 15.0 preinstalled on an SSD,
New, from a shop? What brand/model? I'm curious, selling Linux preinstalled is rare.
and I also wanted to install Tumbleweed on the disk. For reasons detailed below, I did this without installing a bootloader for Tumbleweed, but since Tumbleweed is frequently updated, including grub2, I think it would be better to install the bootloader in Tumbleweed. Due to my lack of knowledge, I would be grateful for advice on how to do that safely. Some specifics follow about the disk and what I did to install Tumbleweed.
The SSD had three partitions: /boot, / (root) and swap. I shrank the root partition (formatted as ext4) and added a btrfs partition for Tumbleweed. I first left /boot and swap as is, but the Tumbleweed installer said there was no bootable partition (I don't remember the exact wording, something like no BIOS boot table). I then tried deleting the /boot partition and adding it again, selecting "BIOS Boot" as the partition ID, but the installer still said there was no bootable partition. I also tried different file systems to format /boot -- originally it was FAT and I also tried XFS and ext3 -- but that made no difference.
It is *another* partition. Very small, perhaps 8 megabytes. Why didn't you ask here before doing changes?
So finally, I left the /boot partition unchanged but unmounted it and proceeded with the installation. At the summary I then changed the boot setup to prevent any boot loader being installed and any changes made to the MBR. The installer said I might end up with an unbootable system, but I went ahead anyway. The installation completed and on rebooting the boot screen showed only Leap 15.0 as before, but after running grub2-mkconfig in Leap, Tumbleweed was found and I could boot it and it seems to be fine.
The disk has GPT with protective MBR. As noted the /boot partition is formatted as FAT and also contains a directory efi, which is populated in the running Leap, which mounts /boot/efi,
Well, first step would be to recover the original.
but in the running Tumbleweed, where /boot is not a separate partition, after mounting the partition Leap sees as /boot/efi, the efi directory is empty (in the running Tumbleweed). I do not plan to install any MS-Windows system, but I do plan to install other Linux-based systems besides Tumbleweed, and possibly a *BSD system. How can I install the bootloader in Tumbleweed -- either from the currently installed Tumbleweed or by reinstalling it -- without risking making both Tumbleweed and Leap unbootable? If that requires deleting the existing /boot partition and add it anew, is it necessary, given the systems I plan to install, to have the efi directory, and if so, do I just have to make /boot/efi a mountpoint, and if not, what else to I need to do to make sure it exists and gets populated as required (if it's required)? And if the efi directory is not needed, what would be the recommended file system for the boot partition?
Please run this script after booting into openSUSE and post results to 'SUSE Paste' (http://susepaste.org/) https://github.com/arvidjaar/bootinfoscript/raw/master/bootinfoscript
I also have a question concerning having a separate /boot partition shared by Leap, Tumbleweed and any other systems I install:
You can not share the /boot partition. -- Cheers / Saludos, Carlos E. R. (from openSUSE, Leap 15.1 x86_64 (ssd-test)) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Op zaterdag 11 mei 2019 20:11:25 CEST schreef Carlos E. R.:
On 11/05/2019 19.58, Stephen Berman wrote:
I bought a computer with Leap 15.0 preinstalled on an SSD,
New, from a shop? What brand/model? I'm curious, selling Linux preinstalled is rare.
and I also wanted to install Tumbleweed on the disk. For reasons detailed below, I did this without installing a bootloader for Tumbleweed, but since Tumbleweed is frequently updated, including grub2, I think it would be better to install the bootloader in Tumbleweed. Due to my lack of knowledge, I would be grateful for advice on how to do that safely. Some specifics follow about the disk and what I did to install Tumbleweed.
The SSD had three partitions: /boot, / (root) and swap. I shrank the root partition (formatted as ext4) and added a btrfs partition for Tumbleweed. I first left /boot and swap as is, but the Tumbleweed installer said there was no bootable partition (I don't remember the exact wording, something like no BIOS boot table). I then tried deleting the /boot partition and adding it again, selecting "BIOS Boot" as the partition ID, but the installer still said there was no bootable partition. I also tried different file systems to format /boot -- originally it was FAT and I also tried XFS and ext3 -- but that made no difference.
It is *another* partition. Very small, perhaps 8 megabytes. Why didn't you ask here before doing changes?
So finally, I left the /boot partition unchanged but
unmounted it and proceeded with the installation. At the summary I then changed the boot setup to prevent any boot loader being installed and any changes made to the MBR. The installer said I might end up with an unbootable system, but I went ahead anyway. The installation completed and on rebooting the boot screen showed only Leap 15.0 as before, but after running grub2-mkconfig in Leap, Tumbleweed was found and I could boot it and it seems to be fine.
The disk has GPT with protective MBR. As noted the /boot partition is formatted as FAT and also contains a directory efi, which is populated in the running Leap, which mounts /boot/efi,
Well, first step would be to recover the original.
but in the running Tumbleweed, where /boot is not a separate partition, after mounting the partition Leap sees as /boot/efi, the efi directory is empty (in the running Tumbleweed). I do not plan to install any MS-Windows system, but I do plan to install other Linux-based systems besides Tumbleweed, and possibly a *BSD system. How can I install the bootloader in Tumbleweed -- either from the currently installed Tumbleweed or by reinstalling it -- without risking making both Tumbleweed and Leap unbootable? If that requires deleting the existing /boot partition and add it anew, is it necessary, given the systems I plan to install, to have the efi directory, and if so, do I just have to make /boot/efi a mountpoint, and if not, what else to I need to do to make sure it exists and gets populated as required (if it's required)? And if the efi directory is not needed, what would be the recommended file system for the boot partition?
Please run this script after booting into openSUSE and post results to 'SUSE Paste' (http://susepaste.org/)
https://github.com/arvidjaar/bootinfoscript/raw/master/bootinfoscript
I also have a question concerning having a separate /boot partition
shared by Leap, Tumbleweed and any other systems I install: You can not share the /boot partition. O? I have: knurpht@Knurpht-HP:~> cat /leaproot/etc/fstab | grep boot/efi UUID=AC45-5602 /boot/efi vfat defaults 0 0 knurpht@Knurpht-HP:~> cat /etc/fstab | grep boot/efi UUID=AC45-5602 /boot/efi vfat defaults 0 0 knurpht@Knurpht-HP:~>
where the top one is Leap 15.0's, the bottom one is Tumbleweed's. -- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Knurpht-openSUSE composed on 2019-05-11 20:27 (UTC+0200):
Carlos E. R. composed:
You can not share the /boot partition.
O? I have: knurpht@Knurpht-HP:~> cat /leaproot/etc/fstab | grep boot/efi UUID=AC45-5602 /boot/efi vfat defaults 0 0 knurpht@Knurpht-HP:~> cat /etc/fstab | grep boot/efi UUID=AC45-5602 /boot/efi vfat defaults 0 0 knurpht@Knurpht-HP:~>
where the top one is Leap 15.0's, the bottom one is Tumbleweed's.
I guess you don't make use of the kernel and initrd symlinks created by kernel installation in your boot menus? -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/05/2019 20.27, Knurpht-openSUSE wrote:
Op zaterdag 11 mei 2019 20:11:25 CEST schreef Carlos E. R.:
On 11/05/2019 19.58, Stephen Berman wrote:
You can not share the /boot partition. O? I have:
But you are an expert. You don't count :-p
knurpht@Knurpht-HP:~> cat /leaproot/etc/fstab | grep boot/efi UUID=AC45-5602 /boot/efi vfat defaults 0 0 knurpht@Knurpht-HP:~> cat /etc/fstab | grep boot/efi UUID=AC45-5602 /boot/efi vfat defaults 0 0 knurpht@Knurpht-HP:~>
where the top one is Leap 15.0's, the bottom one is Tumbleweed's.
But that's the EFI partition, it is designed to be shared. I was talking about the /boot partition. -- Cheers / Saludos, Carlos E. R. (from openSUSE, Leap 15.1 x86_64 (ssd-test)) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Op zaterdag 11 mei 2019 22:21:32 CEST schreef Carlos E. R.:
On 11/05/2019 20.27, Knurpht-openSUSE wrote:
Op zaterdag 11 mei 2019 20:11:25 CEST schreef Carlos E. R.:
On 11/05/2019 19.58, Stephen Berman wrote:
You can not share the /boot partition.
O? I have: But you are an expert. You don't count :-p
knurpht@Knurpht-HP:~> cat /leaproot/etc/fstab | grep boot/efi UUID=AC45-5602 /boot/efi vfat defaults 0 0 knurpht@Knurpht-HP:~> cat /etc/fstab | grep boot/efi UUID=AC45-5602 /boot/efi vfat defaults 0 0 knurpht@Knurpht-HP:~>
where the top one is Leap 15.0's, the bottom one is Tumbleweed's.
But that's the EFI partition, it is designed to be shared. I was talking about the /boot partition. Ah, OK, you're right. Don't know why one could not share a parition mounted on /boot ....
-- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, 11 May 2019 22:39:46 +0200 Knurpht-openSUSE <knurpht@opensuse.org> wrote:
Op zaterdag 11 mei 2019 22:21:32 CEST schreef Carlos E. R.:
On 11/05/2019 20.27, Knurpht-openSUSE wrote:
Op zaterdag 11 mei 2019 20:11:25 CEST schreef Carlos E. R.:
On 11/05/2019 19.58, Stephen Berman wrote:
You can not share the /boot partition.
O? I have: But you are an expert. You don't count :-p
knurpht@Knurpht-HP:~> cat /leaproot/etc/fstab | grep boot/efi UUID=AC45-5602 /boot/efi vfat defaults 0 0 knurpht@Knurpht-HP:~> cat /etc/fstab | grep boot/efi UUID=AC45-5602 /boot/efi vfat defaults 0 0 knurpht@Knurpht-HP:~>
where the top one is Leap 15.0's, the bottom one is Tumbleweed's.
As I wrote, I also have /boot/efi mounted in Leap 15.0. Does that mean Leap is using UEFI to boot? If so, how can I get Tumbleweed to use it as well? As I also wrote in my followup to Carlos E.R., I was unable to do this during the Tumbleweed installation. Should it be possible and if so, how? A possibly relevant datapoint: When I compare the /boot directories in my Leap and Tumbleweed installations, in addition to /boot in Tumbleweed lacking the efi subdirectory, I see that, while in both installations the grub2 subdirectory contains the subdirectory x86_64-efi, in Leap it is filled with 267 *.mod files, while in Tumbleweed it is empty (both installations also contain the directory i386-pc under grub2; in Leap it contains 277 *.mod files, in Tumbleweed 278). Is this another indication that the bootloader (in Leap) is using UEFI?
But that's the EFI partition, it is designed to be shared. I was talking about the /boot partition. Ah, OK, you're right. Don't know why one could not share a parition mounted on /boot ....
Can you elaborate? What about the vmlinuz and initrd symlinks? Are they not necessary? Steve Berman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/05/2019 00.53, Stephen Berman wrote:
On Sat, 11 May 2019 22:39:46 +0200 Knurpht-openSUSE <knurpht@opensuse.org> wrote:
Op zaterdag 11 mei 2019 22:21:32 CEST schreef Carlos E. R.:
On 11/05/2019 20.27, Knurpht-openSUSE wrote:
Op zaterdag 11 mei 2019 20:11:25 CEST schreef Carlos E. R.:
On 11/05/2019 19.58, Stephen Berman wrote:
You can not share the /boot partition.
O? I have: But you are an expert. You don't count :-p
knurpht@Knurpht-HP:~> cat /leaproot/etc/fstab | grep boot/efi UUID=AC45-5602 /boot/efi vfat defaults 0 0 knurpht@Knurpht-HP:~> cat /etc/fstab | grep boot/efi UUID=AC45-5602 /boot/efi vfat defaults 0 0 knurpht@Knurpht-HP:~>
where the top one is Leap 15.0's, the bottom one is Tumbleweed's.
As I wrote, I also have /boot/efi mounted in Leap 15.0. Does that mean Leap is using UEFI to boot? If so, how can I get Tumbleweed to use it as well? As I also wrote in my followup to Carlos E.R., I was unable to do this during the Tumbleweed installation. Should it be possible and if so, how?
A possibly relevant datapoint: When I compare the /boot directories in my Leap and Tumbleweed installations, in addition to /boot in Tumbleweed lacking the efi subdirectory, I see that, while in both installations the grub2 subdirectory contains the subdirectory x86_64-efi, in Leap it is filled with 267 *.mod files, while in Tumbleweed it is empty (both installations also contain the directory i386-pc under grub2; in Leap it contains 277 *.mod files, in Tumbleweed 278). Is this another indication that the bootloader (in Leap) is using UEFI?
Well, the installer said the system might be unbootable, and then you "changed the boot setup to prevent any boot loader being installed". No surprise there are missing things. And indeed, it was unbootable (TW). -- Cheers / Saludos, Carlos E. R. (from openSUSE, Leap 15.1 x86_64 (ssd-test)) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Stephen Berman composed on 2019-05-12 00:53 (UTC+0200):
As I wrote, I also have /boot/efi mounted in Leap 15.0. Does that mean Leap is using UEFI to boot?
I'm pretty sure no astute Linux reseller is going to configure a new system to use the legacy MBR system unless specifically requested to do so, so yes. :-)
If so, how can I get Tumbleweed to use it as well? As I also wrote in my followup to Carlos E.R., I was unable to do this during the Tumbleweed installation. Should it be possible and if so, how?
A possibly relevant datapoint: When I compare the /boot directories in my Leap and Tumbleweed installations, in addition to /boot in Tumbleweed lacking the efi subdirectory, I see that, while in both installations the grub2 subdirectory contains the subdirectory x86_64-efi, in Leap it is filled with 267 *.mod files, while in Tumbleweed it is empty (both installations also contain the directory i386-pc under grub2; in Leap it contains 277 *.mod files, in Tumbleweed 278). Is this another indication that the bootloader (in Leap) is using UEFI?
Absolutely! Check if you have /etc/default/grub on your TW. If it's there, then change GRUB_DISTRIBUTOR="opensuse" to GRUB_DISTRIBUTOR="opensusetw" or whatever suits your fancy to make them distinguishable where there would otherwise be conflict. I filed a bug last summer requesting this ability be included at installation time: https://bugzilla.opensuse.org/show_bug.cgi?id=1101756 This should enable installing Grub EFI from TW to takeover from Leap by the simple YaST2 EFI Grub installation process, which would I expect (not enough practice with fresh installations to be sure) change the values resulting from the command: efibootmgr Right now you'll find the default entry points to a directory "opensuse" in /boot/efi/EFI/ that Leap installation put there. After installing Grub in TW I expect you'll find it points to a new TW entry. The problem will then become keeping that order, since a new kernel installation on Leap (I expect) will change the order back to having Leap first. I work around that potential problem with an fstab alteration. I comment the line that would mount the ESP partition in every installation except the one I want in control of boot. That way nothing during normal updates messes with UEFI's NVRAM or changes what the first entries in my Grub menu look like. On mine I change them all, so would have these according to the release: GRUB_DISTRIBUTOR="debian10" GRUB_DISTRIBUTOR="linuxmint19" GRUB_DISTRIBUTOR="opensuse423" GRUB_DISTRIBUTOR="opensuse150" GRUB_DISTRIBUTOR="opensuse151" GRUB_DISTRIBUTOR="opensusetw" GRUB_DISTRIBUTOR="tubuntu" Thus in /boot/efi/EFI/ there is no longer a directory named opensuse, only these: BOOT # for Memtest 7 debian10 linuxmint19 opensuse150 opensusetw tubuntu because I didn't allow bootloader installation in each.
Ah, OK, you're right. Don't know why one could not share a parition mounted on /boot ....
Can you elaborate?
What about the vmlinuz and initrd symlinks? Are they not necessary? AFAICT, they normally function as mere convenience. When (unfortunately or otherwise) booting to a bare Grub> prompt, they are easier to remember to type
If a /boot/ is shared between installations that use symlinks to kernel and initrd in bootloader menu configurations, each kernel installation would result in usurpation of the symlinks from whichever distro installation last updated, pretty much like when Windows and Linux installers overwrite the MBR with incompatible code without asking first. than a whole kernel-name-and-version string. ISTR many moons ago with Grub Legacy that they may have been used to a limited extent in menu.lst. For my multiboot configurations, the symlinks have been vital for well over a decade, and continue to be even using UEFI (in /boot/grub2/custom.cfg e.g. <https://forums.opensuse.org/showthread.php/533087-How-to-have-a-custom-UEFI-grub-menu-for-a-multiboot-system?p=2880389#post2880389>). I recommend reading these pages produced by some of our more industrious and/or UEFI-enlightened cohorts before proceeding: <https://nwrickert2.wordpress.com/2017/12/19/handling-multiple-opensuse-version-with-uefi/> <https://forums.opensuse.org/showthread.php/533087-How-to-have-a-custom-UEFI-grub-menu-for-a-multiboot-system> -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, 12 May 2019 01:55:06 -0400 Felix Miata <mrmazda@earthlink.net> wrote:
Stephen Berman composed on 2019-05-12 00:53 (UTC+0200):
As I wrote, I also have /boot/efi mounted in Leap 15.0. Does that mean Leap is using UEFI to boot?
I'm pretty sure no astute Linux reseller is going to configure a new system to use the legacy MBR system unless specifically requested to do so, so yes. :-)
If so, how can I get Tumbleweed to use it as well? As I also wrote in my followup to Carlos E.R., I was unable to do this during the Tumbleweed installation. Should it be possible and if so, how?
A possibly relevant datapoint: When I compare the /boot directories in my Leap and Tumbleweed installations, in addition to /boot in Tumbleweed lacking the efi subdirectory, I see that, while in both installations the grub2 subdirectory contains the subdirectory x86_64-efi, in Leap it is filled with 267 *.mod files, while in Tumbleweed it is empty (both installations also contain the directory i386-pc under grub2; in Leap it contains 277 *.mod files, in Tumbleweed 278). Is this another indication that the bootloader (in Leap) is using UEFI?
Absolutely!
Check if you have /etc/default/grub on your TW. If it's there, then change
GRUB_DISTRIBUTOR="opensuse"
to
GRUB_DISTRIBUTOR="opensusetw"
or whatever suits your fancy to make them distinguishable where there would otherwise be conflict. I filed a bug last summer requesting this ability be included at installation time: https://bugzilla.opensuse.org/show_bug.cgi?id=1101756
Here on both Leap and TW it's unset, which according to the preceding comment in the file means "determine the value from /etc/os-release"; the latter files assign values to NAME, VERSION, ID, PRETTY_NAME, CPE_NAME and ID_LIKE that are distinct in both systems. Do you nevertheless recommend setting GRUB_DISTRIBUTOR?
This should enable installing Grub EFI from TW to takeover from Leap by the simple YaST2 EFI Grub installation process, which would I expect (not enough practice with fresh installations to be sure) change the values resulting from the command:
efibootmgr
Are you saying to select, in the Boot Code Options tab of the YaST2 Boot Loader module, "GRUB2 for EFI" from the dropdown list under Boot Loader? And do this in the installed TW or during the (re)installation? And should I then check "Enable Secure Boot Support"? (I think secure boot is disabled in my BIOS ) And what should I set "Protective MBR flag" to: "set", "remove", or "do not change"? Also, if I select "GRUB2 for EFI" will the bootloader be installed in the existing /boot partition, overwriting what is there now from Leap? Note that when I open the Boot Loader module in Leap, it shows GRUB2 as the boot loader, and "Boot from Partition", "Set active Flag in Partition Table for Boot Partition" and "Write generic Boot Code to MBR" are checked and "Protective MBR flag" is set to "do not change". Is this display expected even if the bootloader is using EFI?
Right now you'll find the default entry points to a directory "opensuse" in /boot/efi/EFI/ that Leap installation put there. After installing Grub in TW I expect you'll find it points to a new TW entry.
Are you saying that if I select "GRUB2 for EFI" as above, another directory will be added under /boot/efi/EFI? Does the name of that directory depend on setting GRUB_DISTRIBUTOR as above or will it automatically differ from "opensuse"? From what you write below, it seems you mean the former, but I'd like to be certain.
The problem will then become keeping that order, since a new kernel installation on Leap (I expect) will change the order back to having Leap first.
I work around that potential problem with an fstab alteration. I comment the line that would mount the ESP partition in every installation except the one I want in ^^^ Do you mean "EFI" here? If not, what is the ESP partition?
control of boot. That way nothing during normal updates messes with UEFI's NVRAM or changes what the first entries in my Grub menu look like.
On mine I change them all, so would have these according to the release:
GRUB_DISTRIBUTOR="debian10" GRUB_DISTRIBUTOR="linuxmint19" GRUB_DISTRIBUTOR="opensuse423" GRUB_DISTRIBUTOR="opensuse150" GRUB_DISTRIBUTOR="opensuse151" GRUB_DISTRIBUTOR="opensusetw" GRUB_DISTRIBUTOR="tubuntu"
Thus in /boot/efi/EFI/ there is no longer a directory named opensuse, only these:
BOOT # for Memtest 7 debian10 linuxmint19 opensuse150 opensusetw tubuntu
because I didn't allow bootloader installation in each.
Ah, OK, you're right. Don't know why one could not share a parition mounted on /boot ....
Can you elaborate?
If a /boot/ is shared between installations that use symlinks to kernel and initrd in bootloader menu configurations, each kernel installation would result in usurpation of the symlinks from whichever distro installation last updated, pretty much like when Windows and Linux installers overwrite the MBR with incompatible code without asking first.
Yes, this is what I would expect.
What about the vmlinuz and initrd symlinks? Are they not necessary? AFAICT, they normally function as mere convenience. When (unfortunately or otherwise) booting to a bare Grub> prompt, they are easier to remember to type than a whole kernel-name-and-version string. ISTR many moons ago with Grub Legacy that they may have been used to a limited extent in menu.lst. For my multiboot configurations, the symlinks have been vital for well over a decade, and continue to be even using UEFI (in /boot/grub2/custom.cfg e.g. <https://forums.opensuse.org/showthread.php/533087-How-to-have-a-custom-UEFI-grub-menu-for-a-multiboot-system?p=2880389#post2880389>).
I recommend reading these pages produced by some of our more industrious and/or UEFI-enlightened cohorts before proceeding:
<https://nwrickert2.wordpress.com/2017/12/19/handling-multiple-opensuse-version-with-uefi/> <https://forums.opensuse.org/showthread.php/533087-How-to-have-a-custom-UEFI-grub-menu-for-a-multiboot-system>
Thanks, these are very useful. As I wrote in another post, it looks like I have a mix of EFI and legacy BIOS booting, which AFAICT is either how the machine was delivered to me or a result of my running grub2-mkconfig in Leap after installing TW, in order to make the latter appear in the boot menu. Unless I get urgent advice to the contrary, I plan to reinstall TW and try to use GRUB2 for EFI. Steve Berman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/05/2019 16.29, Stephen Berman wrote:
On Sun, 12 May 2019 01:55:06 -0400 Felix Miata <mrmazda@earthlink.net> wrote:
Stephen Berman composed on 2019-05-12 00:53 (UTC+0200):
As I wrote, I also have /boot/efi mounted in Leap 15.0. Does that mean Leap is using UEFI to boot?
I'm pretty sure no astute Linux reseller is going to configure a new system to use the legacy MBR system unless specifically requested to do so, so yes. :-)
If so, how can I get Tumbleweed to use it as well? As I also wrote in my followup to Carlos E.R., I was unable to do this during the Tumbleweed installation. Should it be possible and if so, how?
A possibly relevant datapoint: When I compare the /boot directories in my Leap and Tumbleweed installations, in addition to /boot in Tumbleweed lacking the efi subdirectory, I see that, while in both installations the grub2 subdirectory contains the subdirectory x86_64-efi, in Leap it is filled with 267 *.mod files, while in Tumbleweed it is empty (both installations also contain the directory i386-pc under grub2; in Leap it contains 277 *.mod files, in Tumbleweed 278). Is this another indication that the bootloader (in Leap) is using UEFI?
Absolutely!
Check if you have /etc/default/grub on your TW. If it's there, then change
GRUB_DISTRIBUTOR="opensuse"
to
GRUB_DISTRIBUTOR="opensusetw"
or whatever suits your fancy to make them distinguishable where there would otherwise be conflict. I filed a bug last summer requesting this ability be included at installation time: https://bugzilla.opensuse.org/show_bug.cgi?id=1101756
Here on both Leap and TW it's unset, which according to the preceding comment in the file means "determine the value from /etc/os-release"; the latter files assign values to NAME, VERSION, ID, PRETTY_NAME, CPE_NAME and ID_LIKE that are distinct in both systems. Do you nevertheless recommend setting GRUB_DISTRIBUTOR?
When several grubs are installed, it is convenient to use different names for each, yes.
This should enable installing Grub EFI from TW to takeover from Leap by the simple YaST2 EFI Grub installation process, which would I expect (not enough practice with fresh installations to be sure) change the values resulting from the command:
efibootmgr
Are you saying to select, in the Boot Code Options tab of the YaST2 Boot Loader module, "GRUB2 for EFI" from the dropdown list under Boot Loader? And do this in the installed TW or during the (re)installation? And should I then check "Enable Secure Boot Support"? (I think secure boot is disabled in my BIOS ) And what should I set "Protective MBR flag" to: "set", "remove", or "do not change"?
Also, if I select "GRUB2 for EFI" will the bootloader be installed in the existing /boot partition, overwriting what is there now from Leap?
Don't do that. Each distribution must have their own separate /boot partition or directory. It is possible to put them into a single /boot partition, but I don't see the reason and I have never done it. A lot of work and dangerous hassle. Not worth it. It is very weird nowdays to have a separate /boot partition. There many be reasons, like when using LVM or some raid modes or perhaps encryption. But you have not mentioned any of that. Also, don't confuse the EFI partition with the /boot partition or the BIOS BOOT partition. Each one is different. And nowdays, /boot is usually a directory of "/". In fact, if you partition "/" as btrfs, you must not use a separate boot partition, or reverting to a previous snapshot will not be able to boot the previous kernel. The EFI partition is formatted as vfat, and is mounted inside /boot. There is only one per disk. It is however very strange to have Leap using bios mode and TW using EFI mode. When you do not know how to create the bios partition, just look at the initial proposal, and replicate the choices for that partition on a different spot. It doesn't use any filesystem, it is raw. And it is tiny, 8..16 mega bytes. If I remember correctly, there is some point at the partitioner where you can choose which partitions to overwrite and which to leave intact, and then ask the installer to make a new proposal. If what you said is correct, that the computer came with "/boot, / (root) and swap", then for sure it was booting in BIOS mode, even if the disk is GPT. I see on bootinfo that you have "Syslinux GPTMBR (4.04-5.01) is installed in the MBR of /dev/nvme0n1"n which confirms it. In this setting, when installing another system, choose to leave the existing protective MBR intact.
Note that when I open the Boot Loader module in Leap, it shows GRUB2 as the boot loader, and "Boot from Partition", "Set active Flag in Partition Table for Boot Partition" and "Write generic Boot Code to MBR" are checked and "Protective MBR flag" is set to "do not change". Is this display expected even if the bootloader is using EFI?
It is not using EFI, IMO. The settings are what I would do on a BIOS machine. Your current setup is, I think, that Leap os-prober found the TW partition and added entries for it in its own grub. You have currently no way to boot by default the second grub - in bios mode. If you switch the computer to EFI mode, it is possible that Leap will not boot, and the the TW boot was incomplete and might not boot. The latter is just a feeling. You should check your bios, what mode it is in. -- Cheers / Saludos, Carlos E. R. (from openSUSE, Leap 15.1 x86_64 (ssd-test)) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, 12 May 2019 20:15:33 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 12/05/2019 16.29, Stephen Berman wrote:
On Sun, 12 May 2019 01:55:06 -0400 Felix Miata <mrmazda@earthlink.net> wrote:
Stephen Berman composed on 2019-05-12 00:53 (UTC+0200):
As I wrote, I also have /boot/efi mounted in Leap 15.0. Does that mean Leap is using UEFI to boot?
I'm pretty sure no astute Linux reseller is going to configure a new system to use the legacy MBR system unless specifically requested to do so, so yes. :-)
If so, how can I get Tumbleweed to use it as well? As I also wrote in my followup to Carlos E.R., I was unable to do this during the Tumbleweed installation. Should it be possible and if so, how?
A possibly relevant datapoint: When I compare the /boot directories in my Leap and Tumbleweed installations, in addition to /boot in Tumbleweed lacking the efi subdirectory, I see that, while in both installations the grub2 subdirectory contains the subdirectory x86_64-efi, in Leap it is filled with 267 *.mod files, while in Tumbleweed it is empty (both installations also contain the directory i386-pc under grub2; in Leap it contains 277 *.mod files, in Tumbleweed 278). Is this another indication that the bootloader (in Leap) is using UEFI?
Absolutely!
Check if you have /etc/default/grub on your TW. If it's there, then change
GRUB_DISTRIBUTOR="opensuse"
to
GRUB_DISTRIBUTOR="opensusetw"
or whatever suits your fancy to make them distinguishable where there would otherwise be conflict. I filed a bug last summer requesting this ability be included at installation time: https://bugzilla.opensuse.org/show_bug.cgi?id=1101756
Here on both Leap and TW it's unset, which according to the preceding comment in the file means "determine the value from /etc/os-release"; the latter files assign values to NAME, VERSION, ID, PRETTY_NAME, CPE_NAME and ID_LIKE that are distinct in both systems. Do you nevertheless recommend setting GRUB_DISTRIBUTOR?
When several grubs are installed, it is convenient to use different names for each, yes.
I can't tell from your answer whether this means I should set GRUB_DISTRIBUTOR differently in Leap and TW or let it be set by /etc/os-release, since most of the entries there differ between Leap and TW. But installing "several grubs" into /boot (wherever it is), seems to run counter to what you say below: "Each distribution must have their own separate /boot partition or directory." Please clarify.
This should enable installing Grub EFI from TW to takeover from Leap by the simple YaST2 EFI Grub installation process, which would I expect (not enough practice with fresh installations to be sure) change the values resulting from the command:
efibootmgr
Are you saying to select, in the Boot Code Options tab of the YaST2 Boot Loader module, "GRUB2 for EFI" from the dropdown list under Boot Loader? And do this in the installed TW or during the (re)installation? And should I then check "Enable Secure Boot Support"? (I think secure boot is disabled in my BIOS ) And what should I set "Protective MBR flag" to: "set", "remove", or "do not change"?
Also, if I select "GRUB2 for EFI" will the bootloader be installed in the existing /boot partition, overwriting what is there now from Leap?
Don't do that. Each distribution must have their own separate /boot partition or directory.
It is possible to put them into a single /boot partition, but I don't see the reason and I have never done it. A lot of work and dangerous hassle. Not worth it.
It is very weird nowdays to have a separate /boot partition. There many be reasons, like when using LVM or some raid modes or perhaps encryption. But you have not mentioned any of that.
I've never used a separate /boot partition till now, and if the machine hadn't come that way, I probably wouldn't have made one myself. (I did tell them when I ordered the machine that I intended to install TW and other Linux-based systems beside Leap but didn't ask for a specific partition scheme; that was probably a mistake. I suppose I could just delete the entire disk and start from scratch. Maybe that's the best way to go...)
Also, don't confuse the EFI partition with the /boot partition or the BIOS BOOT partition. Each one is different. And nowdays, /boot is usually a directory of "/". In fact, if you partition "/" as btrfs, you must not use a separate boot partition, or reverting to a previous snapshot will not be able to boot the previous kernel.
Are you sure? If so, why does openSUSE propose a separate /boot partition but also btrfs for the root partition?
The EFI partition is formatted as vfat, and is mounted inside /boot. There is only one per disk. It is however very strange to have Leap using bios mode and TW using EFI mode.
By strange do you mean unusual but not otherwise dangerous or do you mean it increases the risk of not being able to boot?
When you do not know how to create the bios partition, just look at the initial proposal, and replicate the choices for that partition on a different spot. It doesn't use any filesystem, it is raw. And it is tiny, 8..16 mega bytes.
That's what I first did, as I wrote in my OP, but to everything I tried the installer said there was no bootable partition. If there is some way during installation to create a bios partition without accepting the intaller's proposal, it remained hidden to me.
If I remember correctly, there is some point at the partitioner where you can choose which partitions to overwrite and which to leave intact, and then ask the installer to make a new proposal.
Yes, I think I tried that but the installer said something like the partition scheme I wanted was unsupported.
If what you said is correct, that the computer came with "/boot, / (root) and swap", then for sure it was booting in BIOS mode, even if the disk is GPT. I see on bootinfo that you have "Syslinux GPTMBR (4.04-5.01) is installed in the MBR of /dev/nvme0n1"n which confirms it.
In this setting, when installing another system, choose to leave the existing protective MBR intact.
It's hard for me to decide how to proceed when knowledgeable people (e.g. you and Felix Miata) firmly offer conflicting advice...
Note that when I open the Boot Loader module in Leap, it shows GRUB2 as the boot loader, and "Boot from Partition", "Set active Flag in Partition Table for Boot Partition" and "Write generic Boot Code to MBR" are checked and "Protective MBR flag" is set to "do not change". Is this display expected even if the bootloader is using EFI?
It is not using EFI, IMO. The settings are what I would do on a BIOS machine.
Your current setup is, I think, that Leap os-prober found the TW partition and added entries for it in its own grub. You have currently no way to boot by default the second grub - in bios mode. If you switch the computer to EFI mode, it is possible that Leap will not boot, and the the TW boot was incomplete and might not boot. The latter is just a feeling.
You should check your bios, what mode it is in.
The BIOS has UEFI CSM support enabled "to support a legacy PC boot process." And since that is enabled, that permits configuring "whether to enable the UEFI or legacy option ROM for the storage device controller" and also "for the PCI device controller other than the LAN, storage device, and graphics controllers"; both are set to enable "UEFI option ROM only." Steve Berman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Stephen Berman composed on 2019-05-12 22:33 (UTC+0200):
When several grubs are installed, it is convenient to use different names for each, yes.
I can't tell from your answer whether this means I should set GRUB_DISTRIBUTOR differently in Leap and TW or let it be set by /etc/os-release, since most of the entries there differ between Leap and TW. But installing "several grubs" into /boot (wherever it is), seems to run counter to what you say below: "Each distribution must have their own separate /boot partition or directory." Please clarify.
If you don't use GRUB_DISTRIBUTOR= to override /etc/os-release, every openSUSE installation will use the one and only /boot/efi/EFI/opensuse. Worse, every Ubuntu and every distro based upon Ubuntu (e.g. Linuxmint) uses /boot/efi/EFI/ubuntu. This usurpation is why GRUB_DISTRIBUTOR was created by the Grub developers. And, as the previously linked Bugzilla report explains, you can't even do this until after your openSUSE installation is done and you've rebooted into your new installation. You are guaranteed to have this overwriting occur if you haven't changed the existing installation(s)' GRUB_DISTRIBUTOR to something unique. It's not a big problem, but it's certainly a nuisance to have nearly every kernel installation change the choice of which grub.cfg to present after POST completes. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, 12 May 2019 17:06:26 -0400 Felix Miata <mrmazda@earthlink.net> wrote:
Stephen Berman composed on 2019-05-12 22:33 (UTC+0200):
When several grubs are installed, it is convenient to use different names for each, yes.
I can't tell from your answer whether this means I should set GRUB_DISTRIBUTOR differently in Leap and TW or let it be set by /etc/os-release, since most of the entries there differ between Leap and TW. But installing "several grubs" into /boot (wherever it is), seems to run counter to what you say below: "Each distribution must have their own separate /boot partition or directory." Please clarify.
If you don't use GRUB_DISTRIBUTOR= to override /etc/os-release, every openSUSE installation will use the one and only /boot/efi/EFI/opensuse. Worse, every Ubuntu and every distro based upon Ubuntu (e.g. Linuxmint) uses /boot/efi/EFI/ubuntu. This usurpation is why GRUB_DISTRIBUTOR was created by the Grub developers.
And, as the previously linked Bugzilla report explains, you can't even do this until after your openSUSE installation is done and you've rebooted into your new installation. You are guaranteed to have this overwriting occur if you haven't changed the existing installation(s)' GRUB_DISTRIBUTOR to something unique. It's not a big problem, but it's certainly a nuisance to have nearly every kernel installation change the choice of which grub.cfg to present after POST completes.
Thanks for the clarification. Steve Berman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/05/2019 22.33, Stephen Berman wrote:
On Sun, 12 May 2019 20:15:33 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 12/05/2019 16.29, Stephen Berman wrote:
On Sun, 12 May 2019 01:55:06 -0400 Felix Miata <mrmazda@earthlink.net> wrote:
Stephen Berman composed on 2019-05-12 00:53 (UTC+0200):
As I wrote, I also have /boot/efi mounted in Leap 15.0. Does that mean Leap is using UEFI to boot?
I'm pretty sure no astute Linux reseller is going to configure a new system to use the legacy MBR system unless specifically requested to do so, so yes. :-)
If so, how can I get Tumbleweed to use it as well? As I also wrote in my followup to Carlos E.R., I was unable to do this during the Tumbleweed installation. Should it be possible and if so, how?
A possibly relevant datapoint: When I compare the /boot directories in my Leap and Tumbleweed installations, in addition to /boot in Tumbleweed lacking the efi subdirectory, I see that, while in both installations the grub2 subdirectory contains the subdirectory x86_64-efi, in Leap it is filled with 267 *.mod files, while in Tumbleweed it is empty (both installations also contain the directory i386-pc under grub2; in Leap it contains 277 *.mod files, in Tumbleweed 278). Is this another indication that the bootloader (in Leap) is using UEFI?
Absolutely!
Check if you have /etc/default/grub on your TW. If it's there, then change
GRUB_DISTRIBUTOR="opensuse"
to
GRUB_DISTRIBUTOR="opensusetw"
or whatever suits your fancy to make them distinguishable where there would otherwise be conflict. I filed a bug last summer requesting this ability be included at installation time: https://bugzilla.opensuse.org/show_bug.cgi?id=1101756
Here on both Leap and TW it's unset, which according to the preceding comment in the file means "determine the value from /etc/os-release"; the latter files assign values to NAME, VERSION, ID, PRETTY_NAME, CPE_NAME and ID_LIKE that are distinct in both systems. Do you nevertheless recommend setting GRUB_DISTRIBUTOR?
When several grubs are installed, it is convenient to use different names for each, yes.
I can't tell from your answer whether this means I should set GRUB_DISTRIBUTOR differently in Leap and TW or let it be set by /etc/os-release, since most of the entries there differ between Leap and TW. But installing "several grubs" into /boot (wherever it is), seems to run counter to what you say below: "Each distribution must have their own separate /boot partition or directory." Please clarify.
Each "linux install" should have its own /boot directory (which some times is also a different partition), and in there just one grub. And each one should use a different name (distributor) so that when you boot one you know which one it is. ...
It is very weird nowdays to have a separate /boot partition. There many be reasons, like when using LVM or some raid modes or perhaps encryption. But you have not mentioned any of that.
I've never used a separate /boot partition till now, and if the machine hadn't come that way, I probably wouldn't have made one myself. (I did tell them when I ordered the machine that I intended to install TW and other Linux-based systems beside Leap but didn't ask for a specific partition scheme; that was probably a mistake. I suppose I could just delete the entire disk and start from scratch. Maybe that's the best way to go...)
Possibly... but I would make a backup of what the shop installed, just in case.
Also, don't confuse the EFI partition with the /boot partition or the BIOS BOOT partition. Each one is different. And nowdays, /boot is usually a directory of "/". In fact, if you partition "/" as btrfs, you must not use a separate boot partition, or reverting to a previous snapshot will not be able to boot the previous kernel.
Are you sure? If so, why does openSUSE propose a separate /boot partition but also btrfs for the root partition?
Absolutely sure. And you must be confused: the installer did not propose a separate /boot partition. It wanted a bios partition and an efi partition. (the proper filesystem for /boot, if it exists, is ext2).
The EFI partition is formatted as vfat, and is mounted inside /boot. There is only one per disk. It is however very strange to have Leap using bios mode and TW using EFI mode.
By strange do you mean unusual but not otherwise dangerous or do you mean it increases the risk of not being able to boot?
It should not happen. Not dangerous, but possibly unbootable.
When you do not know how to create the bios partition, just look at the initial proposal, and replicate the choices for that partition on a different spot. It doesn't use any filesystem, it is raw. And it is tiny, 8..16 mega bytes.
That's what I first did, as I wrote in my OP, but to everything I tried the installer said there was no bootable partition. If there is some way during installation to create a bios partition without accepting the intaller's proposal, it remained hidden to me.
Then it was referring to something else I don't see. I don't see the BIOS partition in your layout. Anyway, IIRC that partition is only used when Grub is installed in the MBR in BIOS mode, which is not your case. However, the installer will not be happy till you make it "just in case" you change your mind one day and want to put grub in the mbr. It is a real tiny partition, so it doesn't matter to have it. It looks like this in fdisk: lesar:~ # fdisk -l /dev/sdc Disk /dev/sdc: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors Disk model: ST4000DM004-2CV1 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 1C7EE0A7... Device Start End Sectors Size Type /dev/sdc1 2048 32767 30720 15M BIOS boot <====== /dev/sdc2 32768 1261567 1228800 600M Linux filesystem ...
If I remember correctly, there is some point at the partitioner where you can choose which partitions to overwrite and which to leave intact, and then ask the installer to make a new proposal.
Yes, I think I tried that but the installer said something like the partition scheme I wanted was unsupported.
It certainly failed to boot...
If what you said is correct, that the computer came with "/boot, / (root) and swap", then for sure it was booting in BIOS mode, even if the disk is GPT. I see on bootinfo that you have "Syslinux GPTMBR (4.04-5.01) is installed in the MBR of /dev/nvme0n1"n which confirms it.
In this setting, when installing another system, choose to leave the existing protective MBR intact.
It's hard for me to decide how to proceed when knowledgeable people (e.g. you and Felix Miata) firmly offer conflicting advice...
Felix uses a complicated setup with many linuxes installed :-) Basically, you decide ONE Linux to be the ruler. This one writes the MBR, the rest should leave it intact. Then, in BIOS mode you can change which one has the "legacy boot flag" active, and that's the one that will boot by default. EFI is different.
Note that when I open the Boot Loader module in Leap, it shows GRUB2 as the boot loader, and "Boot from Partition", "Set active Flag in Partition Table for Boot Partition" and "Write generic Boot Code to MBR" are checked and "Protective MBR flag" is set to "do not change". Is this display expected even if the bootloader is using EFI?
It is not using EFI, IMO. The settings are what I would do on a BIOS machine.
Your current setup is, I think, that Leap os-prober found the TW partition and added entries for it in its own grub. You have currently no way to boot by default the second grub - in bios mode. If you switch the computer to EFI mode, it is possible that Leap will not boot, and the the TW boot was incomplete and might not boot. The latter is just a feeling.
You should check your bios, what mode it is in.
The BIOS has UEFI CSM support enabled "to support a legacy PC boot process."
So, you are in BIOS mode, I think. :-?? Either that or the computer sees there is no proper EFI boot system and defaults to Legacy. Maybe it is some sort of dual mode, TW detected EFI and tried to install in EFI mode... :-? (confused)
And since that is enabled, that permits configuring "whether to enable the UEFI or legacy option ROM for the storage device controller" and also "for the PCI device controller other than the LAN, storage device, and graphics controllers"; both are set to enable "UEFI option ROM only."
If you are going to install again, disable legacy and go for pure EFI, and wipe the disk. Just install then Leap but not using the entire disk to leave space for TW. And if you don't have another computer, make sure to have the XFCE aka Rescue image installed in an USB stick (4GB suffices) and boot it at least once to know it works. Even if you have another computer :-) -- Cheers / Saludos, Carlos E. R. (from openSUSE, Leap 15.1 x86_64 (ssd-test)) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. composed on 2019-05-12 23:15 (UTC+0200):
Stephen Berman wrote:
I can't tell from your answer whether this means I should set GRUB_DISTRIBUTOR differently in Leap and TW or let it be set by /etc/os-release, since most of the entries there differ between Leap and TW. But installing "several grubs" into /boot (wherever it is), seems to run counter to what you say below: "Each distribution must have their own separate /boot partition or directory." Please clarify.
Each "linux install" should have its own /boot directory (which some times is also a different partition), and in there just one grub. And each one should use a different name (distributor) so that when you boot one you know which one it is.
While this is good advice, it may be unclear to the reader: 1-/boot/ on a UEFI installation is impure, containing /boot/efi/, on which is normally mounted the FAT ESP partition. 2-(most or all of) the names of the directories in /boot/efi/EFI/ may be selected by the admin by employing GRUB_DISTRIBUTOR=. When the admin does not do so, each is normally a result of either what each /etc/os-release contains, or what the distro provides for GRUB_DISTRIBUTOR=. While in openSUSE by default GRUB_DISTRIBUTOR is null, in others it is not, e.g. Debian 10, Linuxmint 19.1, and Ubuntu 18.04 all use exactly this: GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
It's hard for me to decide how to proceed when knowledgeable people (e.g. you and Felix Miata) firmly offer conflicting advice...
Felix uses a complicated setup with many linuxes installed :-)
It's roots are here: <https://old-en.opensuse.org/Bugs/grub#How_does_a_PC_boot_.2F_How_can_I_set_up_a_working_GRUB.3F> 'We recommend to keep the MBR "neutral"...'
Basically, you decide ONE Linux to be the ruler.
Incorrect. I am the ruler. I put Grub there, not any operating system's installation program or disk maintenance tool. Everything in it I put there, primarily using Midnight Commander. (Initial writes to an empty disk are usually made either by attaching the disk to another system, or by booting the target system to a Knoppix CD, DVD or USB stick. After partitioning and formatting, the master boot partition is finished by copying the content of CONTENT.cpio/usr/lib/grub/ from a 13.1 Grub Legacy rpm using MC, constructing device.map and menu.lst from scratch or LAN template, also in MC, and setting up the boot code blocks via the Grub shell.)
This one writes the MBR,
Incorrect. No OS or OS installer writes to my MBR disks' 440 byte MBR code blocks. What they write to my UEFI/GPT disks' MBR code blocks I'm not sure, but I think they don't touch it. The MBR disk MBR code blocks here all contain either DOS/OS2/Windows/generic code, or nulls. Most contain code originally written for IBM Boot Manager for OS/2 in a more recent iteration provided through eComStation to the non-FOSS partitioner that does all the partition table writing here, DFSee.
the rest should leave it intact.
Then, in BIOS mode you can change which one has the "legacy boot flag" active, and that's the one that will boot by default.
Correct (usually sda3, but often sda1, rarely sda2, all of which exist, and none of which are type extended).
EFI is different.
Correct again! :-D Again, it is me in control, but quite differently. So far, each UEFI-configured system on a normal boot displays a Grub menu from TW named /boot/grub2/custom.cfg, also created and maintained using Midnight Commander. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, 12 May 2019 23:15:33 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 12/05/2019 22.33, Stephen Berman wrote:
On Sun, 12 May 2019 20:15:33 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 12/05/2019 16.29, Stephen Berman wrote:
On Sun, 12 May 2019 01:55:06 -0400 Felix Miata <mrmazda@earthlink.net> wrote:
Stephen Berman composed on 2019-05-12 00:53 (UTC+0200):
As I wrote, I also have /boot/efi mounted in Leap 15.0. Does that mean Leap is using UEFI to boot?
I'm pretty sure no astute Linux reseller is going to configure a new system to use the legacy MBR system unless specifically requested to do so, so yes. :-)
If so, how can I get Tumbleweed to use it as well? As I also wrote in my followup to Carlos E.R., I was unable to do this during the Tumbleweed installation. Should it be possible and if so, how?
A possibly relevant datapoint: When I compare the /boot directories in my Leap and Tumbleweed installations, in addition to /boot in Tumbleweed lacking the efi subdirectory, I see that, while in both installations the grub2 subdirectory contains the subdirectory x86_64-efi, in Leap it is filled with 267 *.mod files, while in Tumbleweed it is empty (both installations also contain the directory i386-pc under grub2; in Leap it contains 277 *.mod files, in Tumbleweed 278). Is this another indication that the bootloader (in Leap) is using UEFI?
Absolutely!
Check if you have /etc/default/grub on your TW. If it's there, then change
GRUB_DISTRIBUTOR="opensuse"
to
GRUB_DISTRIBUTOR="opensusetw"
or whatever suits your fancy to make them distinguishable where there would otherwise be conflict. I filed a bug last summer requesting this ability be included at installation time: https://bugzilla.opensuse.org/show_bug.cgi?id=1101756
Here on both Leap and TW it's unset, which according to the preceding comment in the file means "determine the value from /etc/os-release"; the latter files assign values to NAME, VERSION, ID, PRETTY_NAME, CPE_NAME and ID_LIKE that are distinct in both systems. Do you nevertheless recommend setting GRUB_DISTRIBUTOR?
When several grubs are installed, it is convenient to use different names for each, yes.
I can't tell from your answer whether this means I should set GRUB_DISTRIBUTOR differently in Leap and TW or let it be set by /etc/os-release, since most of the entries there differ between Leap and TW. But installing "several grubs" into /boot (wherever it is), seems to run counter to what you say below: "Each distribution must have their own separate /boot partition or directory." Please clarify.
Each "linux install" should have its own /boot directory (which some times is also a different partition), and in there just one grub. And each one should use a different name (distributor) so that when you boot one you know which one it is.
Ok.
It is very weird nowdays to have a separate /boot partition. There many be reasons, like when using LVM or some raid modes or perhaps encryption. But you have not mentioned any of that.
I've never used a separate /boot partition till now, and if the machine hadn't come that way, I probably wouldn't have made one myself. (I did tell them when I ordered the machine that I intended to install TW and other Linux-based systems beside Leap but didn't ask for a specific partition scheme; that was probably a mistake. I suppose I could just delete the entire disk and start from scratch. Maybe that's the best way to go...)
Possibly... but I would make a backup of what the shop installed, just in case.
I already did that before repartitioning the Leap root partition and installing TW.
Also, don't confuse the EFI partition with the /boot partition or the BIOS BOOT partition. Each one is different. And nowdays, /boot is usually a directory of "/". In fact, if you partition "/" as btrfs, you must not use a separate boot partition, or reverting to a previous snapshot will not be able to boot the previous kernel.
Are you sure? If so, why does openSUSE propose a separate /boot partition but also btrfs for the root partition?
Absolutely sure. And you must be confused: the installer did not propose a separate /boot partition. It wanted a bios partition and an efi partition.
I didn't write down or photograph what was on the screen during the installation, but I have a very clear memory that it proposed a separate /boot partition, and have no memory of an efi partition. I think it referred to there being no BIOS partition when I tried to use the existing /boot partition, and also when I tried to make an new /boot partition. If and when I reinstall, I will capture what's on the screen.
(the proper filesystem for /boot, if it exists, is ext2).
I seem to recall that advice from older installations; is it still considered valid?
The EFI partition is formatted as vfat, and is mounted inside /boot. There is only one per disk. It is however very strange to have Leap using bios mode and TW using EFI mode.
By strange do you mean unusual but not otherwise dangerous or do you mean it increases the risk of not being able to boot?
It should not happen. Not dangerous, but possibly unbootable.
Ok.
When you do not know how to create the bios partition, just look at the initial proposal, and replicate the choices for that partition on a different spot. It doesn't use any filesystem, it is raw. And it is tiny, 8..16 mega bytes.
That's what I first did, as I wrote in my OP, but to everything I tried the installer said there was no bootable partition. If there is some way during installation to create a bios partition without accepting the intaller's proposal, it remained hidden to me.
Then it was referring to something else I don't see.
I don't see the BIOS partition in your layout. Anyway, IIRC that partition is only used when Grub is installed in the MBR in BIOS mode, which is not your case. However, the installer will not be happy till you make it "just in case" you change your mind one day and want to put grub in the mbr. It is a real tiny partition, so it doesn't matter to have it.
It looks like this in fdisk:
lesar:~ # fdisk -l /dev/sdc Disk /dev/sdc: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors Disk model: ST4000DM004-2CV1 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 1C7EE0A7...
Device Start End Sectors Size Type /dev/sdc1 2048 32767 30720 15M BIOS boot <====== /dev/sdc2 32768 1261567 1228800 600M Linux filesystem
I was confused by the installer's and your references to the BIOS boot partition, and now I understand why: "The BIOS boot partition is a partition on a data storage device that GNU GRUB uses on legacy BIOS-based personal computers in order to boot an operating system, when the actual boot device contains a GUID Partition Table (GPT)." (https://en.wikipedia.org/wiki/BIOS_boot_partition) Prior to this new computer I'd never installed on a machine with a GPT.
If I remember correctly, there is some point at the partitioner where you can choose which partitions to overwrite and which to leave intact, and then ask the installer to make a new proposal.
Yes, I think I tried that but the installer said something like the partition scheme I wanted was unsupported.
It certainly failed to boot...
That's misleading; I installed no bootloader in TW, but there's no problem booting TW from the GRUB2 installed in Leap.
If what you said is correct, that the computer came with "/boot, / (root) and swap", then for sure it was booting in BIOS mode, even if the disk is GPT. I see on bootinfo that you have "Syslinux GPTMBR (4.04-5.01) is installed in the MBR of /dev/nvme0n1"n which confirms it.
In this setting, when installing another system, choose to leave the existing protective MBR intact.
It's hard for me to decide how to proceed when knowledgeable people (e.g. you and Felix Miata) firmly offer conflicting advice...
Felix uses a complicated setup with many linuxes installed :-)
Basically, you decide ONE Linux to be the ruler. This one writes the MBR, the rest should leave it intact.
Then, in BIOS mode you can change which one has the "legacy boot flag" active, and that's the one that will boot by default.
EFI is different.
Note that when I open the Boot Loader module in Leap, it shows GRUB2 as the boot loader, and "Boot from Partition", "Set active Flag in Partition Table for Boot Partition" and "Write generic Boot Code to MBR" are checked and "Protective MBR flag" is set to "do not change". Is this display expected even if the bootloader is using EFI?
It is not using EFI, IMO. The settings are what I would do on a BIOS machine.
Your current setup is, I think, that Leap os-prober found the TW partition and added entries for it in its own grub. You have currently no way to boot by default the second grub - in bios mode. If you switch the computer to EFI mode, it is possible that Leap will not boot, and the the TW boot was incomplete and might not boot. The latter is just a feeling.
You should check your bios, what mode it is in.
The BIOS has UEFI CSM support enabled "to support a legacy PC boot process."
So, you are in BIOS mode, I think. :-??
Either that or the computer sees there is no proper EFI boot system and defaults to Legacy.
Maybe it is some sort of dual mode, TW detected EFI and tried to install in EFI mode... :-?
(confused)
You're not the only one who's confused. You're previous reply had almost convinced me that the system was booting in legacy mode (despite what Felix said), and that BIOS setting seems to confirm that. But then I found this (http://www.rodsbooks.com/linux-uefi/): "You should verify an EFI-mode boot by dropping to a Linux shell and typing ls /sys/firmware/efi. If you see a list of files and directories, you've booted in EFI mode [...]". And indeed, this is in the running Leap: steve@linux-tuxedo:~> ls -l /sys/firmware/efi/ total 0 -r--r--r-- 1 root root 4096 May 12 23:44 config_table drwxr-xr-x 2 root root 0 May 12 15:12 efivars drwxr-xr-x 3 root root 0 May 12 23:44 esrt -r--r--r-- 1 root root 4096 May 12 23:44 fw_platform_size -r--r--r-- 1 root root 4096 May 12 23:44 fw_vendor -r--r--r-- 1 root root 4096 May 12 23:44 runtime drwxr-xr-x 13 root root 0 May 12 23:44 runtime-map drwxr-xr-x 2 root root 0 May 12 23:44 secret-key -r-------- 1 root root 4096 May 12 23:44 systab drwxr-xr-x 96 root root 0 May 12 23:44 vars
And since that is enabled, that permits configuring "whether to enable the UEFI or legacy option ROM for the storage device controller" and also "for the PCI device controller other than the LAN, storage device, and graphics controllers"; both are set to enable "UEFI option ROM only."
If you are going to install again, disable legacy and go for pure EFI, and wipe the disk. Just install then Leap but not using the entire disk to leave space for TW.
With everything I've understood you to have said before, this advice surprises me. Why pure EFI? Legacy seems much simpler, and it's worked fine for me till now for booting multiple systems installed on the same machine. Or is it really inadvisable to keep CSM support enable in the BIOS, installing Leap and TW using EFI but leaving the option of legacy booting for other systems that may not support EFI the was openSUSE does?
And if you don't have another computer, make sure to have the XFCE aka Rescue image installed in an USB stick (4GB suffices) and boot it at least once to know it works. Even if you have another computer :-)
I'm using the SSD for system installation only; all my data are on other disks and I have installation media on USB and DVDs. Steve Berman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Stephen Berman composed on 2019-05-13 01:14 (UTC+0200):
On Sun, 12 May 2019 23:15:33 +0200 "Carlos E. R." wrote:
(the proper filesystem for /boot, if it exists, is ext2).
I seem to recall that advice from older installations; is it still considered valid?
"A" proper filesystem, not "the" proper filesystem. It's still the only type I use. I consider a journal a waste of space on a small filesystem on which writes are infrequent, but I have other reasons as well.
If you are going to install again, disable legacy and go for pure EFI, and wipe the disk. Just install then Leap but not using the entire disk to leave space for TW.
With everything I've understood you to have said before, this advice surprises me. Why pure EFI? Legacy seems much simpler, and it's worked fine for me till now for booting multiple systems installed on the same machine. IMO, neither is much simpler than the other. The big difference is how complicated Grub got being scattered about more than 6 filesystem locations, non-filesystem locations, with GPT partitioning and UEFI, in addition to keeping BIOS/MBR. The perceived difference I believe to be more likely due to familiarity with MBR and unfamiliarity with GPT.
Or is it really inadvisable to keep CSM support enable in the BIOS, installing Leap and TW using EFI but leaving the option of legacy booting for other systems that may not support EFI the was openSUSE does? I would expect MBR/BIOS support to remain constant or regress over the life of your new Tuxedo PC, while UEFI grows and improves. -- Evolution as taught in public schools is religion, not science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, 12 May 2019 19:46:31 -0400 Felix Miata <mrmazda@earthlink.net> wrote:
Stephen Berman composed on 2019-05-13 01:14 (UTC+0200):
On Sun, 12 May 2019 23:15:33 +0200 "Carlos E. R." wrote:
(the proper filesystem for /boot, if it exists, is ext2).
I seem to recall that advice from older installations; is it still considered valid?
"A" proper filesystem, not "the" proper filesystem. It's still the only type I use. I consider a journal a waste of space on a small filesystem on which writes are infrequent, but I have other reasons as well.
Ok.
If you are going to install again, disable legacy and go for pure EFI, and wipe the disk. Just install then Leap but not using the entire disk to leave space for TW.
With everything I've understood you to have said before, this advice surprises me. Why pure EFI? Legacy seems much simpler, and it's worked fine for me till now for booting multiple systems installed on the same machine. IMO, neither is much simpler than the other. The big difference is how complicated Grub got being scattered about more than 6 filesystem locations, non-filesystem locations, with GPT partitioning and UEFI, in addition to keeping BIOS/MBR. The perceived difference I believe to be more likely due to familiarity with MBR and unfamiliarity with GPT.
That's certainly the case with me.
Or is it really inadvisable to keep CSM support enable in the BIOS, installing Leap and TW using EFI but leaving the option of legacy booting for other systems that may not support EFI the was openSUSE does? I would expect MBR/BIOS support to remain constant or regress over the life of your new Tuxedo PC, while UEFI grows and improves.
Yeah, that's probably the best reason to switch. Steve Berman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 13/05/2019 01.14, Stephen Berman wrote:
On Sun, 12 May 2019 23:15:33 +0200 "Carlos E. R." <> wrote:
...
Possibly... but I would make a backup of what the shop installed, just in case.
I already did that before repartitioning the Leap root partition and installing TW.
Good :-)
Also, don't confuse the EFI partition with the /boot partition or the BIOS BOOT partition. Each one is different. And nowdays, /boot is usually a directory of "/". In fact, if you partition "/" as btrfs, you must not use a separate boot partition, or reverting to a previous snapshot will not be able to boot the previous kernel.
Are you sure? If so, why does openSUSE propose a separate /boot partition but also btrfs for the root partition?
Absolutely sure. And you must be confused: the installer did not propose a separate /boot partition. It wanted a bios partition and an efi partition.
I didn't write down or photograph what was on the screen during the installation, but I have a very clear memory that it proposed a separate /boot partition, and have no memory of an efi partition. I think it referred to there being no BIOS partition when I tried to use the existing /boot partition, and also when I tried to make an new /boot partition. If and when I reinstall, I will capture what's on the screen.
(the proper filesystem for /boot, if it exists, is ext2).
I seem to recall that advice from older installations; is it still considered valid?
Sure. Reasoning is that on such a small partition (250 MB?) it is a waste to use space on a journal; and anyway, being small fsck goes fast if needed, even without a journal. But if you do want a journal, go for ext4. I do not understand why the install would want a separate /boot.
The EFI partition is formatted as vfat, and is mounted inside /boot. There is only one per disk. It is however very strange to have Leap using bios mode and TW using EFI mode.
By strange do you mean unusual but not otherwise dangerous or do you mean it increases the risk of not being able to boot?
It should not happen. Not dangerous, but possibly unbootable.
Ok.
When you do not know how to create the bios partition, just look at the initial proposal, and replicate the choices for that partition on a different spot. It doesn't use any filesystem, it is raw. And it is tiny, 8..16 mega bytes.
That's what I first did, as I wrote in my OP, but to everything I tried the installer said there was no bootable partition. If there is some way during installation to create a bios partition without accepting the intaller's proposal, it remained hidden to me.
Then it was referring to something else I don't see.
I don't see the BIOS partition in your layout. Anyway, IIRC that partition is only used when Grub is installed in the MBR in BIOS mode, which is not your case. However, the installer will not be happy till you make it "just in case" you change your mind one day and want to put grub in the mbr. It is a real tiny partition, so it doesn't matter to have it.
It looks like this in fdisk:
lesar:~ # fdisk -l /dev/sdc Disk /dev/sdc: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors Disk model: ST4000DM004-2CV1 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 1C7EE0A7...
Device Start End Sectors Size Type /dev/sdc1 2048 32767 30720 15M BIOS boot <====== /dev/sdc2 32768 1261567 1228800 600M Linux filesystem
I was confused by the installer's and your references to the BIOS boot partition, and now I understand why:
"The BIOS boot partition is a partition on a data storage device that GNU GRUB uses on legacy BIOS-based personal computers in order to boot an operating system, when the actual boot device contains a GUID Partition Table (GPT)." (https://en.wikipedia.org/wiki/BIOS_boot_partition)
Yes. Apparently on GPT disks grub has no hidden place to install its loader (when installing to the MBR), so uses instead a dedicated partition. It is a bit confusing, but on the other hand, is a better design. You can even back it up on image backups :-)
Prior to this new computer I'd never installed on a machine with a GPT.
If I remember correctly, there is some point at the partitioner where you can choose which partitions to overwrite and which to leave intact, and then ask the installer to make a new proposal.
Yes, I think I tried that but the installer said something like the partition scheme I wanted was unsupported.
It certainly failed to boot...
That's misleading; I installed no bootloader in TW, but there's no problem booting TW from the GRUB2 installed in Leap.
Indeed. Thus TW does not boot on its own. If you do a kernel update on it, you need to run os-prober on Leap to update the entry. Ah! Unless you add an entry using the kernel symlink. ;-)
Note that when I open the Boot Loader module in Leap, it shows GRUB2 as the boot loader, and "Boot from Partition", "Set active Flag in Partition Table for Boot Partition" and "Write generic Boot Code to MBR" are checked and "Protective MBR flag" is set to "do not change". Is this display expected even if the bootloader is using EFI?
It is not using EFI, IMO. The settings are what I would do on a BIOS machine.
Your current setup is, I think, that Leap os-prober found the TW partition and added entries for it in its own grub. You have currently no way to boot by default the second grub - in bios mode. If you switch the computer to EFI mode, it is possible that Leap will not boot, and the the TW boot was incomplete and might not boot. The latter is just a feeling.
You should check your bios, what mode it is in.
The BIOS has UEFI CSM support enabled "to support a legacy PC boot process."
So, you are in BIOS mode, I think. :-??
Either that or the computer sees there is no proper EFI boot system and defaults to Legacy.
Maybe it is some sort of dual mode, TW detected EFI and tried to install in EFI mode... :-?
(confused)
You're not the only one who's confused. You're previous reply had almost convinced me that the system was booting in legacy mode (despite what Felix said), and that BIOS setting seems to confirm that. But then I found this (http://www.rodsbooks.com/linux-uefi/):
"You should verify an EFI-mode boot by dropping to a Linux shell and typing ls /sys/firmware/efi. If you see a list of files and directories, you've booted in EFI mode [...]".
And indeed, this is in the running Leap:
steve@linux-tuxedo:~> ls -l /sys/firmware/efi/ total 0 -r--r--r-- 1 root root 4096 May 12 23:44 config_table drwxr-xr-x 2 root root 0 May 12 15:12 efivars drwxr-xr-x 3 root root 0 May 12 23:44 esrt -r--r--r-- 1 root root 4096 May 12 23:44 fw_platform_size -r--r--r-- 1 root root 4096 May 12 23:44 fw_vendor -r--r--r-- 1 root root 4096 May 12 23:44 runtime drwxr-xr-x 13 root root 0 May 12 23:44 runtime-map drwxr-xr-x 2 root root 0 May 12 23:44 secret-key -r-------- 1 root root 4096 May 12 23:44 systab drwxr-xr-x 96 root root 0 May 12 23:44 vars
Ah, I didn't know that. But I think your computer has a dual stack, EFI/Legacy. EFI is there, but the machine booted as legacy. Leap is installed in legacy mode...
And since that is enabled, that permits configuring "whether to enable the UEFI or legacy option ROM for the storage device controller" and also "for the PCI device controller other than the LAN, storage device, and graphics controllers"; both are set to enable "UEFI option ROM only."
If you are going to install again, disable legacy and go for pure EFI, and wipe the disk. Just install then Leap but not using the entire disk to leave space for TW.
With everything I've understood you to have said before, this advice surprises me. Why pure EFI? Legacy seems much simpler, and it's worked fine for me till now for booting multiple systems installed on the same machine. Or is it really inadvisable to keep CSM support enable in the BIOS, installing Leap and TW using EFI but leaving the option of legacy booting for other systems that may not support EFI the was openSUSE does?
Well, EFI was designed from the start to support booting several different operating systems, while legacy uses hacks. There is an "EFI" menu that allows you to choose what to boot each time. Of course, we understand legacy better ;-) However, if you do want to use old systems, then you need legacy.
And if you don't have another computer, make sure to have the XFCE aka Rescue image installed in an USB stick (4GB suffices) and boot it at least once to know it works. Even if you have another computer :-)
I'm using the SSD for system installation only; all my data are on other disks and I have installation media on USB and DVDs.
Of course, not saying that. I mean that if the machine breaks and you need repairing or accessing things, better be prepared and have another system you can boot and work with. -- Cheers / Saludos, Carlos E. R. (from openSUSE, Leap 15.1 x86_64 (ssd-test)) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 13 May 2019 12:03:14 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 13/05/2019 01.14, Stephen Berman wrote:
On Sun, 12 May 2019 23:15:33 +0200 "Carlos E. R." <> wrote: [...]
(the proper filesystem for /boot, if it exists, is ext2).
I seem to recall that advice from older installations; is it still considered valid?
Sure.
Reasoning is that on such a small partition (250 MB?) it is a waste to use space on a journal; and anyway, being small fsck goes fast if needed, even without a journal.
But if you do want a journal, go for ext4.
I do not understand why the install would want a separate /boot.
The EFI partition is formatted as vfat, and is mounted inside /boot. There is only one per disk. It is however very strange to have Leap using bios mode and TW using EFI mode.
This is something I'm still unclear about. You say there is only one EFI partition per disk and you also say a separate /boot partition is neither advantageous nor needed. But IIUC the recommended location of the EFI partition is /boot/efi. So what happens in a computer with multiple systems? That would seem to require a separate /boot partition, or can symlinks be used? And what happens if you want to upgrade or even replace the system in whose /boot the EFI partition resides? [...]
The BIOS has UEFI CSM support enabled "to support a legacy PC boot process."
So, you are in BIOS mode, I think. :-??
Either that or the computer sees there is no proper EFI boot system and defaults to Legacy.
Maybe it is some sort of dual mode, TW detected EFI and tried to install in EFI mode... :-?
(confused)
You're not the only one who's confused. You're previous reply had almost convinced me that the system was booting in legacy mode (despite what Felix said), and that BIOS setting seems to confirm that. But then I found this (http://www.rodsbooks.com/linux-uefi/):
"You should verify an EFI-mode boot by dropping to a Linux shell and typing ls /sys/firmware/efi. If you see a list of files and directories, you've booted in EFI mode [...]".
And indeed, this is in the running Leap:
steve@linux-tuxedo:~> ls -l /sys/firmware/efi/ total 0 -r--r--r-- 1 root root 4096 May 12 23:44 config_table drwxr-xr-x 2 root root 0 May 12 15:12 efivars drwxr-xr-x 3 root root 0 May 12 23:44 esrt -r--r--r-- 1 root root 4096 May 12 23:44 fw_platform_size -r--r--r-- 1 root root 4096 May 12 23:44 fw_vendor -r--r--r-- 1 root root 4096 May 12 23:44 runtime drwxr-xr-x 13 root root 0 May 12 23:44 runtime-map drwxr-xr-x 2 root root 0 May 12 23:44 secret-key -r-------- 1 root root 4096 May 12 23:44 systab drwxr-xr-x 96 root root 0 May 12 23:44 vars
Ah, I didn't know that.
But I think your computer has a dual stack, EFI/Legacy. EFI is there, but the machine booted as legacy. Leap is installed in legacy mode...
And since that is enabled, that permits configuring "whether to enable the UEFI or legacy option ROM for the storage device controller" and also "for the PCI device controller other than the LAN, storage device, and graphics controllers"; both are set to enable "UEFI option ROM only."
If you are going to install again, disable legacy and go for pure EFI, and wipe the disk. Just install then Leap but not using the entire disk to leave space for TW.
With everything I've understood you to have said before, this advice surprises me. Why pure EFI? Legacy seems much simpler, and it's worked fine for me till now for booting multiple systems installed on the same machine. Or is it really inadvisable to keep CSM support enable in the BIOS, installing Leap and TW using EFI but leaving the option of legacy booting for other systems that may not support EFI the was openSUSE does?
Well, EFI was designed from the start to support booting several different operating systems, while legacy uses hacks. There is an "EFI" menu that allows you to choose what to boot each time.
I disabled the UEFI CSM support in the BIOS, which IIUC means the computer is using pure EFI. I was prepared to not be able to boot either Leap or TW anymore, but in fact AFAICT nothing has changed: the GRUB2 menu appears just as before and both systems boot fine. Of course I didn't reinstall GRUB2; does that mean the systems are still booting in legacy mode even though this is disabled in BIOS -- is that even possible? Steve Berman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 13/05/2019 22.19, Stephen Berman wrote:
On Mon, 13 May 2019 12:03:14 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 13/05/2019 01.14, Stephen Berman wrote:
On Sun, 12 May 2019 23:15:33 +0200 "Carlos E. R." <> wrote: [...]
(the proper filesystem for /boot, if it exists, is ext2).
I seem to recall that advice from older installations; is it still considered valid?
Sure.
Reasoning is that on such a small partition (250 MB?) it is a waste to use space on a journal; and anyway, being small fsck goes fast if needed, even without a journal.
But if you do want a journal, go for ext4.
I do not understand why the install would want a separate /boot.
The EFI partition is formatted as vfat, and is mounted inside /boot. There is only one per disk. It is however very strange to have Leap using bios mode and TW using EFI mode.
This is something I'm still unclear about. You say there is only one EFI partition per disk and you also say a separate /boot partition is neither advantageous nor needed. But IIUC the recommended location of the EFI partition is /boot/efi. So what happens in a computer with multiple systems? That would seem to require a separate /boot partition, or can symlinks be used? And what happens if you want to upgrade or even replace the system in whose /boot the EFI partition resides?
When there is no separate /boot partition, it simply a normal directory, /boot :-) And each "/" root has a /boot. And each /boot mounts the same efi, as /boot/efi
[...]
Well, EFI was designed from the start to support booting several different operating systems, while legacy uses hacks. There is an "EFI" menu that allows you to choose what to boot each time.
I disabled the UEFI CSM support in the BIOS, which IIUC means the computer is using pure EFI. I was prepared to not be able to boot either Leap or TW anymore, but in fact AFAICT nothing has changed: the GRUB2 menu appears just as before and both systems boot fine. Of course I didn't reinstall GRUB2; does that mean the systems are still booting in legacy mode even though this is disabled in BIOS -- is that even possible?
I don't know... You got me more confused. -- Cheers / Saludos, Carlos E. R. (from openSUSE, Leap 15.1 x86_64 (ssd-test)) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 13 May 2019 22:47:13 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 13/05/2019 22.19, Stephen Berman wrote:
This is something I'm still unclear about. You say there is only one EFI partition per disk and you also say a separate /boot partition is neither advantageous nor needed. But IIUC the recommended location of the EFI partition is /boot/efi. So what happens in a computer with multiple systems? That would seem to require a separate /boot partition, or can symlinks be used? And what happens if you want to upgrade or even replace the system in whose /boot the EFI partition resides?
When there is no separate /boot partition, it simply a normal directory, /boot :-)
And each "/" root has a /boot.
And each /boot mounts the same efi, as /boot/efi
Ok, so no separate /boot partition, but there has to be an EFI partition, which will be mounted in each system at /boot/efi, right? Must the EFI partition be the first disk partition or can it be anywhere? Do you happen to know whether, if I start with a clean disk in an EFI-enabled machine and let the openSUSE installer propose a partition scheme, it will include the EFI partition? [...]
I disabled the UEFI CSM support in the BIOS, which IIUC means the computer is using pure EFI. I was prepared to not be able to boot either Leap or TW anymore, but in fact AFAICT nothing has changed: the GRUB2 menu appears just as before and both systems boot fine. Of course I didn't reinstall GRUB2; does that mean the systems are still booting in legacy mode even though this is disabled in BIOS -- is that even possible?
I don't know... You got me more confused.
¡Qué lástima! :-( Steve Berman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Stephen Berman composed on 2019-05-14 00:25 (UTC+0200):
On Mon, 13 May 2019 22:47:13 +0200 "Carlos E. R." wrote:
When there is no separate /boot partition, it simply a normal directory, /boot :-)
And each "/" root has a /boot.
And each /boot mounts the same efi, as /boot/efi
Ok, so no separate /boot partition, but there has to be an EFI partition,
Absent one, you won't be booting any UEFI installation.
which will be mounted in each system at /boot/efi, right?
That's the convention, but having more than one installation doing so is not necessary. IOW, the one that routinely does mount it there will be the one in control of each initial handoff from the BIOS after POST. If you do routinely keep more than one installation mounting it there, you'll be forced into some sort of routine to respond to one's kernel update process usurping control from the one not you wish to keep in control. If you don't care which is in control, then it should matter to keep them all mounting it there. On mine, only on TW is it routinely (if ever) mounted there. If you wish access to it regardless of what you have booted, simply mount it elsewhere on all but one.
Must the EFI partition be the first disk partition or can it be anywhere?
It can be anywhere, but first is a good convention.
Do you happen to know whether, if I start with a clean disk in an EFI-enabled machine and let the openSUSE installer propose a partition scheme, it will include the EFI partition?
If perfectly clean, yes, assuming the installer actually gets booted in UEFI mode. With CSM fully disabled, and booted into the installer's UEFI mode, I would call it a bug worthy of report if it does not. It's not something testable here without violating my strict convention. My partitioning is always complete before an installer is started on it.
I disabled the UEFI CSM support in the BIOS, which IIUC means the computer is using pure EFI. I was prepared to not be able to boot either Leap or TW anymore, but in fact AFAICT nothing has changed: the GRUB2 menu appears just as before and both systems boot fine. Of course I didn't reinstall GRUB2; does that mean the systems are still booting in legacy mode even though this is disabled in BIOS -- is that even possible?
I don't know... You got me more confused.
¡Qué lástima! :-(
I never did figure out where in this thread you got convinced that you might not be booting either installation in UEFI mode, ie. confusion here too. :-p -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 13 May 2019 21:35:57 -0400 Felix Miata <mrmazda@earthlink.net> wrote:
Stephen Berman composed on 2019-05-14 00:25 (UTC+0200):
On Mon, 13 May 2019 22:47:13 +0200 "Carlos E. R." wrote:
When there is no separate /boot partition, it simply a normal directory, /boot :-)
And each "/" root has a /boot.
And each /boot mounts the same efi, as /boot/efi
Ok, so no separate /boot partition, but there has to be an EFI partition,
Absent one, you won't be booting any UEFI installation.
which will be mounted in each system at /boot/efi, right?
That's the convention, but having more than one installation doing so is not necessary. IOW, the one that routinely does mount it there will be the one in control of each initial handoff from the BIOS after POST. If you do routinely keep more than one installation mounting it there, you'll be forced into some sort of routine to respond to one's kernel update process usurping control from the one not you wish to keep in control. If you don't care which is in control, then it should matter to keep them all mounting it there. On mine, only on TW is it routinely (if ever) mounted there. If you wish access to it regardless of what you have booted, simply mount it elsewhere on all but one.
Thanks for clearly laying out the pros and cons.
Must the EFI partition be the first disk partition or can it be anywhere?
It can be anywhere, but first is a good convention.
Do you happen to know whether, if I start with a clean disk in an EFI-enabled machine and let the openSUSE installer propose a partition scheme, it will include the EFI partition?
If perfectly clean, yes, assuming the installer actually gets booted in UEFI mode. With CSM fully disabled, and booted into the installer's UEFI mode, I would call it a bug worthy of report if it does not.
Good to know; hopefully I won't need to report a bug...
It's not something testable here without violating my strict convention. My partitioning is always complete before an installer is started on it.
I usually do that too, but in this case may be better to start with a clean slate.
I disabled the UEFI CSM support in the BIOS, which IIUC means the computer is using pure EFI. I was prepared to not be able to boot either Leap or TW anymore, but in fact AFAICT nothing has changed: the GRUB2 menu appears just as before and both systems boot fine. Of course I didn't reinstall GRUB2; does that mean the systems are still booting in legacy mode even though this is disabled in BIOS -- is that even possible?
I don't know... You got me more confused.
¡Qué lástima! :-(
I never did figure out where in this thread you got convinced that you might not be booting either installation in UEFI mode, ie. confusion here too. :-p
Carlos drew that conclusion in https://lists.opensuse.org/opensuse/2019-05/msg00459.html: If what you said is correct, that the computer came with "/boot, / (root) and swap", then for sure it was booting in BIOS mode, even if the disk is GPT. I see on bootinfo that you have "Syslinux GPTMBR (4.04-5.01) is installed in the MBR of /dev/nvme0n1"n which confirms it. And in https://lists.opensuse.org/opensuse/2019-05/msg00467.html I replied: You're previous reply had almost convinced me that the system was booting in legacy mode (despite what Felix said), and that BIOS setting seems to confirm that. But then I found this (http://www.rodsbooks.com/linux-uefi/): "You should verify an EFI-mode boot by dropping to a Linux shell and typing ls /sys/firmware/efi. If you see a list of files and directories, you've booted in EFI mode [...]". And indeed, this is in the running Leap [...] To which Carlos again replied in https://lists.opensuse.org/opensuse/2019-05/msg00471.html: But I think your computer has a dual stack, EFI/Legacy. EFI is there, but the machine booted as legacy. Leap is installed in legacy mode... Steve Berman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 14/05/2019 00.25, Stephen Berman wrote:
On Mon, 13 May 2019 22:47:13 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 13/05/2019 22.19, Stephen Berman wrote:
This is something I'm still unclear about. You say there is only one EFI partition per disk and you also say a separate /boot partition is neither advantageous nor needed. But IIUC the recommended location of the EFI partition is /boot/efi. So what happens in a computer with multiple systems? That would seem to require a separate /boot partition, or can symlinks be used? And what happens if you want to upgrade or even replace the system in whose /boot the EFI partition resides?
When there is no separate /boot partition, it simply a normal directory, /boot :-)
And each "/" root has a /boot.
And each /boot mounts the same efi, as /boot/efi
Ok, so no separate /boot partition, but there has to be an EFI partition, which will be mounted in each system at /boot/efi, right? Must the EFI partition be the first disk partition or can it be anywhere?
AFAIK, anywhere.
Do you happen to know whether, if I start with a clean disk in an EFI-enabled machine and let the openSUSE installer propose a partition scheme, it will include the EFI partition?
It should create one if none exists. If it exists already, it should use it. The installer itself must boot in EFI mode. Or rather, if it doesn't, it means it did not detect EFI and will proceed in Bios mode. Visually, both types of Grub boots are different, so it is possible that early to know if things are going on as they should. But I don't know by memory which is which. -- Cheers / Saludos, Carlos E. R. (from openSUSE, Leap 15.1 x86_64 (ssd-test)) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, 14 May 2019 04:30:33 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 14/05/2019 00.25, Stephen Berman wrote:
On Mon, 13 May 2019 22:47:13 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 13/05/2019 22.19, Stephen Berman wrote:
This is something I'm still unclear about. You say there is only one EFI partition per disk and you also say a separate /boot partition is neither advantageous nor needed. But IIUC the recommended location of the EFI partition is /boot/efi. So what happens in a computer with multiple systems? That would seem to require a separate /boot partition, or can symlinks be used? And what happens if you want to upgrade or even replace the system in whose /boot the EFI partition resides?
When there is no separate /boot partition, it simply a normal directory, /boot :-)
And each "/" root has a /boot.
And each /boot mounts the same efi, as /boot/efi
Ok, so no separate /boot partition, but there has to be an EFI partition, which will be mounted in each system at /boot/efi, right? Must the EFI partition be the first disk partition or can it be anywhere?
AFAIK, anywhere.
Do you happen to know whether, if I start with a clean disk in an EFI-enabled machine and let the openSUSE installer propose a partition scheme, it will include the EFI partition?
It should create one if none exists. If it exists already, it should use it.
The installer itself must boot in EFI mode. Or rather, if it doesn't, it means it did not detect EFI and will proceed in Bios mode. Visually, both types of Grub boots are different, so it is possible that early to know if things are going on as they should. But I don't know by memory which is which.
Thanks. I'll reinstall, probably with a clean disk, as soon as I have time to, and report back here, hopefully with a success story (or else, with more questions :o ...). Steve Berman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Stephen Berman composed on 2019-05-14 21:12 (UTC+0200):
I'll reinstall, probably with a clean disk, as soon as I have time to, and report back here, hopefully with a success story (or else, with more questions :o ...).
One more thing first. This thread probably should have started with sharing /etc/fstab for both Leap and TW. I don't remember seeing that happen. If the installer caused something to get mounted on /boot/efi/, it's a pretty sure sign the installation was in UEFI mode. Likewise, output from efibootmgr is quite telling, at least for Leap, since you are (were?) booting from its Grub. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 14/05/2019 23.55, Felix Miata wrote:
Stephen Berman composed on 2019-05-14 21:12 (UTC+0200):
I'll reinstall, probably with a clean disk, as soon as I have time to, and report back here, hopefully with a success story (or else, with more questions :o ...).
One more thing first. This thread probably should have started with sharing /etc/fstab for both Leap and TW. I don't remember seeing that happen. If the installer caused something to get mounted on /boot/efi/, it's a pretty sure sign the installation was in UEFI mode. Likewise, output from efibootmgr is quite telling, at least for Leap, since you are (were?) booting from its Grub.
That's one of the reasons I asked for "Boot Info Script" output, it contains fstab ;-) Here: <http://susepaste.org/89683428> Although in this case it would be interesting to see the output from both Leap and TW sides, it will be different. nvme0n1p2/etc/fstab: # device during installation: /dev/nvme0n1p1 UUID=5F45-40A6 /boot/efi vfat rw 0 2 (and no separate /boot partition) nvme0n1p4/etc/fstab: UUID=7e9f203e-16c1-4c48-8ded-d7918621cb38 / btrfs defaults 0 0 UUID=7e9f203e-16c1-4c48-8ded-d7918621cb38 /boot/grub2/x86_64-efi btrfs subvol=/@/boot/grub2/x86_64-efi 0 0 UUID=7e9f203e-16c1-4c48-8ded-d7918621cb38 /boot/grub2/i386-pc btrfs subvol=/@/boot/grub2/i386-pc 0 0 The second (and third) one I don't know what they are, but they are not an EFI partition. (and no /boot partition) (and it is btrfs) And this was the running system mountpoints at the time: ================================ Mount points: ================================= Device Mount_Point Type Options /dev/nvme0n1p1 /boot/efi vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro) Call me confused if I know which is TW and which Leap, because there is no separate /boot partition anywhere :-) -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On Wed, 15 May 2019 01:29:55 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 14/05/2019 23.55, Felix Miata wrote:
Stephen Berman composed on 2019-05-14 21:12 (UTC+0200):
I'll reinstall, probably with a clean disk, as soon as I have time to, and report back here, hopefully with a success story (or else, with more questions :o ...).
One more thing first. This thread probably should have started with sharing /etc/fstab for both Leap and TW. I don't remember seeing that happen. If the installer caused something to get mounted on /boot/efi/, it's a pretty sure sign the installation was in UEFI mode. Likewise, output from efibootmgr is quite telling, at least for Leap, since you are (were?) booting from its Grub.
The output of efibootmgr when CSM is enabled in the BIOS is different from the output when CSM is disabled (i.e. UEFI only). Originally, and when I installed TW, CSM was enabled, but in preparation for reinstallation using pure EFI I disabled it, and this is what efibootmgr now outputs: BootCurrent: 0000 Timeout: 1 seconds BootOrder: 0000 Boot0000* opensuse With CSM enabled I recall there being three entries in BootOrder and three Boot* entries.
That's one of the reasons I asked for "Boot Info Script" output, it contains fstab ;-)
Here: <http://susepaste.org/89683428>
Although in this case it would be interesting to see the output from both Leap and TW sides, it will be different.
There are no significant differences, that's why I didn't bother uploading the results for TW.
nvme0n1p2/etc/fstab:
# device during installation: /dev/nvme0n1p1 UUID=5F45-40A6 /boot/efi vfat rw 0 2
(and no separate /boot partition)
nvme0n1p4/etc/fstab:
UUID=7e9f203e-16c1-4c48-8ded-d7918621cb38 / btrfs defaults 0 0 UUID=7e9f203e-16c1-4c48-8ded-d7918621cb38 /boot/grub2/x86_64-efi btrfs subvol=/@/boot/grub2/x86_64-efi 0 0 UUID=7e9f203e-16c1-4c48-8ded-d7918621cb38 /boot/grub2/i386-pc btrfs subvol=/@/boot/grub2/i386-pc 0 0
The second (and third) one I don't know what they are, but they are not an EFI partition.
(and no /boot partition) (and it is btrfs)
And this was the running system mountpoints at the time:
================================ Mount points: =================================
Device Mount_Point Type Options
/dev/nvme0n1p1 /boot/efi vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
Call me confused if I know which is TW and which Leap, because there is no separate /boot partition anywhere :-)
Perhaps I've been mistaken in asserting there is a /boot partition. This is what ls -l /boot shows: total 61760 -rw-r--r-- 1 root root 65 Apr 3 14:11 .vmlinuz-4.12.14-lp150.12.58-default.hmac -rw-r--r-- 1 root root 65 Feb 20 2018 .vmlinuz-4.12.14-lp150.4-default.hmac -rw-r--r-- 1 root root 3481827 Apr 3 12:47 System.map-4.12.14-lp150.12.58-default -rw-r--r-- 1 root root 3450845 Feb 20 2018 System.map-4.12.14-lp150.4-default -rw-r--r-- 1 root root 1725 Dec 19 10:14 boot.readme -rw-r--r-- 1 root root 196275 Apr 3 11:42 config-4.12.14-lp150.12.58-default -rw-r--r-- 1 root root 195680 Feb 20 2018 config-4.12.14-lp150.4-default drwxr-xr-x 3 root root 4096 Jan 1 1970 efi drwxr-xr-x 7 root root 4096 May 10 00:37 grub2 lrwxrwxrwx 1 root root 34 Apr 15 17:57 initrd -> initrd-4.12.14-lp150.12.58-default -rw------- 1 root root 12103140 May 13 19:39 initrd-4.12.14-lp150.12.58-default -rw------- 1 root root 11789504 May 13 19:39 initrd-4.12.14-lp150.4-default -rw-r--r-- 1 root root 1125367 Apr 3 13:20 symtypes-4.12.14-lp150.12.58-default.gz -rw-r--r-- 1 root root 389180 Apr 3 13:08 symvers-4.12.14-lp150.12.58-default.gz -rw-r--r-- 1 root root 384978 Feb 20 2018 symvers-4.12.14-lp150.4-default.gz -rw-r--r-- 1 root root 484 Apr 3 13:08 sysctl.conf-4.12.14-lp150.12.58-default -rw-r--r-- 1 root root 484 Feb 20 2018 sysctl.conf-4.12.14-lp150.4-default -rw-r--r-- 1 root root 8052103 Apr 3 13:28 vmlinux-4.12.14-lp150.12.58-default.gz -rw-r--r-- 1 root root 7949431 Feb 20 2018 vmlinux-4.12.14-lp150.4-default.gz lrwxrwxrwx 1 root root 35 Apr 15 17:57 vmlinuz -> vmlinuz-4.12.14-lp150.12.58-default -rw-r--r-- 1 root root 7082096 Apr 3 14:11 vmlinuz-4.12.14-lp150.12.58-default -rw-r--r-- 1 root root 6987984 Feb 20 2018 vmlinuz-4.12.14-lp150.4-default Is it possible that only the efi directory is a separate partition, mounted under /boot, and /boot itself and the rest of its contents are in the root partition? If that is the case, perhaps I can keep the Leap installation, and just reinstall TW, now in pure UEFI. My previous installation was with CSM enabled and the boot screen was the one the openSUSE Start-Up guide says is shown "on machines with a traditional BIOS" (https://doc.opensuse.org/documentation/leap/startup/single-html/book.opensus...). After disabling CSM, a test of the installer showed the "boot screen on machines with UEFi" (https://doc.opensuse.org/documentation/leap/startup/single-html/book.opensus...). If I do leave Leap as is and just reinstall TW, can I mount the EFI partition to TW's /boot without jeopardizing booting Leap? Also, is it a cause for concern that, as the bootinfo script showed, Syslinux GPTMBR is installed in the MBR of of the SSD on which Leap and TW are installed? That is, would it be better to wipe the disk and repartition and reinstall everything? Steve Berman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 15/05/2019 21.29, Stephen Berman wrote:
On Wed, 15 May 2019 01:29:55 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 14/05/2019 23.55, Felix Miata wrote:
Stephen Berman composed on 2019-05-14 21:12 (UTC+0200):
I'll reinstall, probably with a clean disk, as soon as I have time to, and report back here, hopefully with a success story (or else, with more questions :o ...).
One more thing first. This thread probably should have started with sharing /etc/fstab for both Leap and TW. I don't remember seeing that happen. If the installer caused something to get mounted on /boot/efi/, it's a pretty sure sign the installation was in UEFI mode. Likewise, output from efibootmgr is quite telling, at least for Leap, since you are (were?) booting from its Grub.
The output of efibootmgr when CSM is enabled in the BIOS is different from the output when CSM is disabled (i.e. UEFI only). Originally, and when I installed TW, CSM was enabled, but in preparation for reinstallation using pure EFI I disabled it, and this is what efibootmgr now outputs:
BootCurrent: 0000 Timeout: 1 seconds BootOrder: 0000 Boot0000* opensuse
With CSM enabled I recall there being three entries in BootOrder and three Boot* entries.
In pure Legacy mode it should output nothing. ...
Is it possible that only the efi directory is a separate partition, mounted under /boot, and /boot itself and the rest of its contents are in the root partition?
Yes.
If that is the case, perhaps I can keep the Leap installation, and just reinstall TW, now in pure UEFI. My previous installation was with CSM enabled and the boot screen was the one the openSUSE Start-Up guide says is shown "on machines with a traditional BIOS" (https://doc.opensuse.org/documentation/leap/startup/single-html/book.opensus...).
That was it, I could not recall where I had seen it. <https://doc.opensuse.org/documentation/leap/startup/single-html/book.opensuse.startup/#sec.boot_parameters.screen> vs <https://doc.opensuse.org/documentation/leap/startup/single-html/book.opensuse.startup/#sec.boot_parameters.uefi> To install in UEFI mode you have to see the second screen when booting the installation system. If you see the first screen, reboot and change bios parameters.
After disabling CSM, a test of the installer showed the "boot screen on machines with UEFi" (https://doc.opensuse.org/documentation/leap/startup/single-html/book.opensus...).
Yes!
If I do leave Leap as is and just reinstall TW, can I mount the EFI partition to TW's /boot without jeopardizing booting Leap?
The same EFI partition can be mounted in as many operating systems you install. It should have different directories inside for each.
Also, is it a cause for concern that, as the bootinfo script showed, Syslinux GPTMBR is installed in the MBR of of the SSD on which Leap and TW are installed?
No.
That is, would it be better to wipe the disk and repartition and reinstall everything?
I don't know for sure. As you have a backup, I would probably go that route and install everything to my exact liking. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Carlos E. R. composed on 2019-05-15 21:56 (UTC+0200):
The same EFI partition can be mounted in as many operating systems you install. It should have different directories inside for each.
It /should/, but don't count on it, unless you are exercising oversight of GRUB_DISTRIBUTOR= on each (making each unique). -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Stephen Berman composed on 2019-05-15 21:29 (UTC+0200):
The output of efibootmgr when CSM is enabled in the BIOS is different from the output when CSM is disabled (i.e. UEFI only). Originally, and when I installed TW, CSM was enabled, but in preparation for reinstallation using pure EFI I disabled it, and this is what efibootmgr now outputs:
BootCurrent: 0000 Timeout: 1 seconds BootOrder: 0000 Boot0000* opensuse
Unless you change Leap's GRUB_DISTRIBUTOR= first, you'll still have only one opensuse entry after reinstalling TW in UEFI mode.
Perhaps I've been mistaken in asserting there is a /boot partition. This is what ls -l /boot shows:
You clearly have been. A historically good way to tell is by viewing fstab, not /boot/ content. If using btrfs, it may not be so clear. Another way is to try to run 'umount /boot'. It will fail if there is no separate filesystem mounted to /boot/.
Is it possible that only the efi directory is a separate partition, mounted under /boot, and /boot itself and the rest of its contents are in the root partition?
This is quite clearly the normal case. Separate /boot partitions are typically used for LVM and/or RAID installations and/or various encryption configurations, and few others.
If that is the case, perhaps I can keep the Leap installation, and just reinstall TW, now in pure UEFI.
Having the ESP partition mounted to /boot/efi/ in fstab I find it hard to understand that there would be any need to reinstall to ensure TW is only used in UEFI mode. If it was here, first thing I would try is changing TW's GRUB_DISTRIBUTOR= to something unique, then running yast bootloader, changing the timeout, exiting, and rebooting, all assuming in your TW you see the following: # rpm -qa | egrep -i 'grub|prober' grub2-2.02-43.1.x86_64 grub2-i386-pc-2.02-43.1.noarch grub2-x86_64-efi-2.02-43.1.noarch os-prober-1.76-5.1.x86_64 ruby2.6-rubygem-cfa_grub2-1.0.1-1.3.x86_64 -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 15/05/2019 23.57, Felix Miata wrote:
Stephen Berman composed on 2019-05-15 21:29 (UTC+0200):
The output of efibootmgr when CSM is enabled in the BIOS is different from the output when CSM is disabled (i.e. UEFI only). Originally, and when I installed TW, CSM was enabled, but in preparation for reinstallation using pure EFI I disabled it, and this is what efibootmgr now outputs:
BootCurrent: 0000 Timeout: 1 seconds BootOrder: 0000 Boot0000* opensuse
Unless you change Leap's GRUB_DISTRIBUTOR= first, you'll still have only one opensuse entry after reinstalling TW in UEFI mode.
I heard it is possible to do during the initial installation, but not from YaST. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Carlos E. R. composed on 2019-05-16 03:53 (UTC+0200):
Felix Miata wrote:
Unless you change Leap's GRUB_DISTRIBUTOR= first, you'll still have only one opensuse entry after reinstalling TW in UEFI mode.
I heard it is possible to do during the initial installation, but not from YaST.
Not possible AFAICT. Maybe https://lists.opensuse.org/yast-devel/2018-06/msg00031.html or https://bugzilla.opensuse.org/show_bug.cgi?id=1101756 is what you remember. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 16/05/2019 04.10, Felix Miata wrote:
Carlos E. R. composed on 2019-05-16 03:53 (UTC+0200):
Felix Miata wrote:
Unless you change Leap's GRUB_DISTRIBUTOR= first, you'll still have only one opensuse entry after reinstalling TW in UEFI mode.
I heard it is possible to do during the initial installation, but not from YaST.
Not possible AFAICT. Maybe https://lists.opensuse.org/yast-devel/2018-06/msg00031.html or https://bugzilla.opensuse.org/show_bug.cgi?id=1101756 is what you remember.
I don't read the yast mail list. Re the filesystem being still mounted but not shown, Per mentioned the same problem about a week ago. I would suggest Stephen to change now the variable on the Leap install to something different previous to attempt install of TW, and after install change the setting in TW as well. Thus none will use "" except for one boot. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.0 (Legolas))
On Thu, 16 May 2019 11:08:25 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 16/05/2019 04.10, Felix Miata wrote:
Carlos E. R. composed on 2019-05-16 03:53 (UTC+0200):
Felix Miata wrote:
Unless you change Leap's GRUB_DISTRIBUTOR= first, you'll still have only one opensuse entry after reinstalling TW in UEFI mode.
I heard it is possible to do during the initial installation, but not from YaST.
Not possible AFAICT. Maybe https://lists.opensuse.org/yast-devel/2018-06/msg00031.html or https://bugzilla.opensuse.org/show_bug.cgi?id=1101756 is what you remember.
I don't read the yast mail list. Re the filesystem being still mounted but not shown, Per mentioned the same problem about a week ago.
I would suggest Stephen to change now the variable on the Leap install to something different previous to attempt install of TW, and after install change the setting in TW as well. Thus none will use "" except for one boot.
Changing GRUB_DISTRIBUTOR didn't work but also doesn't seem to be needed, as described in the reply I just posted to Felix's and your previous answers. But maybe I did something wrong. Steve Berman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 16/05/2019 11.41, Stephen Berman wrote:
On Thu, 16 May 2019 11:08:25 +0200 "Carlos E. R." <> wrote:
I would suggest Stephen to change now the variable on the Leap install to something different previous to attempt install of TW, and after install change the setting in TW as well. Thus none will use "" except for one boot.
Changing GRUB_DISTRIBUTOR didn't work but also doesn't seem to be needed, as described in the reply I just posted to Felix's and your previous answers. But maybe I did something wrong.
I changed it yesterday on a Bios machine and it worked, which in that case means only changing a line in the Grub boot display. In this EFI laptop I changed it time ago. Legolas:~ # grep -i distribu /etc/default/grub # Uncomment to set your own custom distributor. If you leave it unset or empty, the default GRUB_DISTRIBUTOR=opensuse_main Legolas:~ # efibootmgr -v | less -S BootCurrent: 0000 Timeout: 2 seconds BootOrder: 0000,0004,0002,0001,0003,2001,2002,2003 Boot0000* opensuse_main-secureboot ... Boot0001* Windows Boot Manager ... Boot0002* opensuse-secureboot ... Boot0003* openSUSE ... Boot0004* opensuse_aux-secureboot ... Boot2001* EFI USB Device RC Boot2002* EFI DVD/CDROM RC Boot2003* EFI Network RC Notice the "main" word in efibootmgr output, and another entry with "aux". And the directories: Legolas:~ # ls /boot/efi/EFI/ Boot Microsoft opensuse opensuse_aux opensuse_main Legolas:~ # So here it worked. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.0 (Legolas))
On Wed, 15 May 2019 17:57:11 -0400 Felix Miata <mrmazda@earthlink.net> wrote:
Stephen Berman composed on 2019-05-15 21:29 (UTC+0200):
The output of efibootmgr when CSM is enabled in the BIOS is different from the output when CSM is disabled (i.e. UEFI only). Originally, and when I installed TW, CSM was enabled, but in preparation for reinstallation using pure EFI I disabled it, and this is what efibootmgr now outputs:
BootCurrent: 0000 Timeout: 1 seconds BootOrder: 0000 Boot0000* opensuse
Unless you change Leap's GRUB_DISTRIBUTOR= first, you'll still have only one opensuse entry after reinstalling TW in UEFI mode.
I changed Leap's GRUB_DISTRIBUTOR to 'osleap', ran grub2-mkconfig as the comment in /etc/default/grub recommends, then rebooted, and the boot screen showed 'osleap' instead of 'openSUSE Leap 15.0' and also 'openSUSE Tumbleweed'. I booted into TW... [...]
Having the ESP partition mounted to /boot/efi/ in fstab I find it hard to understand that there would be any need to reinstall to ensure TW is only used in UEFI mode. If it was here, first thing I would try is changing TW's GRUB_DISTRIBUTOR= to something unique, then running yast bootloader, changing the timeout, exiting, and rebooting, all assuming in your TW you see the following:
# rpm -qa | egrep -i 'grub|prober' grub2-2.02-43.1.x86_64 grub2-i386-pc-2.02-43.1.noarch grub2-x86_64-efi-2.02-43.1.noarch os-prober-1.76-5.1.x86_64 ruby2.6-rubygem-cfa_grub2-1.0.1-1.3.x86_64
I have this output, so I changed GRUB_DISTRIBUTOR to 'ostw', went to the YaST bootloader module, changed the bootloader from GRUB2 to GRUB2 for EFI, but on saving got an error that no EFI partition was found. So I added /boot/efi to TW's fstab, went back to the bootloader module, and this time saved without error. However, doing that rewrote /etc/default/grub and unset GRUB_DISTRIBUTOR again. Nevertheless, /boot/grub2/grub.cfg showed both TW and Leap (in that order). Then I rebooted into Leap, where GRUB_DISTRIBUTOR was still set to 'osleap', ran the bootloader module, changed GRUB2 to GRUB2 for EFI, saved, and again this unset GRUB_DISTRIBUTOR, but again, on rebooting, both Leap and TW were listed (now in that order). I was assuming that, when booting in UEFI, GRUB2 for EFI should be used instead of GRUB2, but perhaps that's not necessary. What do you use? On Wed, 15 May 2019 18:36:58 -0400 Felix Miata <mrmazda@earthlink.net> wrote:
Carlos E. R. composed on 2019-05-15 21:56 (UTC+0200):
The same EFI partition can be mounted in as many operating systems you install. It should have different directories inside for each.
It /should/, but don't count on it, unless you are exercising oversight of GRUB_DISTRIBUTOR= on each (making each unique).
As described above, this didn't work for me, and no separate directories were created (where should they be, under /boot/efi ?); did I do something wrong? Do the directories need to be created manually? Also, although "Use graphical console" is checked in the Kernel Parameters tab of the bootloader module (and GRUB_TERMINAL="gfxterm" is in /etc/default/grub in both Leap and TW), the boot screen is in textmode. Other than that, I haven't noticed any problems. Steve Berman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 16/05/2019 11.38, Stephen Berman wrote:
On Wed, 15 May 2019 17:57:11 -0400 Felix Miata <mrmazda@earthlink.net> wrote:
Stephen Berman composed on 2019-05-15 21:29 (UTC+0200):
The output of efibootmgr when CSM is enabled in the BIOS is different from the output when CSM is disabled (i.e. UEFI only). Originally, and when I installed TW, CSM was enabled, but in preparation for reinstallation using pure EFI I disabled it, and this is what efibootmgr now outputs:
BootCurrent: 0000 Timeout: 1 seconds BootOrder: 0000 Boot0000* opensuse
Unless you change Leap's GRUB_DISTRIBUTOR= first, you'll still have only one opensuse entry after reinstalling TW in UEFI mode.
I changed Leap's GRUB_DISTRIBUTOR to 'osleap', ran grub2-mkconfig as the comment in /etc/default/grub recommends, then rebooted, and the boot screen showed 'osleap' instead of 'openSUSE Leap 15.0' and also 'openSUSE Tumbleweed'. I booted into TW...
Ok.
[...]
Having the ESP partition mounted to /boot/efi/ in fstab I find it hard to understand that there would be any need to reinstall to ensure TW is only used in UEFI mode. If it was here, first thing I would try is changing TW's GRUB_DISTRIBUTOR= to something unique, then running yast bootloader, changing the timeout, exiting, and rebooting, all assuming in your TW you see the following:
# rpm -qa | egrep -i 'grub|prober' grub2-2.02-43.1.x86_64 grub2-i386-pc-2.02-43.1.noarch grub2-x86_64-efi-2.02-43.1.noarch os-prober-1.76-5.1.x86_64 ruby2.6-rubygem-cfa_grub2-1.0.1-1.3.x86_64
I have this output, so I changed GRUB_DISTRIBUTOR to 'ostw', went to the YaST bootloader module, changed the bootloader from GRUB2 to GRUB2 for EFI, but on saving got an error that no EFI partition was found. So I added /boot/efi to TW's fstab, went back to the bootloader module, and this time saved without error. However, doing that rewrote /etc/default/grub and unset GRUB_DISTRIBUTOR again. Nevertheless, /boot/grub2/grub.cfg showed both TW and Leap (in that order). Then I rebooted into Leap, where GRUB_DISTRIBUTOR was still set to 'osleap', ran the bootloader module, changed GRUB2 to GRUB2 for EFI, saved, and again this unset GRUB_DISTRIBUTOR, but again, on rebooting, both Leap and TW were listed (now in that order).
Maybe the setting was deleted because you changed to grub2 for efi and that is considered a major change, but perhaps it is a bug. I would try to set distributor again, and this time in yast only change the "timeout in seconds", which is a known trick to force yast to write again its files.
I was assuming that, when booting in UEFI, GRUB2 for EFI should be used instead of GRUB2, but perhaps that's not necessary. What do you use?
In this efi machine, I have grub2 for efi active. Booting in efi mode when previously you booted in bios mode does not change things automatically.
On Wed, 15 May 2019 18:36:58 -0400 Felix Miata <mrmazda@earthlink.net> wrote:
Carlos E. R. composed on 2019-05-15 21:56 (UTC+0200):
The same EFI partition can be mounted in as many operating systems you install. It should have different directories inside for each.
It /should/, but don't count on it, unless you are exercising oversight of GRUB_DISTRIBUTOR= on each (making each unique).
As described above, this didn't work for me, and no separate directories were created (where should they be, under /boot/efi ?); did I do something wrong? Do the directories need to be created manually?
No, yast creates them: Legolas:~ # tree -d /boot/efi/ /boot/efi/ ├── BOOT └── EFI ├── Boot ├── Microsoft │ ├── Boot │ │ ├── Fonts │ │ ├── Resources │ │ │ ├── en-US │ │ │ └── es-ES │ │ ├── bg-BG │ │ ├── cs-CZ │ │ ├── da-DK │ │ ├── de-DE │ │ ├── el-GR │ │ ├── en-GB │ │ ├── en-US │ │ ├── es-ES │ │ ├── es-MX │ │ ├── et-EE │ │ ├── fi-FI │ │ ├── fr-CA │ │ ├── fr-FR │ │ ├── hr-HR │ │ ├── hu-HU │ │ ├── it-IT │ │ ├── ja-JP │ │ ├── ko-KR │ │ ├── lt-LT │ │ ├── lv-LV │ │ ├── nb-NO │ │ ├── nl-NL │ │ ├── pl-PL │ │ ├── pt-BR │ │ ├── pt-PT │ │ ├── qps-ploc │ │ ├── ro-RO │ │ ├── ru-RU │ │ ├── sk-SK │ │ ├── sl-SI │ │ ├── sr-Latn-CS │ │ ├── sr-Latn-RS │ │ ├── sv-SE │ │ ├── tr-TR │ │ ├── uk-UA │ │ ├── zh-CN │ │ ├── zh-HK │ │ └── zh-TW │ └── Recovery ├── opensuse ├── opensuse_aux └── opensuse_main 51 directories Legolas:~ # Legolas:~ # tree --si -D /boot/efi/EFI/opensuse* /boot/efi/EFI/opensuse ├── [1.2M Aug 4 2018] MokManager.efi ├── [ 58 Aug 4 2018] boot.csv ├── [ 155 Aug 4 2018] grub.cfg ├── [1.1M Aug 4 2018] grub.efi ├── [124k Aug 4 2018] grubx64.efi └── [1.2M Aug 4 2018] shim.efi /boot/efi/EFI/opensuse_aux ├── [1.2M Aug 4 2018] MokManager.efi ├── [ 66 Aug 4 2018] boot.csv ├── [ 155 Aug 4 2018] grub.cfg ├── [1.1M Aug 4 2018] grub.efi ├── [124k Aug 4 2018] grubx64.efi └── [1.2M Aug 4 2018] shim.efi /boot/efi/EFI/opensuse_main ├── [1.2M May 9 14:12] MokManager.efi ├── [ 68 May 9 14:12] boot.csv ├── [ 155 May 9 14:12] grub.cfg ├── [1.1M May 9 14:12] grub.efi ├── [124k May 9 14:12] grubx64.efi └── [1.2M May 9 14:12] shim.efi 0 directories, 18 files Legolas:~ # The "opensuse" directory is now an orphan, doesn't belong to any OS. Ie, yast created the new directory but did not delete the old - it had no way of knowing which one was the old, anyway, distributor was not changed inside yast.
Also, although "Use graphical console" is checked in the Kernel Parameters tab of the bootloader module (and GRUB_TERMINAL="gfxterm" is in /etc/default/grub in both Leap and TW), the boot screen is in textmode. Other than that, I haven't noticed any problems.
I don't know about that :-? -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.0 (Legolas))
On Thu, 16 May 2019 12:12:52 +0200 "Carlos E. R." <robin.listas@gmx.es> wrote:
On 16/05/2019 11.38, Stephen Berman wrote: [...]
I have this output, so I changed GRUB_DISTRIBUTOR to 'ostw', went to the YaST bootloader module, changed the bootloader from GRUB2 to GRUB2 for EFI, but on saving got an error that no EFI partition was found. So I added /boot/efi to TW's fstab, went back to the bootloader module, and this time saved without error. However, doing that rewrote /etc/default/grub and unset GRUB_DISTRIBUTOR again. Nevertheless, /boot/grub2/grub.cfg showed both TW and Leap (in that order). Then I rebooted into Leap, where GRUB_DISTRIBUTOR was still set to 'osleap', ran the bootloader module, changed GRUB2 to GRUB2 for EFI, saved, and again this unset GRUB_DISTRIBUTOR, but again, on rebooting, both Leap and TW were listed (now in that order).
Maybe the setting was deleted because you changed to grub2 for efi and that is considered a major change, but perhaps it is a bug. I would try to set distributor again, and this time in yast only change the "timeout in seconds", which is a known trick to force yast to write again its files.
Ah, that worked! linux-pjgr:~ # efibootmgr -v BootCurrent: 0000 Timeout: 1 seconds BootOrder: 0001,0000 Boot0000* opensuse HD(1,GPT,b925e952-4899-46a4-b68a-40d92b7b9d34,0x800,0x100000)/File(\EFI\OPENSUSE\GRUBX64.EFI) Boot0001* ostw HD(1,GPT,b925e952-4899-46a4-b68a-40d92b7b9d34,0x800,0x100000)/File(\EFI\ostw\grubx64.efi) steve@linux-pjgr:~> tree /boot/efi/ /boot/efi/ `-- EFI |-- opensuse | `-- grubx64.efi `-- ostw `-- grubx64.efi 3 directories, 2 files
On Wed, 15 May 2019 18:36:58 -0400 Felix Miata <mrmazda@earthlink.net> wrote:
Carlos E. R. composed on 2019-05-15 21:56 (UTC+0200):
The same EFI partition can be mounted in as many operating systems you install. It should have different directories inside for each.
It /should/, but don't count on it, unless you are exercising oversight of GRUB_DISTRIBUTOR= on each (making each unique).
As described above, this didn't work for me, and no separate directories were created (where should they be, under /boot/efi ?); did I do something wrong? Do the directories need to be created manually?
No, yast creates them: [...] Legolas:~ # tree --si -D /boot/efi/EFI/opensuse* /boot/efi/EFI/opensuse ├── [1.2M Aug 4 2018] MokManager.efi ├── [ 58 Aug 4 2018] boot.csv ├── [ 155 Aug 4 2018] grub.cfg ├── [1.1M Aug 4 2018] grub.efi ├── [124k Aug 4 2018] grubx64.efi └── [1.2M Aug 4 2018] shim.efi /boot/efi/EFI/opensuse_aux ├── [1.2M Aug 4 2018] MokManager.efi ├── [ 66 Aug 4 2018] boot.csv ├── [ 155 Aug 4 2018] grub.cfg ├── [1.1M Aug 4 2018] grub.efi ├── [124k Aug 4 2018] grubx64.efi └── [1.2M Aug 4 2018] shim.efi /boot/efi/EFI/opensuse_main ├── [1.2M May 9 14:12] MokManager.efi ├── [ 68 May 9 14:12] boot.csv ├── [ 155 May 9 14:12] grub.cfg ├── [1.1M May 9 14:12] grub.efi ├── [124k May 9 14:12] grubx64.efi └── [1.2M May 9 14:12] shim.efi
0 directories, 18 files Legolas:~ #
How did grub.cfg and the other files get there? I only have grubx64.efi and grub.cfg is in /boot/grub2 as before. After rebooting Leap, setting GRUB_DISTRIBUTOR="osleap" again and changing the timeout in the bootloader module, I now have this: steve@linux-tuxedo:~> tree /boot/efi/ /boot/efi/ `-- EFI |-- opensuse | `-- grubx64.efi |-- osleap | `-- grubx64.efi `-- ostw `-- grubx64.efi 4 directories, 3 files linux-tuxedo:~ # efibootmgr -v BootCurrent: 0001 Timeout: 1 seconds BootOrder: 0002,0001,0000 Boot0000* opensuse HD(1,GPT,b925e952-4899-46a4-b68a-40d92b7b9d34,0x800,0x100000)/File(\EFI\OPENSUSE\GRUBX64.EFI) Boot0001* ostw HD(1,GPT,b925e952-4899-46a4-b68a-40d92b7b9d34,0x800,0x100000)/File(\EFI\OSTW\GRUBX64.EFI) Boot0002* osleap HD(1,GPT,b925e952-4899-46a4-b68a-40d92b7b9d34,0x800,0x100000)/File(\EFI\osleap\grubx64.efi)
The "opensuse" directory is now an orphan, doesn't belong to any OS. Ie, yast created the new directory but did not delete the old - it had no way of knowing which one was the old, anyway, distributor was not changed inside yast.
Is there any reason not to manually delete the "opensuse" directory?
Also, although "Use graphical console" is checked in the Kernel Parameters tab of the bootloader module (and GRUB_TERMINAL="gfxterm" is in /etc/default/grub in both Leap and TW), the boot screen is in textmode. Other than that, I haven't noticed any problems.
I don't know about that :-?
You mean you have a graphical boot screen with GRUB2 for EFI? I wonder why I don't... Steve Berman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 16/05/2019 14.49, Stephen Berman wrote:
On Thu, 16 May 2019 12:12:52 +0200 "Carlos E. R." <robin.listas@gmx.es> wrote:
On 16/05/2019 11.38, Stephen Berman wrote: [...]
Maybe the setting was deleted because you changed to grub2 for efi and that is considered a major change, but perhaps it is a bug. I would try to set distributor again, and this time in yast only change the "timeout in seconds", which is a known trick to force yast to write again its files.
Ah, that worked!
linux-pjgr:~ # efibootmgr -v BootCurrent: 0000 Timeout: 1 seconds BootOrder: 0001,0000 Boot0000* opensuse HD(1,GPT,b925e952-4899-46a4-b68a-40d92b7b9d34,0x800,0x100000)/File(\EFI\OPENSUSE\GRUBX64.EFI) Boot0001* ostw HD(1,GPT,b925e952-4899-46a4-b68a-40d92b7b9d34,0x800,0x100000)/File(\EFI\ostw\grubx64.efi)
steve@linux-pjgr:~> tree /boot/efi/ /boot/efi/ `-- EFI |-- opensuse | `-- grubx64.efi `-- ostw `-- grubx64.efi
3 directories, 2 files
Good :-)
Carlos E. R. composed on 2019-05-15 21:56 (UTC+0200):
As described above, this didn't work for me, and no separate directories were created (where should they be, under /boot/efi ?); did I do something wrong? Do the directories need to be created manually?
No, yast creates them: [...] Legolas:~ # tree --si -D /boot/efi/EFI/opensuse* /boot/efi/EFI/opensuse ├── [1.2M Aug 4 2018] MokManager.efi ├── [ 58 Aug 4 2018] boot.csv ├── [ 155 Aug 4 2018] grub.cfg ├── [1.1M Aug 4 2018] grub.efi ├── [124k Aug 4 2018] grubx64.efi └── [1.2M Aug 4 2018] shim.efi /boot/efi/EFI/opensuse_aux ├── [1.2M Aug 4 2018] MokManager.efi ├── [ 66 Aug 4 2018] boot.csv ├── [ 155 Aug 4 2018] grub.cfg ├── [1.1M Aug 4 2018] grub.efi ├── [124k Aug 4 2018] grubx64.efi └── [1.2M Aug 4 2018] shim.efi /boot/efi/EFI/opensuse_main ├── [1.2M May 9 14:12] MokManager.efi ├── [ 68 May 9 14:12] boot.csv ├── [ 155 May 9 14:12] grub.cfg ├── [1.1M May 9 14:12] grub.efi ├── [124k May 9 14:12] grubx64.efi └── [1.2M May 9 14:12] shim.efi
0 directories, 18 files Legolas:~ #
How did grub.cfg and the other files get there? I only have grubx64.efi and grub.cfg is in /boot/grub2 as before.
I don't know. Not me, manually. Some command I have used, I don't remember which. YaST? Ah, I have shim. Perhaps you have disabled secure mode.
After rebooting Leap, setting GRUB_DISTRIBUTOR="osleap" again and changing the timeout in the bootloader module, I now have this:
steve@linux-tuxedo:~> tree /boot/efi/ /boot/efi/ `-- EFI |-- opensuse | `-- grubx64.efi |-- osleap | `-- grubx64.efi `-- ostw `-- grubx64.efi
4 directories, 3 files
Yep.
linux-tuxedo:~ # efibootmgr -v BootCurrent: 0001 Timeout: 1 seconds BootOrder: 0002,0001,0000 Boot0000* opensuse HD(1,GPT,b925e952-4899-46a4-b68a-40d92b7b9d34,0x800,0x100000)/File(\EFI\OPENSUSE\GRUBX64.EFI) Boot0001* ostw HD(1,GPT,b925e952-4899-46a4-b68a-40d92b7b9d34,0x800,0x100000)/File(\EFI\OSTW\GRUBX64.EFI) Boot0002* osleap HD(1,GPT,b925e952-4899-46a4-b68a-40d92b7b9d34,0x800,0x100000)/File(\EFI\osleap\grubx64.efi)
The "opensuse" directory is now an orphan, doesn't belong to any OS. Ie, yast created the new directory but did not delete the old - it had no way of knowing which one was the old, anyway, distributor was not changed inside yast.
Is there any reason not to manually delete the "opensuse" directory?
Procrastination? :-D Oh, just in case, till I'm sure it is not needed.
Also, although "Use graphical console" is checked in the Kernel Parameters tab of the bootloader module (and GRUB_TERMINAL="gfxterm" is in /etc/default/grub in both Leap and TW), the boot screen is in textmode. Other than that, I haven't noticed any problems.
I don't know about that :-?
You mean you have a graphical boot screen with GRUB2 for EFI? I wonder why I don't...
I don't boot this machine often, I don't remember. Grub must be in graphic mode, but then I remove plymouth and tell the kernel to boot in "splash=verbose" -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.0 (Legolas))
On Thu, 16 May 2019 15:16:48 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
Legolas:~ # tree --si -D /boot/efi/EFI/opensuse* /boot/efi/EFI/opensuse ├── [1.2M Aug 4 2018] MokManager.efi ├── [ 58 Aug 4 2018] boot.csv ├── [ 155 Aug 4 2018] grub.cfg ├── [1.1M Aug 4 2018] grub.efi ├── [124k Aug 4 2018] grubx64.efi └── [1.2M Aug 4 2018] shim.efi /boot/efi/EFI/opensuse_aux ├── [1.2M Aug 4 2018] MokManager.efi ├── [ 66 Aug 4 2018] boot.csv ├── [ 155 Aug 4 2018] grub.cfg ├── [1.1M Aug 4 2018] grub.efi ├── [124k Aug 4 2018] grubx64.efi └── [1.2M Aug 4 2018] shim.efi /boot/efi/EFI/opensuse_main ├── [1.2M May 9 14:12] MokManager.efi ├── [ 68 May 9 14:12] boot.csv ├── [ 155 May 9 14:12] grub.cfg ├── [1.1M May 9 14:12] grub.efi ├── [124k May 9 14:12] grubx64.efi └── [1.2M May 9 14:12] shim.efi
0 directories, 18 files Legolas:~ #
How did grub.cfg and the other files get there? I only have grubx64.efi and grub.cfg is in /boot/grub2 as before.
I don't know. Not me, manually. Some command I have used, I don't remember which. YaST?
Ah, I have shim. Perhaps you have disabled secure mode.
That's right. [...]
Is there any reason not to manually delete the "opensuse" directory?
Procrastination? :-D
Oh, just in case, till I'm sure it is not needed.
Better safe than sorry ;-)
Also, although "Use graphical console" is checked in the Kernel Parameters tab of the bootloader module (and GRUB_TERMINAL="gfxterm" is in /etc/default/grub in both Leap and TW), the boot screen is in textmode. Other than that, I haven't noticed any problems.
I don't know about that :-?
You mean you have a graphical boot screen with GRUB2 for EFI? I wonder why I don't...
I don't boot this machine often, I don't remember. Grub must be in graphic mode, but then I remove plymouth and tell the kernel to boot in "splash=verbose"
Hm, I didn't change anything in /etc/default/grub besides GRUB_DISTRIBUTOR, but in TW it also has this: GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/disk/by-uuid/b07a251e-a1c8-4d00-97be-d4e97099bf86 quiet mitigations=auto" whereas in Leap it's this: GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/disk/by-uuid/b07a251e-a1c8-4d00-97be-d4e97099bf86 splash=silent quiet showopts" Steve Berman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 16/05/2019 à 16:18, Stephen Berman a écrit :
Hm, I didn't change anything in /etc/default/grub besides GRUB_DISTRIBUTOR, but in TW it also has this:
I didn't read all this (very long) thread, so forgive me if this was already said. I have an EFI Leap 15 install that can be booted both in UEFI mode, with grub-efi from this very install, but also with grub2 (non efi), from an other, rescue, leap 15 install. my computer (Dell Vostro 3360 with HDD and msata) allows me to change boot mode from the boot menu (F12). like this, it's very difficult to know how the current running was booted: I have the efi partition mounted on every mode, as it's mounted from fstab :-) jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 16/05/2019 16.18, Stephen Berman wrote:
On Thu, 16 May 2019 15:16:48 +0200 "Carlos E. R." <> wrote:
...
I don't know about that :-?
You mean you have a graphical boot screen with GRUB2 for EFI? I wonder why I don't...
I don't boot this machine often, I don't remember. Grub must be in graphic mode, but then I remove plymouth and tell the kernel to boot in "splash=verbose"
Hm, I didn't change anything in /etc/default/grub besides GRUB_DISTRIBUTOR, but in TW it also has this:
GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/disk/by-uuid/b07a251e-a1c8-4d00-97be-d4e97099bf86 quiet mitigations=auto"
whereas in Leap it's this:
GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/disk/by-uuid/b07a251e-a1c8-4d00-97be-d4e97099bf86 splash=silent quiet showopts"
I don't know what mitigations is for, but besides that the line is typical. What I said is that I remove "quiet" and change "silent" with "verbose", which makes the boot proceed with hundreds of lines with text from the kernel. But grub itself is in graphic mode. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.0 (Legolas))
On Thu, 16 May 2019 17:22:27 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 16/05/2019 16.18, Stephen Berman wrote:
On Thu, 16 May 2019 15:16:48 +0200 "Carlos E. R." <> wrote:
...
I don't know about that :-?
You mean you have a graphical boot screen with GRUB2 for EFI? I wonder why I don't...
I don't boot this machine often, I don't remember. Grub must be in graphic mode, but then I remove plymouth and tell the kernel to boot in "splash=verbose"
Hm, I didn't change anything in /etc/default/grub besides GRUB_DISTRIBUTOR, but in TW it also has this:
GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/disk/by-uuid/b07a251e-a1c8-4d00-97be-d4e97099bf86 quiet mitigations=auto"
whereas in Leap it's this:
GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/disk/by-uuid/b07a251e-a1c8-4d00-97be-d4e97099bf86 splash=silent quiet showopts"
I don't know what mitigations is for, but besides that the line is typical. What I said is that I remove "quiet" and change "silent" with "verbose", which makes the boot proceed with hundreds of lines with text from the kernel.
But grub itself is in graphic mode.
On Thu, 16 May 2019 18:12:31 -0400 Felix Miata <mrmazda@earthlink.net> wrote:
Stephen Berman composed on 2019-05-11 19:58 (UTC+0200): ... (I decided to provide the following based upon reading the thread since my prior thread post over 12 hours ago.)
Grub menu on my Kaby Lake Gigabyte PC: http://fm.no-ip.com/SS/Suse/gmenu-TW.jpg
Did you change a setting to disable the graphical menu? If not, I wonder if changing GRUB_DISTRIBUTOR somehow does that, because that seems to have been the result after I changed that. (But Carlos you also set GRUB_DISTRIBUTOR but have the graphical menu, right? Hmm.) In any case, although thanks to the help from both of you I got TW booting in UEFI without reinstalling it, I decided in the end to do a reinstallation, not only to see if it would make a difference but also because I wanted to adjust the partition scheme a bit. The installation went without a hitch, the only change I made to the generated bootloader settings was to uncheck secure boot. As Felix has noted, I could not set GRUB_DISTRIBUTOR during installation, and indeed it is unset, but the GRUB2 boot menu is graphical. For now I'll leave the TW bootloader settings alone, but at some point I'll probably change them, and then it will be interesting to see if that affects the boot menu display. I want to thank both of you again for all the feedback and advice; I've learned a lot! Steve Berman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I noticed when archiving mail that I had marked this post for replying, but that I never did. Maybe I wanted to verify something later and forgot. On Friday, 2019-05-17 at 10:48 +0200, Stephen Berman wrote:
On Thu, 16 May 2019 17:22:27 +0200 "Carlos E. R." <...> wrote:
On 16/05/2019 16.18, Stephen Berman wrote:
On Thu, 16 May 2019 15:16:48 +0200 "Carlos E. R." <> wrote:
...
I don't know about that :-?
You mean you have a graphical boot screen with GRUB2 for EFI? I wonder why I don't...
I don't boot this machine often, I don't remember. Grub must be in graphic mode, but then I remove plymouth and tell the kernel to boot in "splash=verbose"
Hm, I didn't change anything in /etc/default/grub besides GRUB_DISTRIBUTOR, but in TW it also has this:
GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/disk/by-uuid/b07a251e-a1c8-4d00-97be-d4e97099bf86 quiet mitigations=auto"
whereas in Leap it's this:
GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/disk/by-uuid/b07a251e-a1c8-4d00-97be-d4e97099bf86 splash=silent quiet showopts"
I don't know what mitigations is for, but besides that the line is typical. What I said is that I remove "quiet" and change "silent" with "verbose", which makes the boot proceed with hundreds of lines with text from the kernel.
But grub itself is in graphic mode.
On Thu, 16 May 2019 18:12:31 -0400 Felix Miata <...> wrote:
Stephen Berman composed on 2019-05-11 19:58 (UTC+0200): ... (I decided to provide the following based upon reading the thread since my prior thread post over 12 hours ago.)
Grub menu on my Kaby Lake Gigabyte PC: http://fm.no-ip.com/SS/Suse/gmenu-TW.jpg
Did you change a setting to disable the graphical menu? If not, I wonder if changing GRUB_DISTRIBUTOR somehow does that, because that seems to have been the result after I changed that. (But Carlos you also set GRUB_DISTRIBUTOR but have the graphical menu, right? Hmm.)
Yes, I have, on this machine, which has several boots installed: GRUB_DISTRIBUTOR="Main_openSUSE" so when the Grub menu displays (in graphical mode, yes) I see which menu it is.
In any case, although thanks to the help from both of you I got TW booting in UEFI without reinstalling it, I decided in the end to do a reinstallation, not only to see if it would make a difference but also because I wanted to adjust the partition scheme a bit. The installation went without a hitch, the only change I made to the generated bootloader settings was to uncheck secure boot. As Felix has noted, I could not set GRUB_DISTRIBUTOR during installation, and indeed it is unset, but the GRUB2 boot menu is graphical. For now I'll leave the TW bootloader settings alone, but at some point I'll probably change them, and then it will be interesting to see if that affects the boot menu display.
I want to thank both of you again for all the feedback and advice; I've learned a lot!
:-) - -- Cheers, Carlos E. R. (from openSUSE 15.0 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXSCUaxwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVflEAoIaXffMEfKOrI9jeANAc G+MQjlsxAJ4lnHXX9Q3eSWwBVuNoz6DGb5zM5A== =o5Td -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Отправлено с iPhone
I changed Leap's GRUB_DISTRIBUTOR to 'osleap', ran grub2-mkconfig as the comment in /etc/default/grub recommends, then rebooted, and the boot screen showed 'osleap' instead of 'openSUSE Leap 15.0' and also 'openSUSE Tumbleweed'. I booted into TW...
grub-mkconfig only recreates grub.cfg. It does not reinstall grub in new location determined by GRUB_DISTRIBUTOR. You need grub2-install or (SUSE specific) “update-bootloader —reinit”. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, 16 May 2019 15:19:27 +0300 Andrei Borzenkov <arvidjaar@gmail.com> wrote:
Отправлено с iPhone
I changed Leap's GRUB_DISTRIBUTOR to 'osleap', ran grub2-mkconfig as the comment in /etc/default/grub recommends, then rebooted, and the boot screen showed 'osleap' instead of 'openSUSE Leap 15.0' and also 'openSUSE Tumbleweed'. I booted into TW...
grub-mkconfig only recreates grub.cfg. It does not reinstall grub in new location determined by GRUB_DISTRIBUTOR. You need grub2-install or (SUSE specific) “update-bootloader —reinit”.
Right, and I assume that is done by the YaST bootloader module, though, as reported in a followup to Carlos, it required first switching to GRUB2 for EFI, then setting GRUB_DISTRIBUTOR again, then running the bootloader module again. Steve Berman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Stephen Berman composed on 2019-05-15 21:29 (UTC+0200):
The output of efibootmgr when CSM is enabled in the BIOS is different from the output when CSM is disabled (i.e. UEFI only). Originally, and when I installed TW, CSM was enabled, but in preparation for reinstallation using pure EFI I disabled it, and this is what efibootmgr now outputs:
BootCurrent: 0000 Timeout: 1 seconds BootOrder: 0000 Boot0000* opensuse
Unless you change Leap's GRUB_DISTRIBUTOR= first, you'll still have only one opensuse entry after reinstalling TW in UEFI mode.
Perhaps I've been mistaken in asserting there is a /boot partition. This is what ls -l /boot shows:
You clearly have been. A historically good way to tell is by viewing fstab, not /boot/ content. If using btrfs, it may not be so clear. Another way is to try to run 'umount /boot'. It will fail if there is no separate filesystem mounted to /boot/.
Is it possible that only the efi directory is a separate partition, mounted under /boot, and /boot itself and the rest of its contents are in the root partition?
This is quite clearly the normal case. Separate /boot partitions are typically used for LVM and/or RAID installations and/or various encryption configurations, and few others.
If that is the case, perhaps I can keep the Leap installation, and just reinstall TW, now in pure UEFI.
Having the ESP partition mounted to /boot/efi/ in fstab I find it hard to understand that there would be any need to reinstall to ensure TW is only used in UEFI mode. If it was here, first thing I would try is changing TW's GRUB_DISTRIBUTOR= to something unique, then running yast bootloader, changing the timeout, exiting, and rebooting, all assuming in your TW you see the following: # rpm -qa | egrep -i 'grub|prober' grub2-2.02-43.1.x86_64 grub2-i386-pc-2.02-43.1.noarch grub2-x86_64-efi-2.02-43.1.noarch os-prober-1.76-5.1.x86_64 ruby2.6-rubygem-cfa_grub2-1.0.1-1.3.x86_64 -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Stephen Berman composed on 2019-05-12 16:29 (UTC+0200):
On Sun, 12 May 2019 01:55:06 -0400 Felix Miata wrote:
I work around that potential problem with an fstab alteration. I comment the line that would mount the ESP partition in every installation except the one I want in ^^^ Do you mean "EFI" here? If not, what is the ESP partition?
https://en.wikipedia.org/wiki/EFI_system_partition -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, 12 May 2019 16:55:02 -0400 Felix Miata <mrmazda@earthlink.net> wrote:
Stephen Berman composed on 2019-05-12 16:29 (UTC+0200):
On Sun, 12 May 2019 01:55:06 -0400 Felix Miata wrote:
I work around that potential problem with an fstab alteration. I comment the line that would mount the ESP partition in every installation except the one I want in ^^^ Do you mean "EFI" here? If not, what is the ESP partition?
Yes, thanks (I also found it after posting). Steve Berman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/05/2019 22.55, Felix Miata wrote:
Stephen Berman composed on 2019-05-12 16:29 (UTC+0200):
On Sun, 12 May 2019 01:55:06 -0400 Felix Miata wrote:
I work around that potential problem with an fstab alteration. I comment the line that would mount the ESP partition in every installation except the one I want in ^^^ Do you mean "EFI" here? If not, what is the ESP partition?
I do not see what ESP is anagram for :-? -- Cheers / Saludos, Carlos E. R. (from openSUSE, Leap 15.1 x86_64 (ssd-test)) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 13 May 2019 12:06:09 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 12/05/2019 22.55, Felix Miata wrote:
Stephen Berman composed on 2019-05-12 16:29 (UTC+0200):
On Sun, 12 May 2019 01:55:06 -0400 Felix Miata wrote:
I work around that potential problem with an fstab alteration. I comment the line that would mount the ESP partition in every installation except the one I want in ^^^ Do you mean "EFI" here? If not, what is the ESP partition?
I do not see what ESP is anagram for :-?
That's 'acronym' rather than 'anagram' I hope :) Does 'Efi System Partition' help clarify? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 13/05/2019 12.57, Dave Howorth wrote:
On Mon, 13 May 2019 12:06:09 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 12/05/2019 22.55, Felix Miata wrote:
Stephen Berman composed on 2019-05-12 16:29 (UTC+0200):
On Sun, 12 May 2019 01:55:06 -0400 Felix Miata wrote:
I work around that potential problem with an fstab alteration. I comment the line that would mount the ESP partition in every installation except the one I want in ^^^ Do you mean "EFI" here? If not, what is the ESP partition?
I do not see what ESP is anagram for :-?
That's 'acronym' rather than 'anagram' I hope :)
Oops, yes.
Does 'Efi System Partition' help clarify?
Ah! :-) -- Cheers / Saludos, Carlos E. R. (from openSUSE, Leap 15.1 x86_64 (ssd-test)) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, 11 May 2019 20:11:25 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 11/05/2019 19.58, Stephen Berman wrote:
I bought a computer with Leap 15.0 preinstalled on an SSD,
New, from a shop? What brand/model? I'm curious, selling Linux preinstalled is rare.
New, from https://www.tuxedocomputers.com
and I also wanted to install Tumbleweed on the disk. For reasons detailed below, I did this without installing a bootloader for Tumbleweed, but since Tumbleweed is frequently updated, including grub2, I think it would be better to install the bootloader in Tumbleweed. Due to my lack of knowledge, I would be grateful for advice on how to do that safely. Some specifics follow about the disk and what I did to install Tumbleweed.
The SSD had three partitions: /boot, / (root) and swap. I shrank the root partition (formatted as ext4) and added a btrfs partition for Tumbleweed. I first left /boot and swap as is, but the Tumbleweed installer said there was no bootable partition (I don't remember the exact wording, something like no BIOS boot table). I then tried deleting the /boot partition and adding it again, selecting "BIOS Boot" as the partition ID, but the installer still said there was no bootable partition. I also tried different file systems to format /boot -- originally it was FAT and I also tried XFS and ext3 -- but that made no difference.
It is *another* partition. Very small, perhaps 8 megabytes.
I'm not sure what you're referring to; there were definitely only the three partitions I listed, and the size of the /boot partition was (and still is) 500 MB (out of a 500 GB disk).
Why didn't you ask here before doing changes?
As I wrote, I only changed the root partition, not the /boot partition. In hindsight, I should have asked here before even attempting the installation, since, while I've installed GNU/Linux (and in particular (open)SUSE) systems for many years, this is the first time I'm using a separate boot partition (also the first time I'm using a GPT disk). Nevertheless, when I encountered the boot loader problem I decided to forge ahead (without changing /boot), hoping that in the worst case, I would just be able to go back to where I started from. And as far as I can tell, that still seems to be an option. But if I do that, I hope someone can tell me either how to install the bootloader for Tumbleweed in the existing /boot partition or how to make a /boot partition that the Tumbleweed installer recognizes. This must be possible, because if I let the installer suggest a partition scheme, it does suggest a separate /boot partition; however, that scheme would have overwritten the Leap 15.0 installation. AFAICT the only way to avoid that was to manually partition the disk, but as described, when I did that the installer said there was no bootable partition.
So finally, I left the /boot partition unchanged but unmounted it and proceeded with the installation. At the summary I then changed the boot setup to prevent any boot loader being installed and any changes made to the MBR. The installer said I might end up with an unbootable system, but I went ahead anyway. The installation completed and on rebooting the boot screen showed only Leap 15.0 as before, but after running grub2-mkconfig in Leap, Tumbleweed was found and I could boot it and it seems to be fine.
The disk has GPT with protective MBR. As noted the /boot partition is formatted as FAT and also contains a directory efi, which is populated in the running Leap, which mounts /boot/efi,
Well, first step would be to recover the original.
Again, the /boot partition is unchanged.
but in the running Tumbleweed, where /boot is not a separate partition, after mounting the partition Leap sees as /boot/efi, the efi directory is empty (in the running Tumbleweed). I do not plan to install any MS-Windows system, but I do plan to install other Linux-based systems besides Tumbleweed, and possibly a *BSD system. How can I install the bootloader in Tumbleweed -- either from the currently installed Tumbleweed or by reinstalling it -- without risking making both Tumbleweed and Leap unbootable? If that requires deleting the existing /boot partition and add it anew, is it necessary, given the systems I plan to install, to have the efi directory, and if so, do I just have to make /boot/efi a mountpoint, and if not, what else to I need to do to make sure it exists and gets populated as required (if it's required)? And if the efi directory is not needed, what would be the recommended file system for the boot partition?
Please run this script after booting into openSUSE and post results to 'SUSE Paste' (http://susepaste.org/)
https://github.com/arvidjaar/bootinfoscript/raw/master/bootinfoscript
This script does not recognize the disk containing the /boot partition (it searches for device names beginning with hd, sd, vd or xvd, but my SSD is at /dev/nvme0n1). Steve Berman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/05/2019 00.50, Stephen Berman wrote:
On Sat, 11 May 2019 20:11:25 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
The SSD had three partitions: /boot, / (root) and swap. I shrank the root partition (formatted as ext4) and added a btrfs partition for Tumbleweed. I first left /boot and swap as is, but the Tumbleweed installer said there was no bootable partition (I don't remember the exact wording, something like no BIOS boot table). I then tried deleting the /boot partition and adding it again, selecting "BIOS Boot" as the partition ID, but the installer still said there was no bootable partition. I also tried different file systems to format /boot -- originally it was FAT and I also tried XFS and ext3 -- but that made no difference.
It is *another* partition. Very small, perhaps 8 megabytes.
I'm not sure what you're referring to; there were definitely only the three partitions I listed, and the size of the /boot partition was (and still is) 500 MB (out of a 500 GB disk).
I refer to the fact that the installation was telling you to create the bios_grub, which is neither /boot nor EFI. It is *another* partition. 8 or 15 mega bytes.
Why didn't you ask here before doing changes?
As I wrote, I only changed the root partition, not the /boot partition. In hindsight, I should have asked here before even attempting the installation, since, while I've installed GNU/Linux (and in particular (open)SUSE) systems for many years, this is the first time I'm using a separate boot partition (also the first time I'm using a GPT disk). Nevertheless, when I encountered the boot loader problem I decided to forge ahead (without changing /boot), hoping that in the worst case, I would just be able to go back to where I started from. And as far as I can tell, that still seems to be an option.
But if I do that, I hope someone can tell me either how to install the bootloader for Tumbleweed in the existing /boot partition or how to make a /boot partition that the Tumbleweed installer recognizes. This must be possible, because if I let the installer suggest a partition scheme, it does suggest a separate /boot partition; however, that scheme would have overwritten the Leap 15.0 installation. AFAICT the only way to avoid that was to manually partition the disk, but as described, when I did that the installer said there was no bootable partition.
We first must know the exact current status, as told by the script I told you to run.
So finally, I left the /boot partition unchanged but unmounted it and proceeded with the installation. At the summary I then changed the boot setup to prevent any boot loader being installed and any changes made to the MBR. The installer said I might end up with an unbootable system, but I went ahead anyway. The installation completed and on rebooting the boot screen showed only Leap 15.0 as before, but after running grub2-mkconfig in Leap, Tumbleweed was found and I could boot it and it seems to be fine.
The disk has GPT with protective MBR. As noted the /boot partition is formatted as FAT and also contains a directory efi, which is populated in the running Leap, which mounts /boot/efi,
Well, first step would be to recover the original.
Again, the /boot partition is unchanged.
You said that /boot is formatted as FAT. This is impossible, can not work and you must restore the original from backup. Unless you are mistaken and talking about /boot/EFI, which is type FAT.
Please run this script after booting into openSUSE and post results to 'SUSE Paste' (http://susepaste.org/)
https://github.com/arvidjaar/bootinfoscript/raw/master/bootinfoscript
This script does not recognize the disk containing the /boot partition (it searches for device names beginning with hd, sd, vd or xvd, but my SSD is at /dev/nvme0n1).
Nevertheless, please run it and upload the result. If it fails, I'm sure arvidjaar will be very interested and will give you further instructions. So, please paste the exact errors you get here. -- Cheers / Saludos, Carlos E. R. (from openSUSE, Leap 15.1 x86_64 (ssd-test)) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, 12 May 2019 02:31:59 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 12/05/2019 00.50, Stephen Berman wrote:
On Sat, 11 May 2019 20:11:25 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
The SSD had three partitions: /boot, / (root) and swap. I shrank the root partition (formatted as ext4) and added a btrfs partition for Tumbleweed. I first left /boot and swap as is, but the Tumbleweed installer said there was no bootable partition (I don't remember the exact wording, something like no BIOS boot table). I then tried deleting the /boot partition and adding it again, selecting "BIOS Boot" as the partition ID, but the installer still said there was no bootable partition. I also tried different file systems to format /boot -- originally it was FAT and I also tried XFS and ext3 -- but that made no difference.
It is *another* partition. Very small, perhaps 8 megabytes.
I'm not sure what you're referring to; there were definitely only the three partitions I listed, and the size of the /boot partition was (and still is) 500 MB (out of a 500 GB disk).
I refer to the fact that the installation was telling you to create the bios_grub, which is neither /boot nor EFI. It is *another* partition. 8 or 15 mega bytes.
Ah, ok. I think this is what the installer suggested as a partitioning scheme, which would have overwritten the Leap 15.0 installation (see below). I didn't see any way to manually add that partition. But from Felix Miata's reply it seems it should not be needed anyway if booting uses UEFI.
Why didn't you ask here before doing changes?
As I wrote, I only changed the root partition, not the /boot partition. In hindsight, I should have asked here before even attempting the installation, since, while I've installed GNU/Linux (and in particular (open)SUSE) systems for many years, this is the first time I'm using a separate boot partition (also the first time I'm using a GPT disk). Nevertheless, when I encountered the boot loader problem I decided to forge ahead (without changing /boot), hoping that in the worst case, I would just be able to go back to where I started from. And as far as I can tell, that still seems to be an option.
But if I do that, I hope someone can tell me either how to install the bootloader for Tumbleweed in the existing /boot partition or how to make a /boot partition that the Tumbleweed installer recognizes. This must be possible, because if I let the installer suggest a partition scheme, it does suggest a separate /boot partition; however, that scheme would have overwritten the Leap 15.0 installation. AFAICT the only way to avoid that was to manually partition the disk, but as described, when I did that the installer said there was no bootable partition.
We first must know the exact current status, as told by the script I told you to run.
See below.
So finally, I left the /boot partition unchanged but unmounted it and proceeded with the installation. At the summary I then changed the boot setup to prevent any boot loader being installed and any changes made to the MBR. The installer said I might end up with an unbootable system, but I went ahead anyway. The installation completed and on rebooting the boot screen showed only Leap 15.0 as before, but after running grub2-mkconfig in Leap, Tumbleweed was found and I could boot it and it seems to be fine.
The disk has GPT with protective MBR. As noted the /boot partition is formatted as FAT and also contains a directory efi, which is populated in the running Leap, which mounts /boot/efi,
Well, first step would be to recover the original.
Again, the /boot partition is unchanged.
You said that /boot is formatted as FAT. This is impossible, can not work and you must restore the original from backup. Unless you are mistaken and talking about /boot/EFI, which is type FAT.
As I wrote, /boot/efi is a mount point in the Leap installation, but AFAICT the entire /boot partition is formatted as FAT, and the output I uploaded at your request (see below) appears to confirm that.
Please run this script after booting into openSUSE and post results to 'SUSE Paste' (http://susepaste.org/)
https://github.com/arvidjaar/bootinfoscript/raw/master/bootinfoscript
This script does not recognize the disk containing the /boot partition (it searches for device names beginning with hd, sd, vd or xvd, but my SSD is at /dev/nvme0n1).
Nevertheless, please run it and upload the result.
If it fails, I'm sure arvidjaar will be very interested and will give you further instructions. So, please paste the exact errors you get here.
See http://susepaste.org/33902084 and http://susepaste.org/89683428 The first URL contains the results obtained with the the updated script Andrei Borzenkov pointed me to; as I noted in my followup to him, this is still erroneous, but a slight modification to the script improved the results (but only partly), and these are contained at the second URL. Three parts of the results (the first two are only in the improved results) stick out to me, and I wonder if they indicate a problem. The Boot Info Summary contains this: nvme0n1p1: _____________________________________________________________________ File system: vfat Boot sector type: FAT32 Boot sector info: According to the info in the boot sector, nvme0n1p1 starts at sector 2048. But according to the info from fdisk, nvme0n1p1 starts at sector 0. Operating System: Boot files: /efi/opensuse/grubx64.efi nvme0n1p2: _____________________________________________________________________ File system: ext4 Boot sector type: Grub2 (v1.99-2.00) Boot sector info: Grub2 (v1.99-2.00) is installed in the boot sector of nvme0n1p2 and looks at sector 19884200 of the same hard drive for core.img, but core.img can not be found at this location. Operating System: openSUSE Leap 15.0 Boot files: /boot/grub2/grub.cfg /etc/fstab /boot/grub2/i386-pc/core.img and the Drive/Partition Info contains this: Drive: nvme0n1 _____________________________________________________________________ Disk /dev/nvme0n1: 465.8 GiB, 500107862016 bytes, 976773168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Partition Boot Start Sector End Sector # of Sectors Id System /dev/nvme0n1p1 1 976,773,167 976,773,167 ee GPT GUID Partition Table detected. Partition Attrs Start Sector End Sector # of Sectors System /dev/nvme0n11 2,048 1,050,623 1,048,576 Data partition (Windows/Linux) /dev/nvme0n12 B 1,050,624 214,042,623 212,992,000 Data partition (Linux) [...] Attributes: R=Required, N=No Block IO, B=Legacy BIOS Bootable, +=More bits set IIUC these say that the partition nvme0n1p2 (which the script misidentifies as nvme0n12 is the partition table), which is the root partition of the Leap 15.0 installation, was made legacy BIOS bootable. Does this conflict with, or override, booting with EFI from the /boot (or /boot/efi) partition nvme0n1p1? If this was not in the original installation, then it could only have resulted from my running grub2-mkconfig in Leap after installing TW, in order to make the latter appear in the boot menu. Was it a mistake to run grub2-mkconfig? If so, how can I repair it? (Note I did not run grub2-install.) My current plan, unless I get urgent advice to the contrary, is to reinstall TW and try to use GRUB2 for EFI. Steve Berman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
12.05.2019 17:28, Stephen Berman пишет:
GUID Partition Table detected.
Partition Attrs Start Sector End Sector # of Sectors System /dev/nvme0n11 2,048 1,050,623 1,048,576 Data partition (Windows/Linux) /dev/nvme0n12 B 1,050,624 214,042,623 212,992,000 Data partition (Linux) [...] Attributes: R=Required, N=No Block IO, B=Legacy BIOS Bootable, +=More bits set
IIUC these say that the partition nvme0n1p2 (which the script misidentifies as nvme0n12 is the partition table), which is the root partition of the Leap 15.0 installation, was made legacy BIOS bootable. Does this conflict with, or override, booting with EFI from the /boot (or /boot/efi) partition nvme0n1p1?
No. I am aware of the only bootloader that interprets this bit - Syslinux GPT MBR, which is legacy MBR code for disk with GPT. native EFI mode should not care about this flag. This allows in principle booting the same installation alternatively using legacy BIOS or native EFI. Linux should boot in either mode.
If this was not in the original installation, then it could only have resulted from my running grub2-mkconfig in Leap after installing TW, in order to make the latter appear in the boot menu.
grub2-mkconfig never fiddles with partition table, nor does grub2-install. Thus is result of choosing "Write generic Boot Code to MBR" and "Boot from Partition" during installation. The installer writes Syslinux GPTMBR into MBR and marks partition that contains /boot as bootable.
Was it a mistake to run grub2-mkconfig? If so, how can I repair it?
There is nothing to repair.
(Note I did not run grub2-install.)
My current plan, unless I get urgent advice to the contrary, is to reinstall TW and try to use GRUB2 for EFI.
Steve Berman
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, 12 May 2019 17:49:33 +0300 Andrei Borzenkov <arvidjaar@gmail.com> wrote:
12.05.2019 17:28, Stephen Berman пишет:
GUID Partition Table detected.
Partition Attrs Start Sector End Sector # of Sectors System /dev/nvme0n11 2,048 1,050,623 1,048,576 Data partition (Windows/Linux) /dev/nvme0n12 B 1,050,624 214,042,623 212,992,000 Data partition (Linux) [...] Attributes: R=Required, N=No Block IO, B=Legacy BIOS Bootable, +=More bits set
IIUC these say that the partition nvme0n1p2 (which the script misidentifies as nvme0n12 is the partition table), which is the root partition of the Leap 15.0 installation, was made legacy BIOS bootable. Does this conflict with, or override, booting with EFI from the /boot (or /boot/efi) partition nvme0n1p1?
No. I am aware of the only bootloader that interprets this bit - Syslinux GPT MBR, which is legacy MBR code for disk with GPT. native EFI mode should not care about this flag.
This allows in principle booting the same installation alternatively using legacy BIOS or native EFI. Linux should boot in either mode.
Ah, ok.
If this was not in the original installation, then it could only have resulted from my running grub2-mkconfig in Leap after installing TW, in order to make the latter appear in the boot menu.
grub2-mkconfig never fiddles with partition table, nor does grub2-install. Thus is result of choosing "Write generic Boot Code to MBR" and "Boot from Partition" during installation. The installer writes Syslinux GPTMBR into MBR and marks partition that contains /boot as bootable.
Thanks for the explanation. Those boot settings were there in the original Leap installation, before I repartioned the root (not boot!) partition.
Was it a mistake to run grub2-mkconfig? If so, how can I repair it?
There is nothing to repair.
That's a relief!
(Note I did not run grub2-install.)
My current plan, unless I get urgent advice to the contrary, is to reinstall TW and try to use GRUB2 for EFI.
Do you think this is a good plan? (The reason I want to reinstall rather than change the boot loader settings in the installed TW is that when I repartioned the disk, I left swap, which was the third partition at the end of the disk, unchanged, so now partitions 4-9 are before partition 3.) Steve Berman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
12.05.2019 1:50, Stephen Berman пишет:
https://github.com/arvidjaar/bootinfoscript/raw/master/bootinfoscript
This script does not recognize the disk containing the /boot partition (it searches for device names beginning with hd, sd, vd or xvd, but my SSD is at /dev/nvme0n1).
Sorry, still have not got around to fix it, you can try this pull request: https://github.com/arvidjaar/bootinfoscript/raw/2f72a7408b24d6a04a9fad626e52... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, 12 May 2019 07:59:25 +0300 Andrei Borzenkov <arvidjaar@gmail.com> wrote:
12.05.2019 1:50, Stephen Berman пишет:
https://github.com/arvidjaar/bootinfoscript/raw/master/bootinfoscript
This script does not recognize the disk containing the /boot partition (it searches for device names beginning with hd, sd, vd or xvd, but my SSD is at /dev/nvme0n1).
Sorry, still have not got around to fix it, you can try this pull request:
https://github.com/arvidjaar/bootinfoscript/raw/2f72a7408b24d6a04a9fad626e52...
Thanks. This still has a problem: it lists the partition of nvme0n1 as nvme0n11, nvme0n12, etc., instead of the correct nvme0n1p1, nvme0n1p2, etc. (see http://susepaste.org/33902084). By changing this line of the script: All_Hard_Drives=$(ls /dev/hd[a-z] /dev/hd[a-z][a-z] /dev/sd[a-z] /dev/sd[a-z][a-z] /dev/xvd[a-z] /dev/vd[a-z] /dev/vd[a-z][a-z] /dev/nvme[0-9]n[0-9] /dev/nvme[0-9]n[0-9][0-9] /dev/nvme[0-9][0-9]n[0-9] /dev/nvme[0-9][0-9]n[0-9][0-9] 2>> ${Trash}); to this: All_Hard_Drives=$(ls /dev/hd[a-z] /dev/hd[a-z][a-z] /dev/sd[a-z] /dev/sd[a-z][a-z] /dev/xvd[a-z] /dev/vd[a-z] /dev/vd[a-z][a-z] /dev/nvme[0-9]n[0-9] /dev/nvme[0-9]n[0-9]p[0-9] 2>> ${Trash}); the results show boot info for the partitions nvme0n1p1 and nvme0n1p2, though the partition table output under "Drive/Partition Info" still incorrectly lists nvme0n11, nvme0n12, etc. (see http://susepaste.org/89683428). (Note that both with and without that change the script correctly shows nvme0n1p1 etc. in the "blkid" output.) Steve Berman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Stephen Berman composed on 2019-05-11 19:58 (UTC+0200): ... (I decided to provide the following based upon reading the thread since my prior thread post over 12 hours ago.) Grub menu on my Kaby Lake Gigabyte PC: http://fm.no-ip.com/SS/Suse/gmenu-TW.jpg Its last two selections are those produced by TW's bootloader management system: first its default as configured via GRUB_DISTRIBUTOR="opensusetw" in /etc/default/grub, followed by its submenu selection generated with GRUB_DISABLE_OS_PROBER="true". It's color scheme IIRC is via /etc/grub.d/05_text_colors (timestamp October 2018): #!/bin/sh exec tail -n +3 $0 set menu_color_normal=cyan/blue set menu_color_highlight=white/blue Redacted /boot/grub2/custom.cfg responsible for all except its last two selections: http://fm.no-ip.com/Share/Linux/custom-template2.cfg Content of /EFI/ on mounted ESP partition (sda1): BOOT debian10 debian1002 opensuse opensuse01 opensusetw opensusetw01 opensusetw02 tubuntu tubuntu02 tubuntu03 ubuntu01 Output from efibootmgr: BootCurrent: 0000 Timeout: 1 seconds BootOrder: 0000,0007,000C,000D Boot0000* opensusetw Boot0007* Hard Drive Boot0009 CD/DVD Drive Boot000C* CD/DVD Drive Boot000D opensuse Motherboard's AMI BIOS date: 2018-04-10 -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (8)
-
Andrei Borzenkov -
Carlos E. R. -
Carlos E. R. -
Dave Howorth -
Felix Miata -
jdd＠dodin.org -
Knurpht-openSUSE -
Stephen Berman