Re: grub-installer/grub2_instead_of_grub_legacy template
Am Donnerstag, den 30.07.2009, 11:42 +0200 schrieb Frans Pop:
> On Thursday 30 July 2009, Felix Zielcke wrote:
> > Unfortunately I'm not a sed expert but that should be easy to fix.
> >
> > if [ "$defopt_params" ]; then
> > sed -i "s!^\(# defoptions=.*\)!\1 $defopt_params!"
> > $ROOT/boot/grub/$menu_file fi
> > if [ "$kopt_params" ]; then
> > sed -i "s!^\(# kopt=.*\)!\1 $kopt_params!"
> > $ROOT/boot/grub/$menu_file fi
> >
> > That needs to be only modified to change GRUB_CMDLINE_LINUX_DEFAULT=""
> > and GRUB_CMDLINE_LINUX="" in $ROOT/etc/default/grub
>
> See recent discussion started by Colin about the problem that D-I is
> normally not allowed to change the config files of other applications.
> That issue needs to be resolved.
Where?
In 533287 message #53 he says:
Let's discount the question of /etc/default/grub; it's not at issue
here, and the solution you're using now for it is not questionable
AFAICS.
On the debian-policy mailing list there isn't either a reply to this.
We use now ucf for it, so the problem is solved now AFAICS.
> > What other known issues?
>
> See the meta BR...
Uhm maybe we are talking about different things?
I don't want to argue if we should make grub2 now the default or not.
I only want to change the template that it doestn't say anymore
experimental software.
I don't know Ubuntu that much, but do they actually use high
experimental software as default in their main repository and not
universe/multiverse?
Serious question.
The meta BR says:
Fix blocked by 470894: grub-installer: user parameters are not added to
grub.cfg for grub2, 477090: grub-installer: no support for dmraid and
multipath for grub2, 477092: grub-installer: does not support setting
password for grub2, 483971: support for device-mapper multipath
470894 can be solved and all others can be mentioned in the template as
I already said.
> One other is no support for bootloader password, but I guess that is
> something that could be accepted as it is only an expert option.
As I said now twice, we can mention that in the template.
Why doesn't it do this already if that's so important to people?
They should know that then if we offer them the choice about grub-legacy
or grub2.
> But all basic functionality should be there, and respecting boot
> parameters (also quiet and vga=) is very much basic functionality.
Ok vga= is for some people a problem with the new linux loader.
But upstream's solution for this is a gfxpayload variable which is in
the form hightxwidth,depth, like 1024x768x32
> > The initial template is from August 2006.
> > At that time I even didn't know grub2 exists, but I can image that it
> > was really experimental at that time. We fixed a bunch of bugs since I
> > joined.
>
> The question is not if grub2 itself is still experimental, but that its
> integration in D-I is incomplete, which makes its use *in D-I*
> experimental. Users should be able to expect no regressions relative to
> grub when the switch is made.
Then the templete should say that the integration into D-I is
experimental (or not complete) not that grub2 itself is experimental
software.
> > Probable you didn't recently (!) tried out grub2, did you?
>
> No. Why should I have? I _know_ that grub2 has been improving, but I also
> know that nothing has been done to complete its integration in D-I.
If you don't have any problems with grub-legacy or need/want
savedefault/fallback support you don't need to.
But it case it breaks it can be sometimes easier to fix, because it has
for example an `ls' command.
You can use grub-emu to get a small impression of the commandline, it's
included in grub-common which grub-legacy depends on since lenny.
> > > P.S. Please do not CC me on replies. It should be obvious that I read
> > > the list. See the Debian mailing list code of conduct.
> >
> > Sorry but why does the list has a stand reply to the sender instead of
> > to the list?
>
> It does not. That is something your MUA is responsible for: it should
> recognize that a mail is list mail (based on headers) and act accordingly
> (although different lists/communities do have different policies).
> Kmail automatically replies correctly only to the list.
>
Well on the upstream grub-devel list, the Reply-To is correctly set to
the list. So this is something configurable with the list software.
But okay on -project and -devel it's the same so seems like on Debian
this isn't wanted by default for dumb MUAs like Evolution.
I file a wishlist report about it.
--
Felix Zielcke
Proud Debian Maintainer
Reply to: