Re: Bug#330445: do_initrd message fails in noninteractive install
On Fri, Sep 30, 2005 at 01:47:47PM -0500, Manoj Srivastava wrote:
> 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).
Just because you fail to see the problem, it doesn't mean there is no problem.
> 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.
Well, you cannot deny that any kernel built with make-kpkg could be made aware
if it is a initrd kernel or not.
> On Fri, 30 Sep 2005 17:09:12 +0200, Sven Luther <sven.luther@wanadoo.fr> said:
>
> >> 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
It would not be, since we will do the right thing :)
> 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.
Well, why do you want to ask the user to configure stuff manually, if you know
what configuration is needed you just have to set it by hand, at least in high
priority of debconf.
> > 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
The bug was filled in a funny format, it was filled against three coma
separated packages, not sure how this is handled by the BTS.
> 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.
Well, i replied to the bug under the linux-2.6 umbrella, and really was
surprised (and a bit pissed i must say) when you reassigned it such, to a
place none of the debian kernel team will ever read ?
And it *IS* a kernel-package bug, even if you deny it.
> >> 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.
yeah, sure, i am sure weall appreciate your comments, in the meantime you are
not really caring for all the debian users, but just the little subset who has
the same needs as you.
> > 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?
Well, you *think* you are catering to them, but you plainly ignore a request
from such an installed base, and defaults to putting the blame to others.
> > 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.
Getting rid of the continuous pain and breakage that is using kernel-package
and having to adapt to his misbehaviors is certainly something some would be
delighted for. I believe that using kernel-package is the best idea though,
but if you are going to go all rigid over the stuff, and not cooperate with
the debian kernel team and refuse to even consider perfectly valid requests, i
doubt it is a good idea to continue using kernel-package at all.
> >> 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.
Ah, yes ? And when is the postinst generated ? When you build the package ?
How can you be so dense as to not see this most trivial of things, and you
supposedly wrote that software. I guess we better get ride of it as quickly as
possible in these conditions.
> Remarks like this make me question if you really know the
> details of the issues we seem to be talking about.
Yeah, i know you well, i believe you perfectly know what we are speaking
about, and that you are playing the ignorant in order to denigrate me, you
already did this in the paste, and i don't appreciate at all.
> > 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?
What if you have a initrd kernel and a non initrd kernel, and you want to boot
both alternatively ?
> 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.
Indeed, but what are we going to put in those hooks ?
> 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.
bah, you just try to play stupid and ignore any arguments because they don't
suite you.
And for your info, i am actually working writing firmware code, so you can
hardly accuse me of having no clue of what is needed to boot a system :)
> > 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.
No, they don't interfer with what we need, so they can stay, for now.
They are mostly just useless cruft though.
> > 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 and other symlink stuff is dependent of if the bootloader can
follow symlink, and also on which kind of filesystem the firmware/bootloader
is able to boot from. The bootfloppy stuff is also influenced with the way you
boot the machine to a degree.
> 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,
indeed. We have to see how this things will survive the initrd-tools to
initramfs migration, and if we can do more funny tricks that initramfs allows.
> 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.
Ha, what happens if you count those that are actually installed by default on
debian systems ? debootstrap itself doesn't even set those values, and a clean
sarge install has maybe 5 values in that file.
> > 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.
Ah, but it allows to handle priorities, and most of all, it allows to show
those questions to user during d-i installs, instead of just dying like it
happens now.
> > 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.
Sure, which is why we need the cooperation from the bootloaders, and a real
policy for this.
> 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?
Sure, then we use debconf to ask questions to user, and we use another file to
handle the information with all packages.
> > 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.
You don't listen at all.
> >> 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.
So, instead of making sure the kernel .deb tells lilo/grub about this, you ask
the user to tell lilo/grub. You know, we are no more in the stone age, and
computers are there for making the task easier for the users.
> > 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
This is why it is important to know both the list of installed bootloaders,
and the one which is used. The user has to provide this information, and after
all it is HE who makes this choice. The system can default to something sane
even, and the user who doesn't care will not even know about it.
> > Do we agree with that, or do you have any kind of problem with that
> > ?
>
> Look above.
Well.
> > 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.
Then why does it not tell the bootloaders instead of asking the user ?
> 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.
You are the one claiming that there is no way to know if there is an initrd or
not. So, now you are saying the opposite and blaming me ?
> 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?
Well, i think i replied to that already numerous times, it is not my fault if
you don't want to know, or only try to make me ridicoulous by playing the one
who doesn't understand.
> >> 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.
Yeah, yeah, i guess you also didn't see where it came from :
Package: linux-image-2.6.12-1-powerpc,linux-kernel-di-powerpc-2.6,kernel-package
I also have no clue why it was filled like that.
> > 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.
Bah, whatever, first you make the specification of the thingy, or the policy
in this case, and then you implement the solution, with the force of the
commonly decided thingy. That is how proper software design works.
You can hardly propose an implementation in this case where more than a single
developer or group of developers is concerned.
> >> >> 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.
Ah, yeah ? so why are you complaining loudly about it ?
> > 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.
it will always be in boot ? The location is always known, and the bootloader
only know if they need an initrd or not ? So why are you making such a fuss ?
> > 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.
Well, you brang this up, it is your example, so why do you confuse the issue
by mentioning stuff you believe are no problem ?
> > 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.
So ? If the user muck around by hand there is no way any automated thingy can
work, the user has to play by the rules also.
> > => 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?
Well, he is installing a hand built kernel with an initrd. Since it is a
handbuild kernel, he tells the database that version so and so of his hand
built (not with make-kpkg) kernel needs an initrd. and the system does 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.
>
> Since this is how you are polite, why do you expect others to
> be more polite than you?
i think there is a qualitative difference between your "faugh" and saying that
the above is pure nonsense, since you put the blame on debian-installer, which
has scarcely anything to do in the scenarios we are contemplating here.
But then, maybe we don't speak the same english ...
> >> > 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.
Ah, i had hoped that as a maintainer you would be responsible enough to read
the bug reports against your packages, but then i beleive the problem was
because you decided to reassign it to some random package just to get ride of
it, and furthermore i did a group reply, so you would have been CCed if you
had not mucked with your email setting, or maybe you are using one of those
blacklister, which block half the ISPs of the planet.
In any case, if you didn't read my reply, it is your own pure fault.
Friendly,
Sven Luther
Reply to: