[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


From: plmalternate plmalternate
Subject: Re:
Date: Tue, 6 May 2014 16:17:04 -0400

Following up on the alternate bootinfoscript by Borzenkov et al, it
took me while to come up with another drive to test with 2 drives but
I've done so now. With 2 drives connected here is the relevant part of

============================= Boot Info Summary: ===============================

 => Grub2 (v2.00) is installed in the MBR of /dev/sda and looks at sector 1 of
    the same hard drive for core.img. core.img is at this location and looks
    for (,msdos1)/boot/grub.
 => Windows Vista is installed in the MBR of /dev/sdb.

sda1: __________________________________________________________________________

    File system:       ext3
    Boot sector type:  -
    Boot sector info:
    Operating System:  Ubuntu 14.04 LTS
    Boot files:        /boot/grub/grub.cfg /etc/fstab

     .  .  . [skipped some normal stuff] .  .  .

sdb1: __________________________________________________________________________

    File system:
    Boot sector type:  Unknown
    Boot sector info:
    Mounting failed:   mount: unknown filesystem type ''
mount: unknown filesystem type ''

     .  .  . [skipped some normal stuff] .  .  .
So as you can see it still fails to id the DRIVE on which Grub looks
for /boot/grub but it does get the partition number, which is a big
improvement over the "official" bootinfoscript in the Ubuntu 14.04 LTS
Trusty repository. Sometime in the next few days I'll verify (or
refute) that it is getting the partition number CORRECTLY (I presume
it is, but I'll check) and study the script to see if I can understand
it and perhaps figure out where it fails in getting the drive letter.
If I come with something that might be of interest, I'll let y'all
know. Thanks for the help.

On 4/30/14, plmalternate plmalternate <address@hidden> wrote:
> Thank you, Arbiel. That script works.  It took me a while to find it.
> It returns:
> "core.img is at this location and looks  for (,msdos1)/boot/grub."
> which is a heck of a lot better than "partiton 94 for .", even if
> imperfect. I suspect leaving off the drive spec In
> "(,msdos1)/boot/grub" is a consequence of my having only one drive
> attached at the moment. I'll test that shortly. This is a huge help.
> Thank you much. I'm surprised this improvement hasn't been adopted at
> Ubuntu yet,
>  For the benefit of anyone who finds their way to this archive through
> searching for the same sort of information, the conversation is on a
> different list, here:
> It links to an alternate bootinfoscript, described in the post by
> Andrey Borzenkov as "my fixes submitted upstream but never applied",
> but on the page at github linked to (
> ) as the "master branch"
> which leaves me a little confused about the history.  But, to cut to
> the chase, it is different from the bootinfoscript in the Ubuntu
> Trusty 14.04 repository, and unlike that one, IT WORKS.
> Direct link to script:
> On 4/28/14, Arbiel Perlacremaz <address@hidden> wrote:
>> Hi
>> Maybe the conversation I once had with Andrey Borzenkov will help you.
>> Look in grub's 2014 february archive (2014/02/15 15:48) for
>> Proposal for fixing bootinfoscript when grub v2.00 sits on the MBR
>> However I now always have grub-install install stage 2 files in a unique
>> grub partition, distinct from /boot as the later has not to be shared
>> among several distributions.
>> Arbiel
>> Le 27/04/2014 14:57, plmalternate plmalternate a écrit :
>>> Can anyone point me toward some approach that I might could hammer and
>>> whittle into a bash-scriptable way of determining which partition grub
>>> is looking in for stage 2 files (that is to say wherever it has to
>>> look after getting everything it can out of the
>>> before-the-first-partition area?
>>> I used bootinfoscript from the ubuntu 14.04 repository but the only
>>> relevant part of its output gives me:
>>> "Grub2 (v1.99) is installed in the MBR of /dev/sda and looks at sector 1
>>> of
>>>      the same hard drive for core.img. core.img is at this location and
>>> looks
>>>      in partition 94 for ."
>>> I only have 8 partitions, not 94 and that "for ." looks like some
>>> variable didn't get set.  So I can't see any way to use that.
>>> I also found in this old thread:
>>> this code:
>>> sudo dd if=/dev/sda  bs=1 skip=1049 count=2 | hexdump
>>> which was supposed to give an output that could be interpreted to give
>>> the info I'm after but
>>> the thread was about grub-legacy and the scheme for interpretation
>>> given there didn't seem applicable to the output I got which was:
>>> 2+0 records in
>>> 2+0 records out
>>> 2 bytes (2 B) copied, 0.000104627 s, 19.1 kB/s
>>> 0000000 ffff
>>> 0000002
>>> It won't do to look for /boot/grub because any or all OSs on any or
>>> all partition could have once BEEN the partition with stage 2 files
>>> but not be any more. Nor do I think it would do to simply look for
>>> evidence of which OS was installed most recently and assume that is
>>> the one
>>> with stage 2 files because the most recent could have been installed
>>> without reinstalling grub.
>>> To reiterate, I'm not looking to find this information out for my
>>> present rig, which is trivial. I looking for something I might could
>>> work into a scriptable way to solve the general case.
>>> Thanks for reading.
>>> _______________________________________________
>>> Help-grub mailing list
>>> address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]