Comment 28 for bug 439784

I have not confirmed this yet by looking at any code, but the reason that grubenv is ending up zero bytes is likely that some code is writing to grubenv ( from linux, not grub itself ) by doing something like: write file "grubenv.tmp"; unlink file "grubenv"; rename "grubenv.tmp" , "grubenv". The reason this is likely being done is that /boot/grub/grubenv is read only. The problem is that unless in data=ordered mode ext* ( this affects ext3 also now that ordered mode is not default ) will sometimes write metadata before data. The work around to prevent zero byte files was to implicitly fsync when renaming over an existing file; because the code is unlinking grubenv first this implicit fsync is not triggered.

To fix this you could either temporarily make grubenv writable and do the standard write new file then rename over old or do: write /boot/grub/grubenv.tmp; fdatasync /boot/grub/grubenv.tmp; unlink /boot/grub/grubenv; rename /boot/grub/grubenv.tmp to /boot/grub/grubenv; fsync /boot/grub/ .

Even if that is not the cause of the problem I don't see how checking for a zero byte file during init is a fix since this bug will prevent users from getting to init in the first place, but I am likely just not understanding something.