Leap 42.3 and Grub 2 Mess

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Leap 42.3 and Grub 2 Mess

Robin Klitscher-2
This is a multi-boot machine with several versions of openSUSE and
Windows 7.  Four hard drives partitioned appropriately, legacy BIOS, not
UEFI.

To install Leap 42.3 I did what has worked for me successfully for more
than ten years - cleared space by formatting where an older version had
been and installing afresh in those spaces, with Grub2 in the MBR.

This time it didn't work.  Or, more accurately, Grub 2 doesn't work.  I
can boot into any of the systems using a Super Grub 2 CDROM, so the
installation(s) themselves work OK, but that external boot procedure
becomes a pain in the backside.

When I try to boot direct from the hard drive(s) I get the following:

error: no such device: <a partition UUID number>
Entering rescue mode
grub rescue>

The first line means what it says.  Booting to any of the systems and
running blkid shows that the UUID cited in the error message doesn't
exist on the system.  I've no idea how it got there, but it did.

I can make available the results of bootinfoscript, but that might not
be necessary.  It appears to confirm that Grub2 is expecting to find its
files at the same non-existent UUID as in the error message above.  The
question seems to be, therefore, is there a way of pointing Grub2 at a
valid UUID; and if so, how can I do this?





--
Robin K
Wellington "Harbour City"
New Zealand

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Leap 42.3 and Grub 2 Mess

Carl Hartung-2
On Sat, 12 Aug 2017 13:41:29 +1200
Robin Klitscher wrote:

Hi Robin,

Comments interspersed ...

> This is a multi-boot machine with several versions of openSUSE and
> Windows 7.  Four hard drives partitioned appropriately, legacy BIOS,
> not UEFI.
8< - - - - - trimmed - - - - - >8
> I can boot into any of the systems using a Super Grub 2 CDROM, so the
> installation(s) themselves work OK, but that external boot procedure
> becomes a pain in the backside.

This is very good news because this means it should be an easy fix.

> When I try to boot direct from the hard drive(s) I get the following:
>
> error: no such device: <a partition UUID number>
> Entering rescue mode
> grub rescue>
>
> The first line means what it says.  Booting to any of the systems and
> running blkid shows that the UUID cited in the error message doesn't
> exist on the system.  I've no idea how it got there, but it did.

Formatted partitions get new UUIDs which are not recognized by the
failing (stale configuration) grub installation(s.)

> I can make available the results of bootinfoscript, but that might not
> be necessary.  It appears to confirm that Grub2 is expecting to find
> its files at the same non-existent UUID as in the error message
> above.  The question seems to be, therefore, is there a way of
> pointing Grub2 at a valid UUID; and if so, how can I do this?

Boot into 42.3 using your Super Grub 2 CD-ROM, switch to VT-1
(Ctrl+Alt+F1) and 'su -' to become superuser. Assuming you want to
reinstall grub(2) on the openSUSE 42.3 '/' partition, and, assuming that
partition maps to /dev/sda1, you would invoke the following:

# grub2-install /dev/sda1
# grub2-mkconfig -o /boot/grub2/grub.cfg

Exit out of VT-1, switch back to your desktop (Ctrl+Alt+F7) and reboot
the system.

The only downside to this arrangement, and I'm sure you're already
familiar with this pain, is sometimes various Linux distributions 'step
on' each other's grub installations whenever e.g. the proprietary
graphics driver and/or the kernel is updated. I use the above procedure
quite reliably to restore sanity when this happens on my system.

I hope this helps and YMMV disclaimers apply, of course.

regards,

Carl

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Leap 42.3 and Grub 2 Mess

Carl Hartung-2
In reply to this post by Robin Klitscher-2
On Sat, 12 Aug 2017 13:41:29 +1200
Robin Klitscher wrote:

> It appears to confirm that Grub2 is expecting to find its files at
> the same non-existent UUID as in the error message above.  The
> question seems to be, therefore, is there a way of pointing Grub2 at
> a valid UUID; and if so, how can I do this?

I forgot to mention that I did have an incident not too long ago, on a
UEFI system, where I concluded it would be a lot less work to restore
the 'missing' UUID than it would be to unscramble the other affected
configurations (there were several.) Notes: 1. I always use ext4. 2. I
can only vouch that the following works for ext2/3/4.

First, to do this, you have to boot into rescue mode using the
installation media (or into a parallel Linux installation) and, as
superuser, ensure that the affected partitions are not mounted. Use
'tune2fs' to rewrite the old UUIDs (on ext2/3/4), e.g.:

# tune2fs /dev/{device} -U {uuid}

Looks looks this:

# tune2fs /dev/sda1 -U c1b9d5a2-f162-11cf-9ece-0020afc76f16

Restoring the overwritten UUIDs in that case actually saved me a lot of
time, so it might be worth investigating in your case, as well.

hth, YMMV & regards,

Carl

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Leap 42.3 and Grub 2 Mess

Robin Klitscher-2
On 08/12/17 14:52, Carl Hartung wrote:

> On Sat, 12 Aug 2017 13:41:29 +1200
> Robin Klitscher wrote:
>
>> It appears to confirm that Grub2 is expecting to find its files at
>> the same non-existent UUID as in the error message above.  The
>> question seems to be, therefore, is there a way of pointing Grub2 at
>> a valid UUID; and if so, how can I do this?
>
> I forgot to mention that I did have an incident not too long ago, on a
> UEFI system, where I concluded it would be a lot less work to restore
> the 'missing' UUID than it would be to unscramble the other affected
> configurations (there were several.) Notes: 1. I always use ext4. 2. I
> can only vouch that the following works for ext2/3/4.
>
> First, to do this, you have to boot into rescue mode using the
> installation media (or into a parallel Linux installation) and, as
> superuser, ensure that the affected partitions are not mounted. Use
> 'tune2fs' to rewrite the old UUIDs (on ext2/3/4), e.g.:
>
> # tune2fs /dev/{device} -U {uuid}
>
> Looks looks this:
>
> # tune2fs /dev/sda1 -U c1b9d5a2-f162-11cf-9ece-0020afc76f16
>
> Restoring the overwritten UUIDs in that case actually saved me a lot of
> time, so it might be worth investigating in your case, as well.
>
> hth, YMMV & regards,
>
> Carl
>

Thank you for this and your previous.

Unfortunately when I try the grub2-install routine (mapped to /dev/sdc1
where the 42.3 / installation is), I get this:

Installing for i386-pc platform.
grub2-install: warning: File system `ext2' doesn't support embedding.
grub2-install: warning: Embedding is not possible.  GRUB can only be
installed in this setup by using blocklists.  However, blocklists are
UNRELIABLE and their use is discouraged..
grub2-install: error: will not proceed with blocklists.

... but I don't know enough to know what that means.

I'm exclusively in ext4 too, so I'll maybe try your tune2fs solution.
After a pause to catch my breath, that is.

If it's of any relevance, the first page of the bootinfoscript run is here:

https://paste.opensuse.org/40124952


The uuid 2dfdf01d-9ed8-4d03-846b-5b452652b707 is the one that's nowhere
on the system.


--
Robin K
Wellington "Harbour City"
New Zealand

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Leap 42.3 and Grub 2 Mess

Carl Hartung-2
On Sat, 12 Aug 2017 15:16:52 +1200
Robin Klitscher wrote:

> grub2-install: warning: File system `ext2' doesn't support embedding.

My apologies, Robin! Drop the '1' from /dev/sdc1, e.g.:

# grub2-install /dev/sdc
# grub2-mkconfig -o /boot/grub2/grub.cfg

This should cause the installation to reproduce / match the other Grub2
installations on that system. Just out of curiosity, how are you
selecting which drive is booting this system? Is there a built-in boot
menu which allows you to select which grub menu is loading?

regards,

Carl

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Leap 42.3 and Grub 2 Mess

Felix Miata-3
In reply to this post by Robin Klitscher-2
Robin Klitscher composed on 2017-08-12 13:41 (UTC+1200):

> To install Leap 42.3 I did what has worked for me successfully for more
> than ten years - cleared space by formatting where an older version had
> been and installing afresh in those spaces, with Grub2 in the MBR.

If you are now using Grub2 in MBR, it's not what you were doing 10 years ago, at
least, not with openSUSE as primary OS, or its bootloader as primary bootloader.
Grub2 became the default bootloader in openSUSE 12.2 in September 2012, almost 5
years ago. Grub2 was not even mentioned in the 12.1 release notes, while Grub
was. :-D

Grub remains available in 42.3, just not configurable as bootloader during
openSUSE installation. It's still the only openSUSE bootloader I've ever used.

All my 25+ working systems are multiboot. One has >40 bootable installations,
none have fewer than 3, and most have >12. openSUSE's Grub is the exclusive
bootloader for FOSS OSes on every such system on which I have no version of
*buntu installed (which is most).

Particularly because of openSUSE Gfxboot, Grub remains competent and well suited
to my multiboot needs, needs which in order to maximize filesystem accessibility
regardless what is currently booted, exclude all Linux native filesystems other
than swap and EXT#, or more than 2TB.

Even if I was using BTRFS, I'd still be using Grub, just not using BTRFS to host
/boot/'s files.

One key to *reliable* multiboot is following this sage advice:
<https://old-en.opensuse.org/Bugs/grub#How_does_a_PC_boot_.2F_How_can_I_set_up_a_working_GRUB.3F>

For me that means a primary partition on the first HD hosts the primary
bootloader, one which is never mounted to /boot/, and generic code lives in
every HD's MBR that has any code at all.

Given you're "clearing space" for 42.3 installation, not using UEFI, and
multibooting, which very likely means you still have some version of openSUSE
still bootable, the only technical reason I can think of that you couldn't
convert back to the comprehensible old Grub, should you choose, would be
non-availability of of a primary partition table slot on the first HD to host
your choice of primary bootloader.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Leap 42.3 and Grub 2 Mess

Carl Hartung-2
In reply to this post by Robin Klitscher-2
On Sat, 12 Aug 2017 15:16:52 +1200
Robin Klitscher wrote:

> Thank you for this and your previous.

You're welcome!

> Unfortunately when I try the grub2-install routine (mapped
> to /dev/sdc1 where the 42.3 / installation is), I get this:
>
> Installing for i386-pc platform.
> grub2-install: warning: File system `ext2' doesn't support embedding.
> grub2-install: warning: Embedding is not possible.  GRUB can only be
> installed in this setup by using blocklists.  However, blocklists are
> UNRELIABLE and their use is discouraged..
> grub2-install: error: will not proceed with blocklists.
>
> ... but I don't know enough to know what that means.

It means you need to install Grub2 in the MBR, not in the partition.
Dropping the '1' as mentioned in my previous reply will accomplish this.

> I'm exclusively in ext4 too, so I'll maybe try your tune2fs solution.
> After a pause to catch my breath, that is.
>
> If it's of any relevance, the first page of the bootinfoscript run is
> here:
>
> https://paste.opensuse.org/40124952
>
>
> The uuid 2dfdf01d-9ed8-4d03-846b-5b452652b707 is the one that's
> nowhere on the system.

If you restore this UUID to the partition, don't forget to
edit /etc/fstab in the 42.3 installation so it matches. After making
this change, you'll need to install Grub2 again. :)

regards,

Carl

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Leap 42.3 and Grub 2 Mess

Robin Klitscher-2
On 08/12/17 16:00, Carl Hartung wrote:

> On Sat, 12 Aug 2017 15:16:52 +1200
> Robin Klitscher wrote:
>
>> Thank you for this and your previous.
>
> You're welcome!
>
>> Unfortunately when I try the grub2-install routine (mapped
>> to /dev/sdc1 where the 42.3 / installation is), I get this:
>>
>> Installing for i386-pc platform.
>> grub2-install: warning: File system `ext2' doesn't support embedding.
>> grub2-install: warning: Embedding is not possible.  GRUB can only be
>> installed in this setup by using blocklists.  However, blocklists are
>> UNRELIABLE and their use is discouraged..
>> grub2-install: error: will not proceed with blocklists.
>>
>> ... but I don't know enough to know what that means.
>
> It means you need to install Grub2 in the MBR, not in the partition.
> Dropping the '1' as mentioned in my previous reply will accomplish this.
>

Did that, though to /dev/sdc rather than sda 'cos 42.3 system is on sdc1.

Since the bootscript result seems to indicate that the bootloader is
looking for its files at sda rather than sdc, d'you think it might be
worth a try to reinstall Grub2 there rather than sdc????


--
Robin K
Wellington "Harbour City"
New Zealand

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Leap 42.3 and Grub 2 Mess

Robin Klitscher-2
In reply to this post by Felix Miata-3
On 08/12/17 15:59, Felix Miata wrote:

> Robin Klitscher composed on 2017-08-12 13:41 (UTC+1200):
>
>> To install Leap 42.3 I did what has worked for me successfully for more
>> than ten years - cleared space by formatting where an older version had
>> been and installing afresh in those spaces, with Grub2 in the MBR.
>
> If you are now using Grub2 in MBR, it's not what you were doing 10 years ago, at
> least, not with openSUSE as primary OS, or its bootloader as primary bootloader.
> Grub2 became the default bootloader in openSUSE 12.2 in September 2012, almost 5
> years ago. Grub2 was not even mentioned in the 12.1 release notes, while Grub
> was. :-D
>
> Grub remains available in 42.3, just not configurable as bootloader during
> openSUSE installation. It's still the only openSUSE bootloader I've ever used.
>
> All my 25+ working systems are multiboot. One has >40 bootable installations,
> none have fewer than 3, and most have >12. openSUSE's Grub is the exclusive
> bootloader for FOSS OSes on every such system on which I have no version of
> *buntu installed (which is most).
>
> Particularly because of openSUSE Gfxboot, Grub remains competent and well suited
> to my multiboot needs, needs which in order to maximize filesystem accessibility
> regardless what is currently booted, exclude all Linux native filesystems other
> than swap and EXT#, or more than 2TB.
>
> Even if I was using BTRFS, I'd still be using Grub, just not using BTRFS to host
> /boot/'s files.
>
> One key to *reliable* multiboot is following this sage advice:
> <https://old-en.opensuse.org/Bugs/grub#How_does_a_PC_boot_.2F_How_can_I_set_up_a_working_GRUB.3F>
>
> For me that means a primary partition on the first HD hosts the primary
> bootloader, one which is never mounted to /boot/, and generic code lives in
> every HD's MBR that has any code at all.
>
> Given you're "clearing space" for 42.3 installation, not using UEFI, and
> multibooting, which very likely means you still have some version of openSUSE
> still bootable, the only technical reason I can think of that you couldn't
> convert back to the comprehensible old Grub, should you choose, would be
> non-availability of of a primary partition table slot on the first HD to host
> your choice of primary bootloader.
>
Thanks Felix.  My use of the language was a bit loose.  I should have
said I'd been using the procedure I described, first under Grub and then
under Grub2 for more than ten years (about 15, actually) successfully
until now.  But I'd still prefer to make Grub2 work than to backlevel to
Grub in defeat!

--
Robin K
Wellington "Harbour City"
New Zealand

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Leap 42.3 and Grub 2 Mess

David C. Rankin
In reply to this post by Robin Klitscher-2
On 08/11/2017 11:24 PM, Robin Klitscher wrote:
> Did that, though to /dev/sdc rather than sda 'cos 42.3 system is on sdc1.
>
> Since the bootscript result seems to indicate that the bootloader is
> looking for its files at sda rather than sdc, d'you think it might be
> worth a try to reinstall Grub2 there rather than sdc????

No, you are probably chainloading from sda, so if you resinstall grub to sda,
you may lose the chainload references to all other OSs. (it depends on how you
are doing things)

  Instead, take a look at

/etc/default/grub

  Check the 'resume' option in GRUB_CMDLINE_LINUX_DEFAULT, e.g.

GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/disk/by-uuid/3cadab5b-13b4-4dce-84d3-05e2070f741c
splash=silent ...

  you can set the UUID (or /dev/sdc1) there. Then remake the grub config with

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

Yast is most likely defaulting to sda (I've had it do weird things with grub2
config on multi-drive, multi-os systems... like overwriting the Win10
bootloader, inserting grub in sda, setting windows to chainload from grub and
booting Linux on sdb, when all I was doing was installing to sdb)

There are a couple of other grub configs you can edit manually as well
(including /boot/grub2/grub.cfg), you just need to be exact when you do.


--
David C. Rankin, J.D.,P.E.

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Leap 42.3 and Grub 2 Mess

Carl Hartung-2
In reply to this post by Robin Klitscher-2
On Sat, 12 Aug 2017 16:24:14 +1200
Robin Klitscher wrote:

> On 08/12/17 16:00, Carl Hartung wrote:
> > On Sat, 12 Aug 2017 15:16:52 +1200
 

> > It means you need to install Grub2 in the MBR, not in the partition.
> > Dropping the '1' as mentioned in my previous reply will accomplish
> > this.
>
> Did that, though to /dev/sdc rather than sda 'cos 42.3 system is on
> sdc1.
>
> Since the bootscript result seems to indicate that the bootloader is
> looking for its files at sda rather than sdc, d'you think it might be
> worth a try to reinstall Grub2 there rather than sdc????

Did you see my question? "Just out of curiosity, how are you selecting
which drive is booting this system? Is there a built-in boot menu which
allows you to select which grub menu is loading?" It relates to this. :)

