Thanks Dave,
Fixed in grub2-2.00-14.mga3
Please update and test.
Barry

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Installing it as an update fails to copy the file, as the symlink
already exists. In a clean install, it works.

As the updated grub2 didn't make it into the latest (likely last)
build of the beta 2 iso images, it might be better to add the -f
option to the cp command.

Indeed.

Done
Thanks for testing.

Barry

It's back.

Mageia-Default-1280x1024.png -> /usr/share/mga/backgrounds/Mageia-Default-1280x1024.png

The /boot directory must not contain symlinks to /usr.

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

Do you have /boot or /usr on a separate partition now ?

I just made a test net-install with separate /boot partition (in VM) and the file is copied, there is no symlink.

Please give more details on how you installed grub2 so I can try to reproduce.

Keywords: (none) => NEEDINFO

/boot is an ext2 filesystem on sda1.
/ is an ext4 filesystem encrypted on sda6.
grub2 was installed on the mbr of sda.

The install was done by booting
Mageia-3-beta3-LiveCD-GNOME-en-i586-CD.iso
from Thu Feb 28 23:10:00 CET 2013, and then
from the live mode, selecting the install to
hard drive.

Ah OK, it's a problem with the Live isos.

I don't know enough about how the installation from Live works, however it seems that either:-

1. grub2-mageia-theme is not actually being installed on the final system (i.e. it's pre-installed somewhere prior to iso generation and so it's %post is not run in the actual final environment.

OR

2. It's being re-installed in the final environment so it's %post does not see it as an install, (a re-install is seen by rpm as an update).

A workaround for this would be for the Live installer to:

urpme grub2-mageia-theme && urpmi grub2-mageia-theme

Note *NOT* urpmi --replacepkgs grub2-mageia-theme

...although there is probably a much more elegant solution ;)

Priority: Normal => release_blocker
Component: RPM Packages => Installer
Blocks: (none) => 416
Summary: grub2 has symlinks to /usr in /boot => Live iso's do not install grub2 theme correctly as %post is not run in final environment
Whiteboard: 3beta2 => 3beta3
Severity: normal => major

Of course no scripts is run as packages are already installed on the iso.
The live installer just dump the iso contents on the hard disk.

You can easily check if the package is present on the ISO by mountint it, mounting the squashfs, chrooting it, then running rpm -q... squashfs

(In reply to Thierry Vignaud from comment #9)
> Of course no scripts is run as packages are already installed on the iso.
> The live installer just dump the iso contents on the hard disk.

Is there a mechanism in the Live disk creation process for installing certain rpms after the dump by including them in the iso uninstalled, so they can be installed on the real hardware?
I'm guessing that there must be more cases where this is required.
 
> You can easily check if the package is present on the ISO by mountint it,
> mounting the squashfs, chrooting it, then running rpm -q... squashfs

Yes it is.

I'm thinking of maybe adding a small "local rpm repo" on the live medias with grub2 and broadcom-wl rpms.

The other way would be to tell people to add online medias if they want grub2 support

I'm thinking about tagging this bug as invalid!
Why grub2 try to automatically install itself in %post?
This is _VERY_ wrong.
This is the job of drakboot and drakboot indeed does it.

As far as I see, the whole %post should be killed.

This is about grub2-mageia-theme and %post mageia-theme.
Sorry if that was not clear.

However, it now appears that we may have to use a custom background for the grub2 theme in Mageia 3 because the new artwork of the default background is unsuitable without some modification. This would make the whole of %post mageia-theme redundant as the image file could be placed in the package, rather than symlinked or copied as it is now.

So please leave this bug for now until we have decided on the artwork.

/OT
I take your point about %post, however it does only generate one small file (26k) which users find useful when exploring grub2 for the first time.
Many people install grub2 as a standalone package to get the feel of it before using drakboot to install it permanently.
I have spent a lot of time in the forum helping users transition from grub legacy to grub2 and it is useful to have core.img pre-built.
Also, much documentation now also states that it will be there after installing the package.

Re: /OT Sorry that statement was wrong - it does also install itself in /boot/grub2 of course. I was only thinking about core.img.

So are you saying that installing grub2 should not install itself in /boot/grub2?

It's plainly wrong b/c if eg: grub is on the VBR instead of the MBR, grub2 will overwrite it.

Either users are not gurus and will use drakboot or they're experts and they should know what to do.
We've unified management for lilo/grub/grub2 so grub2 shouldn't re-imagine system management.

As for grub2-mageia-theme:
1) this has no reason to be there:
  "Remove trailing blank lines from /etc/default/grub"
2) same for "Check that /etc/default/grub ends in a linefeed"
3) it's overly complex.
Why not just:
ln /usr/share/mga/backgrounds/Mageia-Default-1280x1024.png||\
cp -f /usr/share/mga/backgrounds/Mageia-Default-1280x1024.png /boot/grub2/themes/maggy

or just do the simple cp instead of playing with root, boot & usr partitions
That's basically what does /usr/sbin/grub-gfxmenu for grub

(In reply to Thierry Vignaud from comment #15)
On 06/03/13 17:39, Thierry Vignaud wrote:
> It's plainly wrong b/c if eg: grub is on the VBR instead of the MBR, grub2 will
> overwrite it.

I never heard of "VBR", but if you mean "is installed to the root partition boot sector", then it will not overwrite it at all.
Grub2 does not attempt to write to the partition boot sector with that command - it simply writes /boot/grub2/i386-pc/core.img.
I have regularly had grub legacy installed in the PBR and either chainloaded legacy or multibooted grub2 (into core.img) without any change to the system whatsoever. They can co-exist this way - in fact it's a handy boot system backup to have both installed.

> Either users are not gurus and will use drakboot or they're experts and they
> should know what to do.

Or they are just cautious and would like to test grub2 without committing to it

> We've unified management for lilo/grub/grub2 so grub2 shouldn't re-imagine
> system management.

Well yes *now* you have and it's looking good, but for the last year grub2 has not been integrated at all and I have tried to make installation and testing as simple as possible to encourage users to try it.
I agree that with integration there is less need for it to do some things for itself, but as long as these do not interfere with the integrated operation, then I see no need to remove them either.
>
> As for grub2-mageia-theme:
> 1) this has no reason to be there:
>    "Remove trailing blank lines from /etc/default/grub"
> 2) same for "Check that /etc/default/grub ends in a linefeed"
> 3) it's overly complex.

Since /etc/default/grub is user editable and all the howtos for grub2 flying around promote this, the above was my attempt to avoid breakages.

I recently broke it myself by closing the file with no trailing linefeed. When I subsequently installed grub2-mageia-theme the theme line was appended on the same line as the existing last line.
Uninstalling the theme can leave an empty blank line, so again the above is my attempt to avoid this.
You could probably do it with more compact code - but mine does work ;)

> Why not just:
> ln /usr/share/mga/backgrounds/Mageia-Default-1280x1024.png||\
> cp -f /usr/share/mga/backgrounds/Mageia-Default-1280x1024.png
> /boot/grub2/themes/maggy

Because IIANM that would always link the file since at package install time / is mounted and decrypted and /boot and /usr are mounted.
My checking of /usr and /boot partitions was to see if / and /usr would both be available at boot time. If either / was encrypted (/boot on separate partition)  or /usr was on a separate partition the background image file needed to be copied, otherwise it could be linked.
>
> or just do the simple cp instead of playing with root, boot & usr partitions
> That's basically what does /usr/sbin/grub-gfxmenu for grub
>
I was trying to save space by not copying the file when it's not necessary.
However, I am just about to push an update which includes the file in the package, since it will have to be a modified image for Mageia 3, so the symlink option will no longer exist. I am applying the change to the current version now before updating the theme nearer release.

Barry

Fixed in svn.

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED