[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Wed, 30 Apr 2014 22:24:21 -0400
Thank you, Arbiel. That script works. It took me a while to find it.
"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
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 (
https://github.com/arvidjaar/bootinfoscript ) 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:
> 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.
> 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
>> the same hard drive for core.img. core.img is at this location and
>> 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
>> 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
- [no subject], plmalternate plmalternate, 2014/04/27
- Re:, Arbiel Perlacremaz, 2014/04/28
plmalternate plmalternate <=