The bootscript result says you have Grub2 (v2.00) installed in the MBRs
of sda, sdb and sdc, and that the Vista bootloader is installed in the
MBR of sdd. The 42.3 installation system is falling back to the safest
and most sane configuration given the complex (for os-prober)
environment it has discovered. It chooses to install grub2 in the MBR
of the installation target device. Although it 'sees' the other Grub2
installations, it refuses to touch them -- including the one that the
system is apparently booting from by default, and, which was rendered
stale by the UUID change.

This 'safe and sane' strategy does a good job of avoiding 'stepping on'
and breaking other Linux installations. You just need to update each
individual Grub2 installation using it's own 'native' installer (there
are differences across distributions.)

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Leap 42.3 and Grub 2 Mess

Robin Klitscher-2
On 08/12/17 19:57, Carl Hartung wrote:

> On Sat, 12 Aug 2017 16:24:14 +1200
> Robin Klitscher wrote:
>
>> On 08/12/17 16:00, Carl Hartung wrote:
>>> On Sat, 12 Aug 2017 15:16:52 +1200
>  
>>> It means you need to install Grub2 in the MBR, not in the partition.
>>> Dropping the '1' as mentioned in my previous reply will accomplish
>>> this.
>>
>> Did that, though to /dev/sdc rather than sda 'cos 42.3 system is on
>> sdc1.
>>
>> Since the bootscript result seems to indicate that the bootloader is
>> looking for its files at sda rather than sdc, d'you think it might be
>> worth a try to reinstall Grub2 there rather than sdc????
>
> Did you see my question? "Just out of curiosity, how are you selecting
> which drive is booting this system? Is there a built-in boot menu which
> allows you to select which grub menu is loading?" It relates to this. :)
>
When it worked, Grub2 gave me a menu list from which I could select
which OS to boot, but I expect that's not what you mean.  If you mean
could I select which grub menu was actually loading, the answer would
have to be "no".  In the case of Leap 42.2 on /dev/sdb2, however, and
only circumstantially, I've long suspected that the menu actually being
loaded was not the one installed with 42.2 but was probably the one
installed previously with 42.1 (on sdc1).


> The bootscript result says you have Grub2 (v2.00) installed in the MBRs
> of sda, sdb and sdc, and that the Vista bootloader is installed in the
> MBR of sdd. The 42.3 installation system is falling back to the safest
> and most sane configuration given the complex (for os-prober)
> environment it has discovered. It chooses to install grub2 in the MBR
> of the installation target device. Although it 'sees' the other Grub2
> installations, it refuses to touch them -- including the one that the
> system is apparently booting from by default, and, which was rendered
> stale by the UUID change.
>
> This 'safe and sane' strategy does a good job of avoiding 'stepping on'
> and breaking other Linux installations. You just need to update each
> individual Grub2 installation using it's own 'native' installer (there
> are differences across distributions.)
>

I really don't know how the bootinfoscript could come up with "Vista
installed in the MBR of /dev/sdd".  This machine has never had Vista
anywhere near it.  What I do have is Windows 7, with the small System
Reserved partition as sda1 and the main installation in sda2.  Weird.

But right now it's bedtime where I am.  I'll return to this in the morning.

--
Robin K
Wellington "Harbour City"
New Zealand

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Leap 42.3 and Grub 2 Mess

Robin Klitscher-2
In reply to this post by David C. Rankin
On 08/12/17 19:10, David C. Rankin wrote:

> On 08/11/2017 11:24 PM, Robin Klitscher wrote:
>> Did that, though to /dev/sdc rather than sda 'cos 42.3 system is on sdc1.
>>
>> Since the bootscript result seems to indicate that the bootloader is
>> looking for its files at sda rather than sdc, d'you think it might be
>> worth a try to reinstall Grub2 there rather than sdc????
>
> No, you are probably chainloading from sda, so if you resinstall grub to sda,
> you may lose the chainload references to all other OSs. (it depends on how you
> are doing things)
>
>   Instead, take a look at
>
> /etc/default/grub
>
>   Check the 'resume' option in GRUB_CMDLINE_LINUX_DEFAULT, e.g.
>
> GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/disk/by-uuid/3cadab5b-13b4-4dce-84d3-05e2070f741c
> splash=silent ...
>
>   you can set the UUID (or /dev/sdc1) there. Then remake the grub config with
>
>  # grub2-mkconfig -o /boot/grub2/grub.cfg
>
> Yast is most likely defaulting to sda (I've had it do weird things with grub2
> config on multi-drive, multi-os systems... like overwriting the Win10
> bootloader, inserting grub in sda, setting windows to chainload from grub and
> booting Linux on sdb, when all I was doing was installing to sdb)
>
> There are a couple of other grub configs you can edit manually as well
> (including /boot/grub2/grub.cfg), you just need to be exact when you do.
>
>
I don't quite understand.  In all three openSUSE installations
(currently Leap 41.2, Leap 41.3 and Tumbleweed), that line in
/etc/default/grub uses the UUID of a SWAP partition.

And as far as I can see, all of the UUID entries in the respective
/boot/grub2/grub.cfg files point to the correct partition in each case.

--
Robin K
Wellington "Harbour City"
New Zealand

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Leap 42.3 and Grub 2 Mess

Robin Klitscher-2
On 08/12/17 23:06, Robin Klitscher wrote:

> On 08/12/17 19:10, David C. Rankin wrote:
>> On 08/11/2017 11:24 PM, Robin Klitscher wrote:
>>> Did that, though to /dev/sdc rather than sda 'cos 42.3 system is on sdc1.
>>>
>>> Since the bootscript result seems to indicate that the bootloader is
>>> looking for its files at sda rather than sdc, d'you think it might be
>>> worth a try to reinstall Grub2 there rather than sdc????
>>
>> No, you are probably chainloading from sda, so if you resinstall grub to sda,
>> you may lose the chainload references to all other OSs. (it depends on how you
>> are doing things)
>>
>>   Instead, take a look at
>>
>> /etc/default/grub
>>
>>   Check the 'resume' option in GRUB_CMDLINE_LINUX_DEFAULT, e.g.
>>
>> GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/disk/by-uuid/3cadab5b-13b4-4dce-84d3-05e2070f741c
>> splash=silent ...
>>
>>   you can set the UUID (or /dev/sdc1) there. Then remake the grub config with
>>
>>  # grub2-mkconfig -o /boot/grub2/grub.cfg
>>
>> Yast is most likely defaulting to sda (I've had it do weird things with grub2
>> config on multi-drive, multi-os systems... like overwriting the Win10
>> bootloader, inserting grub in sda, setting windows to chainload from grub and
>> booting Linux on sdb, when all I was doing was installing to sdb)
>>
>> There are a couple of other grub configs you can edit manually as well
>> (including /boot/grub2/grub.cfg), you just need to be exact when you do.
>>
>>
> I don't quite understand.  In all three openSUSE installations
> (currently Leap 41.2, Leap 41.3 and Tumbleweed), that line in
> /etc/default/grub uses the UUID of a SWAP partition.
>
> And as far as I can see, all of the UUID entries in the respective
> /boot/grub2/grub.cfg files point to the correct partition in each case.
>

Of course I meant 42.2 and 42.3.  It's too late at night......


--
Robin K
Wellington "Harbour City"
New Zealand

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Leap 42.3 and Grub 2 Mess

Anton Aylward-2
In reply to this post by Robin Klitscher-2
On 12/08/17 07:06 AM, Robin Klitscher wrote:
> I don't quite understand.  In all three openSUSE installations
> (currently Leap 41.2, Leap 41.3 and Tumbleweed), that line in
> /etc/default/grub uses the UUID of a SWAP partition.
>
> And as far as I can see, all of the UUID entries in the respective
> /boot/grub2/grub.cfg files point to the correct partition in each case.

For the sake of visibility I use the partitioning tool to label my key
partitions.  Of course its even easier with LVM :-)

So I have

# ls /dev/disk/by-label/
BACKUP  HOME  Mail   MyMovies  OPT  PhotoByYear  SHARE4  SWAP  VAR
BOOT    ISO   Media  MyMusic   PDF  ROOT4        SRV     TMP


And of course things like /etc/default/grub have the matching entry for when
mkinit etc etc runs, it make verifying congruence and the contents of lsinitrd
so much easier.

What's that about UUIDs being unique and unambiguous?
Well I'm not saying that you couldn't put the swap function on a partition
called HOME, but its easy enough to verify, and if you deliberately make things
that obscure when you don't have to then more fool you.   I realise not everyone
is as methodological and persnicity as I am, nor logs what they do in a daily
written journal, but its something that I would advise.  As someone said, its
that kind of dedication to the details that separates the professionals from the
cowboys.

Sorry, preaching and getting off topic.


But it's little things like this that make life so much more tension free.

--
         A: Yes.
     >   Q: Are you sure?
     >>  A: Because it reverses the logical flow of conversation.
     >>> Q: Why is top posting frowned upon?


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Leap 42.3 and Grub 2 Mess

Robin Klitscher-2
In reply to this post by Carl Hartung-2
On 08/12/17 14:52, Carl Hartung wrote:

> On Sat, 12 Aug 2017 13:41:29 +1200
> Robin Klitscher wrote:
>
>> It appears to confirm that Grub2 is expecting to find its files at
>> the same non-existent UUID as in the error message above.  The
>> question seems to be, therefore, is there a way of pointing Grub2 at
>> a valid UUID; and if so, how can I do this?
>
> I forgot to mention that I did have an incident not too long ago, on a
> UEFI system, where I concluded it would be a lot less work to restore
> the 'missing' UUID than it would be to unscramble the other affected
> configurations (there were several.) Notes: 1. I always use ext4. 2. I
> can only vouch that the following works for ext2/3/4.
>
> First, to do this, you have to boot into rescue mode using the
> installation media (or into a parallel Linux installation) and, as
> superuser, ensure that the affected partitions are not mounted. Use
> 'tune2fs' to rewrite the old UUIDs (on ext2/3/4), e.g.:
>
> # tune2fs /dev/{device} -U {uuid}
>
> Looks looks this:
>
> # tune2fs /dev/sda1 -U c1b9d5a2-f162-11cf-9ece-0020afc76f16
>
> Restoring the overwritten UUIDs in that case actually saved me a lot of
> time, so it might be worth investigating in your case, as well.
>
> hth, YMMV & regards,
>
> Carl
>

OK; I tried that.  Changed the UUID of sdc1 to match the one in the
error message, verified that the change had taken hold, and edited the
line in fstab to match.

Unfortunately, my mileage did vary.  On reboot I was again dumped into
the grub rescue shell, this time following a new error message:

"symbol 'grub_tpm_measure' not found"

and I've not the faintest idea what that means.


--
Robin K
Wellington "Harbour City"
New Zealand

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Leap 42.3 and Grub 2 Mess

David C. Rankin
In reply to this post by Robin Klitscher-2
On 08/12/2017 06:06 AM, Robin Klitscher wrote:
> I don't quite understand.  In all three openSUSE installations
> (currently Leap 41.2, Leap 41.3 and Tumbleweed), that line in
> /etc/default/grub uses the UUID of a SWAP partition.
>
> And as far as I can see, all of the UUID entries in the respective
> /boot/grub2/grub.cfg files point to the correct partition in each case.
>

  No, you are right -- it was late, for the root partitions and boot
partitions, you can tweak the menu (and submenu) entries in grub.cfg. If the
problem is the entries need to change because you are trying to chainload from
your original boot drive to the new install at sdc1, then you need to find the
'menuentry' in the first /boot/grub2/grub.cfg that you select to boot the new
install on sdc1. It will have the old UUID. (UUIDs attach to filesystems, not
partitions). So you need to point it to the new filesystem.

The menuentry is like:

  You need to point this to the new root UUID at the end of

        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos5
--hint-efi=hd1,msdos5 --hint-baremetal=ahci1,msdos5 --hint='hd0,msdos5'
3738365d-78f5-4831-aa18-63d4aed48e2d
        else
          search --no-floppy --fs-uuid --set=root
3738365d-78f5-4831-aa18-63d4aed48e2d
        fi

  You need to point to the /boot UUID (grub root) as root= in the linux line
where resume= IS swap. (you can just confirm this is picked up correctly from
/etc/default/grub)

        linux   /vmlinuz-4.4.79-18.23-default
root=UUID=8e3d344b-32ba-4edc-85b7-03a1bba70427
resume=/dev/disk/by-uuid/3cadab5b-13b4-4dce-84d3-05e2070f741c splash=silent
quiet showopts



--
David C. Rankin, J.D.,P.E.

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Leap 42.3 and Grub 2 Mess

Robin Klitscher-2
On 08/13/17 11:57, David C. Rankin wrote:

> On 08/12/2017 06:06 AM, Robin Klitscher wrote:
>> I don't quite understand.  In all three openSUSE installations
>> (currently Leap 41.2, Leap 41.3 and Tumbleweed), that line in
>> /etc/default/grub uses the UUID of a SWAP partition.
>>
>> And as far as I can see, all of the UUID entries in the respective
>> /boot/grub2/grub.cfg files point to the correct partition in each case.
>>
>
>   No, you are right -- it was late, for the root partitions and boot
> partitions, you can tweak the menu (and submenu) entries in grub.cfg. If the
> problem is the entries need to change because you are trying to chainload from
> your original boot drive to the new install at sdc1, then you need to find the
> 'menuentry' in the first /boot/grub2/grub.cfg that you select to boot the new
> install on sdc1. It will have the old UUID. (UUIDs attach to filesystems, not
> partitions). So you need to point it to the new filesystem.
>
> The menuentry is like:
>
>   You need to point this to the new root UUID at the end of
>
>         if [ x$feature_platform_search_hint = xy ]; then
>           search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos5
> --hint-efi=hd1,msdos5 --hint-baremetal=ahci1,msdos5 --hint='hd0,msdos5'
> 3738365d-78f5-4831-aa18-63d4aed48e2d
>         else
>           search --no-floppy --fs-uuid --set=root
> 3738365d-78f5-4831-aa18-63d4aed48e2d
>         fi
>
>   You need to point to the /boot UUID (grub root) as root= in the linux line
> where resume= IS swap. (you can just confirm this is picked up correctly from
> /etc/default/grub)
>
>         linux   /vmlinuz-4.4.79-18.23-default
> root=UUID=8e3d344b-32ba-4edc-85b7-03a1bba70427
> resume=/dev/disk/by-uuid/3cadab5b-13b4-4dce-84d3-05e2070f741c splash=silent
> quiet showopts
>
>

Thank you for that.  It prompted me to check each of the three
/boot/grub2/grub.cfg files I have on this machine.  Two were clear, but
sure enough, the stale UUID appeared many times in the third -
Tumbleweed with its root filesystem on /sda11.

So thought booting to that OS and running grub2-mkconfig <etc> might
cure the problem.  And sure, it corrected all of the references to the
stale UUID in Tumbleweed's grub.cfg.

But, dammit, on reboot I still get dumped into the grub2 rescue shell
with the same error message pointing to the stale UUID.  So that
reference has to be somewhere else in the grub2 environment as well.
But where?



--
Robin K
Wellington "Harbour City"
New Zealand

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Leap 42.3 and Grub 2 Mess

Anton Aylward-2
On 12/08/17 10:05 PM, Robin Klitscher wrote:
> But, dammit, on reboot I still get dumped into the grub2 rescue shell
> with the same error message pointing to the stale UUID.  So that
> reference has to be somewhere else in the grub2 environment as well.
> But where?

You should also rebuild the initrd.

        mkinitrd

although that is a wrapper now we have drakut, but it also updates the
bootloader for you :-)

Why?  It seems that the initrd has stuff embedded in it and that needs updating
as well.


A lot of all this stuff is scripts, either shell or perl, and is quite readable.
The only "obscure" parts are, if you're not familiar with them,

a) the regular expressions, either in perl or the way that the shell slices and
dices

b) some of the way the shell constructs strings

You may have to consult the man pages or the O'Reilly books.
I've found them a good investment.

--
         A: Yes.
     >   Q: Are you sure?
     >>  A: Because it reverses the logical flow of conversation.
     >>> Q: Why is top posting frowned upon?


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Leap 42.3 and Grub 2 Mess

Andrei Borzenkov
In reply to this post by Robin Klitscher-2
13.08.2017 02:17, Robin Klitscher пишет:
>
> Unfortunately, my mileage did vary.  On reboot I was again dumped into
> the grub rescue shell, this time following a new error message:
>
> "symbol 'grub_tpm_measure' not found"
>
> and I've not the faintest idea what that means.
>

This means that grub image installed on your boot disk and loaded by
firmware (or first level bootloader) does not match content of
/boot/grub2 directory. grub actually tried to protect you by loudly
screaming that /boot/grub2 directory *used during bootloader
installation* no more existed, but you preferred to ignore it and follow
"helpful" advices and tried to fool grub into believing directory
existed ... fortunately it hit problem early enough instead of crashing
mysteriously with black screen.

You need to reinstall bootloader in the right place. Where "right place"
depends on what disk is actually used by your BIOS to boot your system.
And "reinstall bootloader" means exactly that - running grub2-install or
update-bootloader --reinit; your problem has nothing to do with
configuration file, so no amount of grub2-mkconfig or fiddling with
/etc/default/grub is going to help.

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

123
Loading...