Bug#330445: do_initrd message fails in noninteractive install
Hi,
This is a long message, but I have tried conscientiously to
answer every bit addressed in the rpeceding message. I honestly
think that the previous message was very confused, since it seems to
address an on-existent problem (that the ekrnel-image either does not
know it was created to be an initrd image, or that somehow the
location of the initrd image is unknown -- which is not the case).
Given that the previous mesage went at great lengths devising
a solution to a different, non-existent problem, I am at a loss as to
how much of the actuall problem has been discussed below (which is,
does the current lilo.conf or grub's menu.lst or whatever boot loader
is being used -- which could have changed since the time any of the
boot laoders on the machine were installed) are aware that the kernel
iamge to boot has an initrd. Details below.
On Fri, 30 Sep 2005 17:09:12 +0200, Sven Luther <sven.luther@wanadoo.fr> said:
> 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.
There are already bugs filed on kernel-package for debconf
usage -- and this bug has nothing to do with debconf (even with
debconf, kernel images shall not install if doing so may leave the
system hosed).
>> 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.
Feel free. However, unless you come up with a mechanism for
not hosing the user system on install, that would still be an RC bug
for the official kernel image, so I am not sure what you are
buying. If you install an initrd image system willy nilly with out
asking to make sure that the user has added initrd handling in the
boot loader, it still won't get into etch due to the "breaks whole
system" rc bug.
> 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 ?
The bug was assigned from that package to kernel-package, I
merely sent it back. I assume that the original reporter found the
bug in the packages it was originally reported against. Really, you
should stop getting annoyed by bugs reported against packages you are
responsible for.
>> 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
If the debian kernel team is choosing not to cater to the wide
user base that the kernel-package caters to, I see this as a flaw in
the kernel team working.
> 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
Well, really, I am catering to the installed base, and the
users. Am I mistaken in assuming that the desires of the project are
supposed to be exactly that?
> 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 :)
Well, if reducing functionality and choices for the users
makes people dance with joy, I'll probably have to start
de-recommending the official kernels.
>> 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.
Good god, man, the post isnt _does_ indeed know it has an
initrd kernel image. How dense can you get? If you do not have an
initrd kernel image, it does not ask that question. What the postinst
does not know is if the target system is ready for an initrd kernel
image.
Remarks like this make me question if you really know the
details of the issues we seem to be talking about.
> The fact that the /etc/kernel-img.conf is shared between all kernels
> is probably another kernel-package bug in this context.
Why? It isshared between _all_ kernels on the same machine,
yes, but which part of the kernel-img.conf actually fails for this?
Any hook script can be made version dependent, and all the
configuration file is there for is to providehooks and and for some
cross version stuff like symbolic links and reverse symlinks and so
on.
You continually make broad sweeping statements with very
little technical substantiation. Had you ever elaborated on the
technical problem you were trying to solve that the configurations
offered do not meet, rather than these broad
drive-by-vague-insinuations, they would have been addressed.
>> >> > 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.
Removing subarches that are not used is the domain of the
people responsible for them. If you really think that there are
obsolete subarches, and that they interfere with other subarches (abd
why is that?), send me an email.
> 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.
Which oprion in the kernel-img.conf are dependnet on boot
loaders?
link_in_boot, do_symlinks, minimal_swap, no_symlinks,
reverse_symlinks, image_dest, postinst_hook, postrm_hook,
preinst_hook, prerm_hook, src_postinst_hook, headers_postinst_hook,
move_image, clobber_modules, do_bootfloppy, relative_links,
use_hard_links, relink_build_link, force_build_link,
relink_src_link, silent_modules, ignore_depmod_err
Are not related to boot loaders. The following are also not
related to boot loaders directly, they are about initial ram disks,
which can be used by boot laoders:
ramdisk, do_initrd, warn_initrd, mkimage,
The following three options are related to boot loaders,
however, you do not have to use them; you can set them to no
and just do your own thing in a postinst hook
do_boot_enable, do_bootloader, silent_loader,
What kind of maths do you use in which three options out of 29
become "most"? This again makes me question if you even know what
kernel-img.conf is all about, and your rants become just that --
uninformed rants.
> 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.
Well, using debconf would not make the annoying question
disappear, you know. Installing in a chroot is not the common case
for kernel-images; end user systems are.
>> > 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.
debconf setting have nothing to do with the configuration
currently on disk. "Debconf is not a registry". The users can change
their mind about which boot loader to use -- when installed, I used
lilo, since it was set up already. Then I migrated to grub, after
creating grub on a floppy and then testing grub.
Why is it so hard for you to understand that debconf is not to
be used as a registry, and that the situation on the machine may have
changed after the initial install?
>> > 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.
Err, I listen to sound technical solution, not just hand
waving and pretend solutions.
>> > 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.
Debcong is for use in an initial install phase. The users are
free to change configurations at will, post isntall. Kernel images
are designed to be installed at any time, even after an initial
install, and after the stuffon the disk has changed.
> Do you have an alternative proposal of what to use for that ?
Use debconf to ask users questions. Don't rely on the debconf
answer after the initial install. The configuration lives in files in
/etc, not in a debconf database.
>> > 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.
Why am I wrong?
> 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.
Right. That is why the question is being asked: the postinst
knows that the kernel has an initrd, but does not know if lilo/grub
is aware of that.
> 2) The information on where to put the initrd in a way it can be
> loaded is something related to the bootloader.
Correct.
> 3) The information on what bootloader is installed is of the resort
> of the user.
And there can be multiple boot loaders installed. The user
may change which one is currently active by running grub/lilo/whatever
> Do we agree with that, or do you have any kind of problem with that
> ?
Look above.
> 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.
The kernel package already knows this, this is why it is
asking.
The fact you insist that the ekrnel-package needs to know
whether or not there is an initrd also makes me question if
you know what we are talking about, or what the current
behaviour actually is.
How does one tell which boot loader is currently in use? How
does one tell if the configuration of that boot loader is ready for
an initrd?
>> 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.
I am reassigning it 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.
> So, because you believe we cannot have a bootloader policy, we
> should not try to make any effort to fix things for sarge ?
We can have a policy till we are blue in the face. Until we
have actual implementation it is all hot air. And until we have a
technical means for telling what boot loader is active, and querying
the configuration of the active boot loader, this is not anything but
a lot of hand waving.
>> >> 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.
This is not a problem that the question is trying to ascertain
anyway, so this is a distraction. Can you stick tothe point we are
trying to solve? The location of the initrd image is already fixed,
and there is no confusion about that.
> 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.
The location is not the problem.
> 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.
Sure. Except that there is no reason to ever change the
location, so you are solving an non existent problem.
> 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.
Err, this is not something that needs to be fixed.
> 4) They decide to build their own kernel without initrd, and build
> a debianb package of it, the .deb package knows it has no
> initrd (because it was generated without --initrd :), and does
> the right thing.
Grub configuration was changed not to expect or use an initrd,
but otherwise correct.
> 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.
This is not the case. The user has booted their kernel iamge,
and changed the grub configuration. So, now the machine is running a
non-initrd kernel iamge, and the grub configuration does not expect a
initrd image.
> => 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.
What happens if now he is trying to install an image with an
initrd?
>> > 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.
Since this is how you are polite, why do you expect others to
be more polite than you?
>> > 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 ?
Actually, since I had to go hunting for your reposnse (it was
not sent tome by email), no, this is a piss-poor place to do a
design. Sending me email would ensure I was kept int he loop.
manoj
--
Always look over your shoulder because everyone is watching and
plotting against you.
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: