Re: Bug#330445: do_initrd message fails in noninteractive install

[Manoj Srivastava <srivasta@debian.org (va, manoj)>]

reassign 330445 linux-kernel-di-powerpc-2.6
thanks

        Please read on below for an explanation why this is not a
 kernel-package issue. The solutions being proposed now call for a
 grand plan betweeen all known boot loaders, and boot loader
 configuration, and automated discovery of boot loader
 configurations -- and until something like that is in place, it is
 not buggy for kernel package generated images to fail to install
 unless a human has indicated it is ok (otherwise the system may be
 rendered unbootable).

        So, this is a kernel-package feature, not a bug :P

On Thu, 29 Sep 2005 03:27:54 +0200, Sven Luther <sven.luther@wanadoo.fr> said: 

> On Wed, Sep 28, 2005 at 03:33:34PM -0500, Manoj Srivastava wrote:
>> On Wed, 28 Sep 2005 21:15:59 +0200, Sven Luther
>> <sven.luther@wanadoo.fr> said:
>> > Ah, you are wrong, if the scripts where using debconf, then you
>> > could preseed it, or use the non-interactive mode or whatever.
>> 
>> Wrong, eh? Indeed, it is you who have no idea whast is being talked
>> about here. Even if debconf is used, the kernel image can choose to
>> abort install unless a human answers the question, and that is
>> likely to be what shall happen when I code debconf in.

> Ok, well, but from my experience with d-i and kernel installation,
> those questions which usually show up (at least on a powerpc
> install), where hardly of the kind that could no be worked around,
> especially since the installer knew better than the user about
> those.

        The installer does not know better then the user whether or
 not initrd's are supported in the boot loader -- and definitely not
 in the general, real world case. And the idea is to cater to as many
 user as we can, not just the case of ourselves (I, for example, never
 ever use initrd's on my production boxes).

        If you think the initrd question is useless, I don't think you
 have thought through real world scenarios and use cases.

>> > The current questions are mostly worthless (at least on powerpc)
>> > anyway, and are just an annoyance that should go away.
>> 
>> Opinions with no rationale are unlikely to sway me on this.

> The powerpc scripts are outdated and have no relationship to
> reallity since a couple of years. I end up being asked about quik
> and such on my pegasos machine, which is pretty annoying. I know
> this is partly my fault, since i didn't take time to fix this
> correctly, but i guess now is the time to solve this, possibly in
> conjunction with said bootloaders and the kernel team.

        Since I do not have a  powerpc  machine, it is hard for me to
 tell what the problems are. Some of them, if memory serves me right,
 are from an attempt to ship a generic, unusable kernel image in
 powerpc, and on the fly create an usable vmlinuz -- which is an
 unusual situation, and most of that has not been designed by me. I
 would be happy to have a look at a solution for powerpc instead of
 delegating that to the architecture people.

> The same seems to happen about the link in boot and other such
> options, which with the new kernels may or not be still uptodate
> default choices, at least i heard some comments about this earlier.

        I have no idea what you are talking about here. Can you
 elaborate? 

>> > I believe that the kernel package should work out of the box and
>> > not need manual intervention to set the initrd thingy, since the
>> > kernel image knows perfectly that it needs an initrd or not, so
>> > why have it have the logic to know about it and tell the user
>> > instead of just doing the right thing ?
>> 
>> Again, you seem to be missing the point. Some boot loaders require
>> intervention before they can handle initrd images (indeed, booth
>> grub and lilo do, as far as I can tell).  Unfortunately, it is

> No, i know this perfectly. What i am saying is that in most cases,
> the bootloader maintainer and the kernel-package/kernel-team
> maintainers know more about this kind of thing than the end user,
> and are able to make the right choice.

        I maintain you still do not know what you are talking about
 here. How can the boot loader maintainers and kernel team maintainers
 know about, say, my machines, which usually have both grub and lilo
 installed? How would you know if I have initrd turned on or not?

> This is something which i have been thinking about for a while, and
> it is my profund conviction that the solution is one where the
> bootloaderis, the kernel packages and kernel-package need to be
> working together better, since between themselves those have the
> knowledge you point out above, and if there is user intervention
> needed, the choices can be added to the debconf database once and
> for all, with varrying degree of questions and default depending on
> the priority.

        Having a profound conviction is nice. Have a technical
 solution is better.

> Each bootloader would provide a debconf hook to be chosed as default
> bootloader, and it will know what to do to make the kernel and
> initrd installable, and provide the adequate kernel post-inst hooks
> for it to work.  The user, if he installed more than one bootloader,
> will be able to chose in debconf the bootloader which is going to be
> active, and this one will do the right thing.

        What part of "Debconf is not a registry" is so hard to
 understand? 

> It needs some maturation, experimenting, and implementation, but i
> have the strong believe this is the right solution, and would solve
> all those issues.

        Maturation? Faugh. Say, user A installed lilo. During
 installation, had initrd turned on, perhaps even using debconf.They
 then installed grub, again with initrd turnd on. ASfter a bit, they
 overwrote the boot loader in /dev/hda3 (which is /booot, and toggled
 bootable using fdisk).  Then, they started using their own kernel,
 and turned off initrd's in /boot/grub/menu.lst.


        How can you discover this reliably, using just debconf?

>> not feasible to know what boot loader is being used (I have both
>> grub and lilo on my machines), nor is it feasible to tell whether
>> the boot

> In today's setup, you are right :), but i believe we should be able
> to come up with somewhat better for etch if we start soon enough.

        So, in todays set up, this is not a bug in kernel-package, so
 I am reassigning this back to where it came from.


>> loader can handle initrd's -- and no way am I goona add bunches of
>> code to parse every tom dick and harry bootloader config script.

> Indeed, but if the bootloaders provided those ?

        Err , sure -- depending on boot loaderes know about this? And
 which boot loader scrip in the example above should I trust? Frank;y,
 this is not a workable idea right now. 

>> As I have said elsewhere in this report, working correctly, and not
>> rendering the system unbootable, trumps non-interactive installs.

> Indeed, but let's try to do the right thing and allow both for etch,
> i believe it is possible, altough there may be issues you have more
> experience with and which i may have missed which may make the above
> plan not work, but i believe it is the right way to solve those
> issues.

        Indeed. Come up with a solution that works for the scenario I
 have given above, and we may be getting somewhere.

>> > I think now is the moment to think about the futur of
>> > kernel-package, and what will happen to it for etch. Could you
>> > tell us a bit more about what your plans are for that ?
>> 
>> My plans are not to remove functionality that makes it easy for
>> novices to use packaged kernel images.

> :)

> The alternative being the official kernels doing their own stuff,
> which i believe is not the aim here.

>> So, debconf or no debconf, there is no surety that kernel images
>> shall install when debconf frontend is set to non interactive --
>> unless there is some way to dete t that proceed shal not hose the
>> end user system.

> Indeed, but debconf and a proper large-scale plan should be able to
> solve this where kernel-package alone could not.

        Good. When such a plan, and a workable one, is in place, feel
 free to open a wishlist bug against kernel-package. At this point,
 however, it is the debian installer that is buggy.

> This is also the logical continuation of the work done by the kernel
> team, and i hope you can add your experience and knowledge to help
> us evolute this in the best possible solution for etch.

        I have always answered emails sent to me. I would also prefer
 to start working with the problem statement, not with a proposed fait
 accompli, since there are times, like now, where I consider the
 proposed solution as being suboptimal when it comes to kernel
 packaging --- but I have been doing this for ten years.


        manoj
-- 
Dreams are free, but there's a small charge for alterations.
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C