Re: Bug#330445: do_initrd message fails in noninteractive install
retitle 330445 Let's stop using kernel-package for official kernels
reassign 330445 linux-2.6
severity 330445 wishlist
thanks.
On Fri, Sep 30, 2005 at 09:10:44AM -0500, Manoj Srivastava wrote:
> 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).
Well, I disagree, this is not expected behavior, and i think any package which
asks user questions without going through debconf was supposed to be buggy
already for sarge, let alone for etch.
> So, this is a kernel-package feature, not a bug :P
It is indeed a bug, but hey, if you really think it is a feature, probably
the best solution will be for the official kernels to drop kernel-package and
do their own stuff, so retitling the bug accordyingly.
Also, Manoj, why in hell did you chose to reassign this bug to
linux-kernel-di-powerpc-2.6, which is a group of .udebs without any such logic
and doesn't even remotely have any link to kernel-package, was it just to anoy
me or something ? If this is so, i think i am expecting some apologizes from
you, but i believe it was only a mistake on your part ?
> 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).
Whatever, but this is not the choice of the debian kernel team, nor of the
debian-installer team, so if you run your own kernels and want a
kernel-package which suits your own need, without caring about what the need
of the debian project is, then i think there is no more reason for the debian
kernel team to use kernel-package to build the official kernels. I know some
people who will dance with joy if we go this way :)
> If you think the initrd question is useless, I don't think you
> have thought through real world scenarios and use cases.
Well, i guess that if you produce a initrd kernel with the --initrd option to
make-kpkg, then make-kpkg has all the logic to know that it needs an initrd,
and can produce suitable postinst scripts which do the right thing.
The fact that the /etc/kernel-img.conf is shared between all kernels is
probably another kernel-package bug in this context.
> >> > 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.
Most problems are from having bootloaders installed that are not used, others
are for having subarch targets in kernel-package that nobody used for ages, so
i think removing the old cruft and keeping only the newer powerpc and
powerpc64 targets should work just fine.
Also, notice that most of the /etc/kernel-img.conf options are highly
dependent on the bootloaders, and if one uses more than one bootloader on the
same machine, there should be problems.
The case is that the kernel-package code used to break frequently during the
sarge d-i development phase, since it was not using debconf for its questions,
and random questions came up until the setting of the kernel-img.conf entries
was nicely set. I only get breakage when i build chroots with debootstrap now,
and need to install a kernel to build kernel .udebs from it or for another
reason, and get asked about this anoying initrd thingy.
> > 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?
See above.
> >> > 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?
Both grub and lilo are installed, both have debconf logic, and add themselves
to the list of boot-loaders listed in the debconf database, and ask you which
one you prefer to use. Then the kernel package postinst can easily enough
query that debconf setting and do the right thing.
> > 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.
Unless the people you are trying to explain it to just decide not to care
about hearing any kind of explanation, and dismiss it from the start because
it doesn't suit them.
> > 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?
And what is it for then ? We can use our own /etc/bootloaders list then or
something, but if you read at the debconf documentation, it has explicit
instructions on how to set up this kind of things, using some windows manager
setup or something.
Do you have an alternative proposal of what to use for that ?
> > 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
Please stay polite, ok ?
> 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.
This is where you are oh so wrong, and i am very surprised because it is not
like you to be so small-minded.
Anyway.
1) The information of if there is a initrd or not is something related to
the kernel used, since you build the kernel image with either the --initrd
option or not.
2) The information on where to put the initrd in a way it can be loaded is
something related to the bootloader.
3) The information on what bootloader is installed is of the resort of the
user.
Do we agree with that, or do you have any kind of problem with that ?
So, i believe that any neat solution to the problem will be to let each part
be responsible of what he knows about, the kernel package to know it has to
generate an initrd or not, the bootloader to know where he has to put it, and
the user to chose the bootloader he is installing.
> 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.
you are reassigning it to some random package without thought.
> >> 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.
So, because you believe we cannot have a bootloader policy, we should not try
to make any effort to fix things for sarge ?
> >> 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 believe i have, and you probably would have seen it if you had looked at it
positively, since i believe that you are a rather brillant person, but let's
go at it.
1) A user did an initial installation, using lilo and an initrd kernel.
=> Lilo provides information to the system, either through debconf or
another system of where the initrd should go. The kernel informs the system
that it needs to generate an initrd. The kernel postinst script gets the
information from lilo of the kernel location, and from the kernel that it
needs an initrd, and does the right thing.
2) Later the user decides to switch to grub.
=> grub is now the default bootloader, and the information on where the
initrd goes change. The user didn't upgrade the kernel, so during the grub
the changing of the default bootloader, a script makes sure the initrd is
moved to the right place or something.
Note: This could happen either when the choice is made to switch, and the
user is left to run grub by hand, or the bootloader scripts should provide
logic for a hook system and running grub itself cause an invocation of this
hook which does the right thing and moves the initrd and such.
3) The user changed the disk around. I am not sure about this one, could you
please explain more in detail the exact situation ? I mean i am used to
firmwares which are not discriminate in where they boot of, and have little
experience with limited functionality ones like the x86 stuff.
4) They decide to build their own kernel without initrd, and build a debian
package of it, the .deb package knows it has no initrd (because it was
generated without --initrd :), and does the right thing.
5) The user decides to use a self generated kernel. Frankly, this is not
something that debian officially supports, and it should be ok to leave the
user alone in this case, he can write the lilo/grub configuration just fine
in this way, and also do the lilo/grub invocation by hand, and if it fails,
it is his own problem.
=> Neverthless, we can support this situation also by providing some kind of
user-config in the database, where the user points his kernel too, and his
initrd status, and the rest of the scripts would still do the right thing.
> > 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.
you are speakign pure nonsense here.
> > 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.
Hehe, well, and you don't think a bug report is a good place to discuss this,
right ?
Friendly,
Sven Luther
Reply to: