bugGNU GRUB - Bugs: bug #37606, Grub2-install doesn't report a...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #37606: Grub2-install doesn't report a failure to write to boot partition

Submitter:  Simon <simd>
Submitted:  Sun 21 Oct 2012 09:56:21 AM UTC
   
 
Category:  Installation Severity:  Major
Priority:  5 - Normal Item Group:  Software Error
Status:  Fixed Privacy:  Public
Assigned to:  None Originator Name:  sd
Open/Closed:  Closed Release:  other
Release:  Reproducibility:  Every Time
Planned Release:  None

Jump to the original submission

Sun 03 Nov 2013 06:09:02 PM UTC, comment #11: 

Now GRUB ignores dynamic disks unless there is a special partition in MBR.

Vladimir Serbinenko <phcoder>
Group administrator
Tue 23 Oct 2012 07:19:40 AM UTC, comment #10: 

OK, I've managed to sort out what had happened. Thanks for the help! I'll record the result here in case it's useful to someone else in the future.

There was indeed a PRIVHEAD signature on the last sector of the disk (when I eventually found it, since the usual partition tools would only tell me the last sector of the last partition. It might be helpful if grub could output where it is looking, and for what in its debug.)

This was probably the result of initially having formatted the disk to run Windows Vista - a long time ago. Vista was subsequently scrubbed and the disk totally re-partitioned. The LDM sector however doesn't seem to have been cleared by the re-partitioning.

I've now cleared the sector to nulls (having backed it up using dd just in case). Grub now runs as expected (yo!) and so far as I can see nothing else has been affected.

Can't comment about whether grub is acting correctly in such a use case or not.

Simon <simd>
Mon 22 Oct 2012 03:58:43 PM UTC, comment #9: 

Do you have "PRIVHEAD" or "VBLK" signatures in either sector 6 or last sector?

Vladimir Serbinenko <phcoder>
Group administrator
Mon 22 Oct 2012 03:36:10 PM UTC, comment #8: 

Well, I've never formatted anything on that disk as an LDM device as far as I'm aware. The partition in question has been the boot partition for my linux for two years! Could you explain what exactly grub is testing for? Parted etc list the disk exactly as normal.

Simon <simd>
Mon 22 Oct 2012 12:41:25 PM UTC, comment #7: 

It's the presence of LDM database with partiton starting at exactly the same sector as the mounted partition.

Vladimir Serbinenko <phcoder>
Group administrator
Mon 22 Oct 2012 12:27:50 PM UTC, comment #6: 

That's interesting. What has established it as an LDM disk as far as grub is concerned?
As far as I am concerned it is a disk that has a number of different msdos types partitions, one of which is NTFS (windows), others are ext3 linux etc, and also LVM (Logical Volume Manager).
As far as I can remember, it was partitioned using gparted. Can it be, for exmaple, that Windows has changed the MBR record somehow? Can I change it back?

Simon <simd>
Mon 22 Oct 2012 10:45:38 AM UTC, comment #5: 

It's LDM/"Dynamic disk" (not LVM). This changes a lot. Installing to LDM isn't currently supported.

Vladimir Serbinenko <phcoder>
Group administrator
Mon 22 Oct 2012 10:03:12 AM UTC, comment #4: 

No, it was being called with /dev/sdb2. From the log output I could only guess that the fact that the disk had LVM partitions on it was throwing grub-install. I've attached the full output.

(file #26813)

Simon <simd>
Mon 22 Oct 2012 09:48:23 AM UTC, comment #3: 

If grub-setup as called with a virtual device then most likely the grub-install command was wrong. It has to be
grub-install /dev/sdX, not some mdX device.

Vladimir Serbinenko <phcoder>
Group administrator
Mon 22 Oct 2012 09:38:21 AM UTC, comment #2: 

Agree, I misread the 0x400.
However I had expected to see some evidence in the output of grub doing something to the partition, and so wasn't sure. The fact that grub-install didn't report a failure to write the partition correctly is the point of the bug-report.

Regarding the write failure itself, I tracked it to the program ending up in the procedure 'grub_diskfilter_write' in diskfilter.c, which exits with GRUB_ERR_NOT_IMPLEMENTED_YET. Not sure if this is the same as what you mean. Agree, this may though have been updated in a later release.

Simon <simd>
Sun 21 Oct 2012 11:13:20 AM UTC, comment #1: 

It's not 400 but 1024. And at this message it writes to core.img file, not to some sector. It's underlying function responsability to set grub_errno (through grub_error). As to apparent writing failure it's due to the lack of necessary flushing ioctl (Linux API is broken in that write doesn't necessarily actually writes unless you add a bunch of ioctl) which is fixed in latest code.

Vladimir Serbinenko <phcoder>
Group administrator
Sun 21 Oct 2012 09:56:21 AM UTC, original submission:  

I think this bug has come up before in different guises e.g. https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/574883

Was trying to load Grub2 into a partition (not MBR), in Fedora 17 using grub2-install. (Wanting to use a specific partition for Grub in a multi-os situation).

Process ran through, no error reported. Attempted to chain load to the partition resulted in an error 'no signature'. Dumping the first sector of the partition showed it to be filled only with "0"s. No boot code.

After some attempts & investigation, running again using debug/verbose option ended with following (actually by this time I was trying just grub2-bios-setup itself):

....
/usr/sbin/grub2-bios-setup: info: saving <213632,0,512>.
/usr/sbin/grub2-bios-setup: info: saving <213633,0,512>.
/usr/sbin/grub2-bios-setup: info: saving <216642,0,512>.
/usr/sbin/grub2-bios-setup: info: saving <216643,0,512>.
/usr/sbin/grub2-bios-setup: info: opening the core image `/mnt/grub-partition/grub2/i386-pc/core.img'.
/usr/sbin/grub2-bios-setup: info: writing 0x400 bytes.

----End----

Appears as if grub has just written 400 bytes, either to the core image or the partition boot sector. It's not clear which.

Panic sets in at this point. Grub has apparently written 400 bytes somewhere, but obviously not to my boot sector. Has it potentially corrupted another sector?

Downloaded & built source and eventually found the following error:
File: grub-core/kern/disc.c
Procedure: grub_disk_write
The following line (or similar) occurs in more than one place:

...
  if ((disk->dev->write) (disk, sector, 1, tmp_buf) != GRUB_ERR_NONE)
    goto finish;
...
 finish:
  return grub_errno;

Here, whilst the procedure correctly stops if the disk write fails, it doesn't record the fact that an error occurred (into grub_errno). The grub_disk_write process therefore returns an apparent success, even though there was a fundamental error.
The user, like me, is left wondering what happened!

I think it would be a good idea to surround both the start and end of the write to the boot partition with comments, so you can see more clearly just what's being done.

Looking further the code, it appeared I had an error 24, which I think is a Not-Implemented error. Does that mean that this sort of set-up, using "blocklists" isn't supported at all anymore? The documentation implies it is, but you have to be careful and use the --force switch (which I did).

Simon <simd>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #26813:  Grub2_dump.txt added by simd (30KiB - text/plain)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by phcoder (Posted a comment)
  • -email is unavailable- added by simd (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-11-03 phcoder StatusNone Fixed
        Open/ClosedOpen Closed
    2012-10-22 simd Attached File- Added Grub2_dump.txt, #26813

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code