2

This is a weird one...

I'm working on some software. It has a function to make a USB device bootable. It does this by running a long, complex sequence of actions to copy a minimal Linux OS onto the device and then install GRUB2 as the bootloader. The trouble is, at the end of this procedure, the device won't boot. GRUB2 loads, but drops into a rescue shell and whines that it can't find [whatever the UUID of the boot partition currently is]. The UUID it's whining about is definitely correct.

The actual command that my software is running is this:

grub2-install --boot-directory=/mnt/boot /dev/sdb

The command exits with code 0, and says on stdout "installation finished, no errors reported". And yet, GRUB won't boot.

Here's the excruciatingly weird part: If I manually type in the exact command above, then the device becomes bootable. Everything works perfectly. But when the software runs this command automatically, something goes wrong... What the hell??

Does anybody have the vaguest idea why this behaviour might occur? Are there any environment variables the installation script depends on? What kinds of disk modifications would upset GRUB? Is there some way I can see what gets changed the second time I run the script?

Edit: OpenSUSE 12.2, everything is running as root. (Is any other user even allowed to fiddle with the MBR of a disk?)

Edit: env returns nearly identical results both from the software and from a terminal. (A few variables such as PWD, SHLVL, WINDOWID were different, but I can't see how that's relevant.)

Edit: I tried having my software just run the command twice. That made no difference. So it really is an environment difference of some kind...

  • Strange indeed. Could it be a username issue? Do you run the program and the manual command as the same user? Is that user root? What's your OS? On my Debian grub2-install is a shell script so environmental vars could be a factor I guess. – terdon Feb 18 '14 at 16:34
  • @terdon Yes, definitely a shell script. I'm wading through the source code now. :-( – MathematicalOrchid Feb 18 '14 at 16:36
  • Reading the source code reveals the existence of an undocumented --debug flag. This produces many billion lines of incomprehensible output. So I still don't know what the problem is... – MathematicalOrchid Feb 18 '14 at 17:16
2

Ah-HAH!

The application mounts the filesystem slightly differently than how I'm doing it on the command-line.

On the command-line, I do

mount /dev/sdb12 /mnt

But the application uses a whizzy system that parses the partition table and then does something like

mount /dev/sdb /mnt -rw -o offset=32784,limit=8598543

Apparently grub2-install has an undocumented --debug option. If I run the installation from the application and from the command-line using this switch and diff the output, I can see that from the application it's talking about /dev/loop0 rather than /dev/sdb. Also suspicious is the line that reads

< + modules=' biosdisk fat  '
---
> + modules=' biosdisk fat  part_gpt '

Given that the disk is GPT-partitioned, I would expect that this module is kinda necessary.

So it seems that mounting the filesystem in this mannar confuses the script somehow. Now to see if I can fix this or not...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.