update-grub fails on kernel install or remove

Bug Description

Binary package hint: grub

I have my shell configured with "set -o noclobber", which I think causes the failure during kernel installation. Please see log snippet at the end.

This happened during update to Gutsy, and in a subsequent kernel removal. I redid the kernel install from a clean root shell (without the noclobber), and it worked fine.

From apt log:
update-initramfs: Generating /boot/initrd.img-2.6.22-14-generic
63.5%
Running postinst hook script /sbin/update-grub.
Searching for GRUB installation directory ... found: /boot/grub
/usr/sbin/update-grub: line 383: /tmp/fileP9xio4: cannot overwrite existing file
User postinst hook script [/sbin/update-grub] exited with value 1
dpkg: error processing linux-image-2.6.22-14-generic (--configure):

This one can be easily fixed, on line 383 replace
cat > "$newtemplate" <<EOF
with
cat >| "$newtemplate" <<EOF

There may be more instances of this problem though (trying to redirect to an existing file).

You should use the "sudo" command to run install commands. Do not use a root shell, and above all, do not configure the root shell in any way.

Hardly any scripts are meant to be used with "noclobber".

I can see that it's hard to noclobber-proof all scripts, but the problem is that running a simple sudo appears to pass the noclobber setting in my shell to the resulting command (synaptic in this case). It is kind of odd, but this is what happens in my case. I haven't touched root settings, and as I said running in a fresh root login works fine (noclobber is not set). Using the -i option to sudo should help, but it's not standard.

If you use the synaptic GUI you should not use sudo, but just start it from the Administration menu. Does it still pick up your noclobber setting? This is in your .bashrc?

Since the file is created with "tempfile" in line 382, we can safely use ">>" as well.

Tormod Volden wrote:
> If you use the synaptic GUI you should not use sudo, but just start it
> from the Administration menu. Does it still pick up your noclobber
> setting? This is in your .bashrc?

Yes, it's in my .bashrc. But I also noticed something else unusual - I
export BASH_ENV=~/.bashrc. And, this survives into the environment of
"gksu synaptic", thus setting noclobber in every shell spawned by
synaptic. This may be a fairly rare configuration, and thus people
haven't seen the problem much.

Without that export of BASH_ENV, the noclobber is not propagated and
update-grub works.

gksu has a --preserve-env option which is not used in this case, so I guess gksu should have sanitized its environment. I keep the "grub" task open, so that I remember to fool-proof (clobber-proof) it anyway.

Can someone please push this patch to the grub bzr repository?

BTW, I tried to make a bzr merge directive, but the grub repo "needs bzr 0.92" and I have 0.90 on this Gutsy machine :(

Yes, sorry, the bzr repo made use of some fairly cutting-edge functionality to merge the upstream and Debian branches, so it's not surprising that it doesn't work with the gutsy version of bzr.

As for pushing the patch, I'd looked at this bug before and was unconvinced that this is a bug that warrants fixing in update-grub. "noclobber" is really just not supposed to get set for system scripts, and I think that's the real bug here; we could fix update-grub now to be safe under noclobber, but how many more times would we have to play whack-a-mole with scripts on the system that don't work under noclobber?

For comparison, this same 'noclobber' issue was discussed in Debian several years ago in connection to another package, and the conclusion was that having "noclobber" set in such a way that it's inherited by package scripts is unsupported: http://bugs.debian.org/275140

And the recommendation from <http://bugs.debian.org/cgi-bin/275140#37> is that "set -o noclobber" should be guarded by if [ -n "$PS1" ].

Alex, does changing your .bashrc in this manner give you the desired behavior?

I agree we should not try to noclobber-safe all scripts, but in this case it's as valid to use >> as > since we know it's an empty file.

Steve Langasek wrote:

> And the recommendation from <http://bugs.debian.org/cgi-bin/275140#37>
> is that "set -o noclobber" should be guarded by if [ -n "$PS1" ].
>
> Alex, does changing your .bashrc in this manner give you the desired
> behavior?

Yes, with that arrangement there is no problem. It seems a reasonable
solution. I don't know if this is documented more visibly than the debian
bug report, but it would seem useful to have it mentioned, as noclobber is a
sensible option to enable if you use the shell much.

Thanks!

alex

ok, I've committed this change to the grub repository - it's trivial either way, so not worth the trouble of arguing. ;)

This bug was fixed in the package grub - 0.97-29ubuntu19

---------------
grub (0.97-29ubuntu19) hardy; urgency=low

[ David Futcher ]
* debian/presubj: Fixed spelling mistake (LP: #177540)

[ Tormod Volden ]
* debian/update-grub: use >> instead of > when writing to existing files
so that the script continues to work if noclobber is set. LP: #155423

[ Steve Langasek ]
* debian/patches/ext3_256byte_inode.diff: new patch cherry-picked from
Debian to support 256-byte inodes in ext3, for compatibility with recent
e2fsprogs upstream defaults. Thanks Stefan Lippers-Hollmann.

-- Steve Langasek <email address hidden> 2008年3月19日 12:12:40 -0700

Closing the gksu task for this fixed bug.