[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#636123: "fixed" the problem: broken/missing dependency



On Tue, Aug 2, 2011 at 12:44 AM, Ben Hutchings <ben@decadent.org.uk> wrote:
> On Sun, 2011-07-31 at 14:37 +0100, Luke Kenneth Casson Leighton wrote:
>> ok - i've established the cause of the failure: incorrect dependencies
>> in linux-image-2.6.39-2-amd64.
>
> This is not relevant.  The kernel does not depend on a userland library.

 yeah... i did wonder about that.  unfortunately, i've demonstrated
otherwise.  if you have an older version of the userland libraries and
userland applications, it don't boot.  if you do, it works.  ergo,
there's a dependency, and that really is the end of it.  now, neither
you nor i may _like_ the fact that there is a dependency between the
linux kernel and a userland library in order to have a successful
boot, but like or dislike has absolutely nothing to do with the
reality of empirically observed results.

 i didn't say it would be easy to solve this!  i don't believe there's
an "optional" debian dependency-specifier.  yes there's "Recommends",
yes there's "Suggested", yes there's "Depends", but there isn't
"If-Installed-Needs-to-be-At-Least-This-Version:", is there?

 which is actually what's required here. "if you have package X, _and_
you have package Y, then if you upgrade package X, package Y must be
upgraded to at least version N.N.  but, if you don't have package Y
installed, and you upgrade package X, then it all doesn't matter".

 if that happens to be describing "Suggests", then great!  but... i
don't believe it is, is it?


> Previously you wrote:
>> ** Kernel log: boot messages should be attached
>> not possible.  very simple: no root filesystem found.  ergo, kernel panic.
>> works absolutely fine on 2.6.32 standard debian kernel.
>
> It is neither 'not possible' nor 'very simple'.  Send us the messages.

 that would involve de-installing / reverting the list of packages
installed.  which would involve finding them, first (debian/testing),
probably from source, because debian/testing is a moving target and i
last updated 3 months ago.

 also - the last time i did a de-install / revert of some debian
packages i got told i was being a fucking idiot (summary) and that
everything i'd done in order to actually help do some testing and to
get some results was "non-standard", not "The Debian Way", that i must
have fucked up my system, that reverting debian packages was "not
supported", and on this basis the bugreport was declared "totally
invalid" and the package maintainer felt totally justified in
completely ignoring the information provided and in closing the
bugreport.

 so you'll forgive me if i don't go down that route, eh?

 the other alternative is hypno-regression to put me into a trance
state so that i can pretend i have a photographic memory and recall
verbatim what i saw.

 perhaps an easier way is to "make up" the exact same messages
received, such as by booting a system with a non-existent root
filesystem.  you will get exactly the same messages that i saw.
"error, no root file system found" and then a kernel panic stack trace
with about 5 lines in it.


 anyway.  let's try and go over this.

 * 3-6 months ago i install 2.6.32-trunk-amd64.  it work great.
 * two days ago - installing 2.6.39, an initrd was created
 * the initrd contains LVM lookup stuff.
 * the initrd also contains libdevmapper1.02.so
 * libdevmapper didn't do its job.
 * bootup barfed, unable to find root file system.
 * boot back with 2.6.32
 * i upgraded libdevmapper
 * i upgraded grub
 * the upgrade of grub fired off re-creation of the initrd
 * a new version of libdevmapper got shoved in the initrd
 * system boot wurk now, it all peachy.

that's the sequence of events.

ergo, there's a dependency.

l.



Reply to: