Debian Bug report logs - #349354
initramfs-tools - kernel -udev dependency loop

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: "Nikita V. Youshchenko" <yoush@debian.org>

To: submit@bugs.debian.org

Subject: initramfs-tools - kernel -udev dependency loop

Date: Sun, 22 Jan 2006 17:27:43 +0300

[Message part 1 (text/plain, inline)]

Package: initramfs-tools,kernel,udev

Currently:

  - recent linux-image packages depend on 'initramfs-tools | yaird | 
linux-initramfs-tool', so initramfs-tools is the 'default' alternative

  - initramfs-tools depends on recent udev

  - recent udev refuses to install unless recent kernel is running

This loop needs to be broken somehow.

  

[Message part 2 (application/pgp-signature, inline)]

Message #10 received at 349354@bugs.debian.org (full text, mbox, reply):

From: Sven Luther <sven.luther@wanadoo.fr>

To: "Nikita V. Youshchenko" <yoush@debian.org>, 349354@bugs.debian.org

Subject: Re: Bug#349354: initramfs-tools - kernel -udev dependency loop

Date: Fri, 27 Jan 2006 20:13:00 +0100

severity 349354 critical
thanks
On Sun, Jan 22, 2006 at 05:27:43PM +0300, Nikita V. Youshchenko wrote:
> Package: initramfs-tools,kernel,udev
> 
> Currently:
> 
>   - recent linux-image packages depend on 'initramfs-tools | yaird | 
> linux-initramfs-tool', so initramfs-tools is the 'default' alternative
> 
>   - initramfs-tools depends on recent udev
> 
>   - recent udev refuses to install unless recent kernel is running
> 
> This loop needs to be broken somehow.

Indeed.

This means that we could as well make yaird the default again, since in both
case we need to first upgrade the kernel to a recent 2.6, and then only can we
upgrade the the kernel.

So, this absolutely needs to be solved, thus raising the severity to critical :)

Friendly,

Sven Luther

Message #27 received at 349354@bugs.debian.org (full text, mbox, reply):

From: maximilian attems <maks@sternwelten.at>

To: 349354@bugs.debian.org

Subject: Re: initramfs-tools - kernel -udev dependency loop

Date: Sun, 5 Feb 2006 13:01:09 +0100

severity 349354 important
stop dude

as discussed with vorlon this needs to be resolved soon.

but latest klibc in testing needs that i-t release,
so let it slip for now, or we'll break to many systems.

-- 
maks

Message #36 received at 349354@bugs.debian.org (full text, mbox, reply):

From: Bastian Blank <waldi@debian.org>

To: maximilian attems <maks@sternwelten.at>, 349354@bugs.debian.org

Subject: Re: Bug#349354: initramfs-tools - kernel -udev dependency loop

Date: Sun, 5 Feb 2006 13:57:07 +0100

severity 349354 serious
thanks

On Sun, Feb 05, 2006 at 01:01:09PM +0100, maximilian attems wrote:
> as discussed with vorlon this needs to be resolved soon.

as not discussed with the kernel team, this is a problem and the release
team can decide to overwrite this on there own.

Bastian

-- 
Ahead warp factor one, Mr. Sulu.

Message #45 received at 349354-quiet@bugs.debian.org (full text, mbox, reply):

From: md@Linux.IT (Marco d'Itri)

To: 349354-quiet@bugs.debian.org

Subject: Re: Bug#349354: initramfs-tools - kernel -udev dependency loop

Date: Fri, 17 Feb 2006 19:32:25 +0100

A pointer to another thread about this:

http://groups.google.com/group/linux.debian.devel.release/browse_frm/thread/7285458be97bc622/010a417899f3f1d6#010a417899f3f1d6

-- 
ciao,
Marco

Message #50 received at 349354@bugs.debian.org (full text, mbox, reply):

From: Andrew McMillan <andrew@catalyst.net.nz>

To: 349354@bugs.debian.org

Subject: Dependency loop makes upgrading Sarge -> Unstable very hard

Date: Wed, 22 Feb 2006 23:03:29 +1300

[Message part 1 (text/plain, inline)]

Hi,

This bug is a pain.  I just had to upgrade a system from Sarge to
Unstable.  Even though the system was installing a 2.6.15 kernel as part
of the dist-upgrade udev refused to install because the currently
running kernel was 2.6.8 (the Sarge default).

My workaround was to replace /bin/uname with a temporary script that
echoed "2.6.15", and that enabled me to get out of the loop, but it is a
very undesirable thing to have to do!

While I can see that someone could potentially end up with a non-working
system (although I'm not sure to what degree it might be non-working) by
upgrading udev and then rebooting to a < 2.6.12 kernel, but udev's
preinst check doesn't do that: it is testing what kernel I'm running
now, which is often a lot less relevant.

If we make the assumption that Joe Default will be running a kernel that
Debian installed, then we can reasonably expect that a pretty normal
situation will involve a kernel upgrade to meet the udev dependency,
along with the udev upgrade.  Unfortunately the udev.preinst script
doesn't seem to make any effort to behave sanely in this situation.

Regards,
					Andrew McMillan.

-------------------------------------------------------------------------
Andrew @ Catalyst .Net .NZ  Ltd,  PO Box 11-053, Manners St,  Wellington
WEB: http://catalyst.net.nz/            PHYS: Level 2, 150-154 Willis St
DDI: +64(4)803-2201      MOB: +64(272)DEBIAN      OFFICE: +64(4)499-2267
-------------------------------------------------------------------------

[signature.asc (application/pgp-signature, inline)]

Message #55 received at 349354@bugs.debian.org (full text, mbox, reply):

From: Mike O'Connor <stew@vireo.org>

To: 349354@bugs.debian.org

Subject: why not yaird by default?

Date: Fri, 24 Feb 2006 16:24:55 -0500

Is there any drawback to just switching the default dependency to be on
yaird instead of initramfs-tools?

Message #60 received at 349354@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Mike O'Connor <stew@vireo.org>, 349354@bugs.debian.org

Subject: Re: Bug#349354: why not yaird by default?

Date: Fri, 24 Feb 2006 14:09:29 -0800

[Message part 1 (text/plain, inline)]

On Fri, Feb 24, 2006 at 04:24:55PM -0500, Mike O'Connor wrote:
> Is there any drawback to just switching the default dependency to be on
> yaird instead of initramfs-tools?

Yes.  You can't install yaird on upgrade from a 2.4 kernel.

And currently, you can't install initramfs-tools on upgrade from a 2.6.8
kernel.

In each case there are workarounds, but we really want to be able to break
this dependency loop.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

[signature.asc (application/pgp-signature, inline)]

Message #65 received at 349354@bugs.debian.org (full text, mbox, reply):

From: Jonas Smedegaard <dr@jones.dk>

To: Steve Langasek <vorlon@debian.org>, 349354@bugs.debian.org

Cc: stew@vireo.org

Subject: Re: Bug#349354: why not yaird by default?

Date: Fri, 24 Feb 2006 23:33:10 +0100

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 24 Feb 2006 14:09:29 -0800
Steve Langasek <vorlon@debian.org> wrote:

> On Fri, Feb 24, 2006 at 04:24:55PM -0500, Mike O'Connor wrote:
> > Is there any drawback to just switching the default dependency to
> > be on yaird instead of initramfs-tools?
> 
> Yes.  You can't install yaird on upgrade from a 2.4 kernel.
> 
> And currently, you can't install initramfs-tools on upgrade from a
> 2.6.8 kernel.
> 
> In each case there are workarounds, but we really want to be able to
> break this dependency loop.

More details on the limitations of each ramdisk tools (and other
comparative info) is on the Debian wiki[1].

Please help fill in the gaps at that page, if you know of something
that is not on that page, or is marked wrongly or as "Unknown,
needs to be tested" :-)

 - Jonas


[1] http://wiki.debian.org/InitrdReplacementOptions

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD/4mmn7DbMsAkQLgRApfUAKCPXB5zw/ehcqpIwfFD0L0sMA1N6QCgm10E
bAqa0sqanAZ8+x65WcxebQU=
=SOQy
-----END PGP SIGNATURE-----

Message #70 received at 349354@bugs.debian.org (full text, mbox, reply):

From: Sven Luther <sven.luther@wanadoo.fr>

To: Mike O'Connor <stew@vireo.org>, 349354@bugs.debian.org

Subject: Re: Bug#349354: why not yaird by default?

Date: Mon, 27 Feb 2006 14:36:39 +0100

On Fri, Feb 24, 2006 at 04:24:55PM -0500, Mike O'Connor wrote:
> Is there any drawback to just switching the default dependency to be on
> yaird instead of initramfs-tools?

The quality of the maintainers of both tool also play an important role in
which tool to chose as standard, and we have a pretty good feedback from both
the initramfs-tools maintainer and upstream, while for yaird, the upstream
maintainer seems to be MIA since around late december, and the debian
maintainer seems to be unable to fix a bug or even looking at patches without
getting feedback from the upstream maintainer, which makes yaird unsuitable to
be the default.

Friendly,

Sven Luther

Message #75 received at 349354@bugs.debian.org (full text, mbox, reply):

From: Jonas Smedegaard <dr@jones.dk>

To: 349354@bugs.debian.org

Subject: Re: Bug#349354: why not yaird by default?

Date: Mon, 27 Feb 2006 15:01:39 +0100

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 27 Feb 2006 14:36:39 +0100
Sven Luther <sven.luther@wanadoo.fr> wrote:

> The quality of the maintainers of both tool also play an important
> role in which tool to chose as standard, and we have a pretty good
> feedback from both the initramfs-tools maintainer and upstream, while
> for yaird, the upstream maintainer seems to be MIA since around late
> december, and the debian maintainer seems to be unable to fix a bug
> or even looking at patches without getting feedback from the upstream
> maintainer, which makes yaird unsuitable to be the default.

...says a single member of the kernel team.

I would appreciate comments from other members of the kernel team on
this issue.


Most friendly,

 - Jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFEAwZDn7DbMsAkQLgRAiwCAKCI07/HyDWg/xwn/vY1bBBtek0ylACeJ6ZW
h5acslgPIZLxixJkPrrNKV0=
=v2PD
-----END PGP SIGNATURE-----

Message #80 received at 349354@bugs.debian.org (full text, mbox, reply):

From: Sven Luther <sven.luther@wanadoo.fr>

To: Jonas Smedegaard <dr@jones.dk>, 349354@bugs.debian.org

Subject: Re: Bug#349354: why not yaird by default?

Date: Mon, 27 Feb 2006 15:14:02 +0100

On Mon, Feb 27, 2006 at 03:01:39PM +0100, Jonas Smedegaard wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Mon, 27 Feb 2006 14:36:39 +0100
> Sven Luther <sven.luther@wanadoo.fr> wrote:
> 
> > The quality of the maintainers of both tool also play an important
> > role in which tool to chose as standard, and we have a pretty good
> > feedback from both the initramfs-tools maintainer and upstream, while
> > for yaird, the upstream maintainer seems to be MIA since around late
> > december, and the debian maintainer seems to be unable to fix a bug
> > or even looking at patches without getting feedback from the upstream
> > maintainer, which makes yaird unsuitable to be the default.
> 
> ...says a single member of the kernel team.
> 
> I would appreciate comments from other members of the kernel team on
> this issue.

Please tell us since when you have not heard about your upstream, and what
fixes you have down to yaird since then, and when do you expect to be looking
at merged bug :

  #343427: linux-image-2.6.14-2-powerpc: Installation fails
  #345067: [powerpc] ide-generic is not built on powerpc, yaird tries to
  include it and fails

Open respectively since 74 and 60 days now. I even proposed you to go over the
patch and solve it in erkelenz, but you where more interested in polimicking
than fixing this bug, what else can i say ...

Sven Luther
  

Message #85 received at 349354@bugs.debian.org (full text, mbox, reply):

From: Jonas Smedegaard <dr@jones.dk>

To: 349354@bugs.debian.org

Subject: Re: Bug#349354: why not yaird by default?

Date: Mon, 27 Feb 2006 15:43:17 +0100

[Message part 1 (text/plain, inline)]

On Mon, 27 Feb 2006 15:14:02 +0100
Sven Luther <sven.luther@wanadoo.fr> wrote:

>   #343427: linux-image-2.6.14-2-powerpc: Installation fails
>   #345067: [powerpc] ide-generic is not built on powerpc, yaird tries
>   to include it and fails

Both relate to ide-generic.

Difference between yaird and initramfs-tools in regards to this issue
is that yaird has builtin probing while initramfs-tools rely on udev
for extracting kernels own logic and/or implement workarounds.

So the maintainer of initramfs-tools is right in not having any hanging
bugreports about ide-generic (they should be pushed either to udev or
linux-2.6) while yaird do not have such luxury.

If I remember correctly then the maintainer of udev has been quite
sceptical about implementing workarounds for the ide-generic problem
(rather than considering it a kernel bug) too.


I am still interested in opinions from _other_ members of the kernel
team: Is it decided to decided to ditch yaird due to my irresponsible
or non-cooperative behaviour (which I claim is related to the
problematic ide-generic issue), or do you have different opinions on
how ramdisk generators should be picked for the official kernels?

Yes, I am perfectly aware that not all is in favor of yaird, but the
reasoning behind choosing one over the other - or what is considered
fair ground for fair a competition between them.


 - Jonas

-- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm

[Message part 2 (application/pgp-signature, inline)]

Message #90 received at 349354@bugs.debian.org (full text, mbox, reply):

From: Sven Luther <sven.luther@wanadoo.fr>

To: Jonas Smedegaard <dr@jones.dk>, 349354@bugs.debian.org

Subject: Re: Bug#349354: why not yaird by default?

Date: Mon, 27 Feb 2006 16:39:51 +0100

On Mon, Feb 27, 2006 at 03:43:17PM +0100, Jonas Smedegaard wrote:
> On Mon, 27 Feb 2006 15:14:02 +0100
> Sven Luther <sven.luther@wanadoo.fr> wrote:
> 
> >   #343427: linux-image-2.6.14-2-powerpc: Installation fails
> >   #345067: [powerpc] ide-generic is not built on powerpc, yaird tries
> >   to include it and fails
> 
> Both relate to ide-generic.
> 
> Difference between yaird and initramfs-tools in regards to this issue
> is that yaird has builtin probing while initramfs-tools rely on udev
> for extracting kernels own logic and/or implement workarounds.

What has that to do with anything ? The question was "should yaird not be made
the default" and i answered that this is probably not a good idea because the
DD maintainer (you) doesn't seem able to fix bugs without consulting his
upstream and that said upstream is MIA.

Sven Luther

Message #95 received at 349354@bugs.debian.org (full text, mbox, reply):

From: Jonas Smedegaard <dr@jones.dk>

To: 349354@bugs.debian.org

Subject: Re: Bug#349354: why not yaird by default?

Date: Mon, 27 Feb 2006 18:48:40 +0100

[Message part 1 (text/plain, inline)]

On Mon, 27 Feb 2006 16:39:51 +0100
Sven Luther <sven.luther@wanadoo.fr> wrote:

> What has that to do with anything ?

Possibly nothing. That's what I wanted other opinions on to help find
out :-)


Warm thoughts from a cold Denmark,

 - Jonas


-- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm

[Message part 2 (application/pgp-signature, inline)]

Message #100 received at 349354@bugs.debian.org (full text, mbox, reply):

From: Stephen Gran <sgran@debian.org>

To: Sven Luther <sven.luther@wanadoo.fr>, 349354@bugs.debian.org

Cc: Jonas Smedegaard <dr@jones.dk>

Subject: Re: Bug#349354: why not yaird by default?

Date: Mon, 27 Feb 2006 20:46:49 +0000

[Message part 1 (text/plain, inline)]

This one time, at band camp, friendly Sven Luther said:
> On Mon, Feb 27, 2006 at 03:43:17PM +0100, Jonas Smedegaard wrote:
> > On Mon, 27 Feb 2006 15:14:02 +0100 Sven Luther
> > <sven.luther@wanadoo.fr> wrote:
> > 
> > >   #343427: linux-image-2.6.14-2-powerpc: Installation fails
> > >   #345067: [powerpc] ide-generic is not built on powerpc, yaird
> > >   tries to include it and fails
> > 
> > Both relate to ide-generic.
> > 
> > Difference between yaird and initramfs-tools in regards to this
> > issue is that yaird has builtin probing while initramfs-tools rely
> > on udev for extracting kernels own logic and/or implement
> > workarounds.
> 
> What has that to do with anything ? 

Since both bugs are arguably kernel bugs (some modules on some platforms
can't work without also loading ide-generic, but the kernel provides no
mechanism to find that out), I think it has rather a lot to do with the
issue at hand.

> The question was "should yaird not be made the default" and i answered
> that this is probably not a good idea because the DD maintainer (you)
> doesn't seem able to fix bugs without consulting his upstream and that
> said upstream is MIA.

An MIA upstream is indeed a serious problem.  A maintainer being
unwilling to accept a bad hack to work around brokenness elsewhere is
less of an issue, at least IMHO.

Ever so friendly,
-- 
 -----------------------------------------------------------------
|   ,''`.                                            Stephen Gran |
|  : :' :                                        sgran@debian.org |
|  `. `'                        Debian user, admin, and developer |
|    `-                                     http://www.debian.org |
 -----------------------------------------------------------------

[signature.asc (application/pgp-signature, inline)]

Message #105 received at 349354@bugs.debian.org (full text, mbox, reply):

From: Gustaf Räntilä <opera@kth.se>

To: 349354@bugs.debian.org

Subject: Linux or debian

Date: Tue, 28 Feb 2006 12:15:35 +0900

Hi all,

You seem to have problems with something called yaird, whatever that is.
My problem is that the udev package needs kernel modules
in /lib/modules/2.6.15-1-686. Mine is in 2.6.15.3... Why is the udev
package script looking at that particular directory? I really hope it's
not because that's where the debian kernel packages are, you really need
to support us using our own compiled kernels.
It's easy for me to fix, just symlink my modules to whatever pleases a
debian package for the moment, but I'd prefer a dialog; "Where are your
kernel modules, I couldn't find them", or even better, doing a uname.
In my case uname says 2.6.15.3, just as the directory of my modules.
Those are my suggestions anyway.

/Gustaf

Message #110 received at 349354@bugs.debian.org (full text, mbox, reply):

From: maximilian attems <maks@sternwelten.at>

To: Gustaf Räntilä <opera@kth.se>, 349354@bugs.debian.org

Subject: Re: Bug#349354: Linux or debian

Date: Tue, 28 Feb 2006 10:09:01 +0100

On Tue, Feb 28, 2006 at 12:15:35PM +0900, Gustaf Räntilä wrote:
> 
> You seem to have problems with something called yaird, whatever that is.

opening a bug report against it might be better,
than posting to a random bug.

> My problem is that the udev package needs kernel modules
> in /lib/modules/2.6.15-1-686. Mine is in 2.6.15.3... Why is the udev
> package script looking at that particular directory? I really hope it's
> not because that's where the debian kernel packages are, you really need
> to support us using our own compiled kernels.
> It's easy for me to fix, just symlink my modules to whatever pleases a
> debian package for the moment, but I'd prefer a dialog; "Where are your
> kernel modules, I couldn't find them", or even better, doing a uname.
> In my case uname says 2.6.15.3, just as the directory of my modules.
> Those are my suggestions anyway.

could you please
a) open a new bugreport
b) paste the error you are seeing

aboves text doesn't give any clue whatsoever of your problems.


--
maks

Message #115 received at 349354@bugs.debian.org (full text, mbox, reply):

From: Sven Luther <sven.luther@wanadoo.fr>

To: Stephen Gran <sgran@debian.org>

Cc: Sven Luther <sven.luther@wanadoo.fr>, 349354@bugs.debian.org, Jonas Smedegaard <dr@jones.dk>

Subject: Re: Bug#349354: why not yaird by default?

Date: Tue, 28 Feb 2006 10:49:16 +0100

On Mon, Feb 27, 2006 at 08:46:49PM +0000, Stephen Gran wrote:
> This one time, at band camp, friendly Sven Luther said:
> > On Mon, Feb 27, 2006 at 03:43:17PM +0100, Jonas Smedegaard wrote:
> > > On Mon, 27 Feb 2006 15:14:02 +0100 Sven Luther
> > > <sven.luther@wanadoo.fr> wrote:
> > > 
> > > >   #343427: linux-image-2.6.14-2-powerpc: Installation fails
> > > >   #345067: [powerpc] ide-generic is not built on powerpc, yaird
> > > >   tries to include it and fails
> > > 
> > > Both relate to ide-generic.
> > > 
> > > Difference between yaird and initramfs-tools in regards to this
> > > issue is that yaird has builtin probing while initramfs-tools rely
> > > on udev for extracting kernels own logic and/or implement
> > > workarounds.
> > 
> > What has that to do with anything ? 
> 
> Since both bugs are arguably kernel bugs (some modules on some platforms
> can't work without also loading ide-generic, but the kernel provides no
> mechanism to find that out), I think it has rather a lot to do with the
> issue at hand.

Well, sure, but the maintainership of MIA is crap, and the debian maintainer
is unwilling to be reasonable and leaves "unable to install kernel bugs" with
patches open for months. We cannot consider such a package of enough quality
enough to even consider it for etch unless something changes with the
maintainership. This was my point, not some random technical babling about the
difference between yaird and initramfs-tools (and yes, i was a fervent
supporter of yaird, and strongly advocated making it the default previously,
so i am aware of the technical issues).

> > The question was "should yaird not be made the default" and i answered
> > that this is probably not a good idea because the DD maintainer (you)
> > doesn't seem able to fix bugs without consulting his upstream and that
> > said upstream is MIA.
> 
> An MIA upstream is indeed a serious problem.  A maintainer being
> unwilling to accept a bad hack to work around brokenness elsewhere is
> less of an issue, at least IMHO.

Well, the problem was introduced in a bad hack without any kind of
understanding about the issue in the first place, the proposed problem is just
desactivating the hack on powerpc, where we know we don't build the
ide-generic module, so i doubt anyone can prove me it is *NEEDED* in any way.

In erkelenz i disucssed this with jonas, told him let's look at this and
convince ourself that it is no problem, and was only told that he would not do
som, because he was not able to be sure that it would not break on some random
user setup, and without getting his upstream approval. I wrote upstream
immediately, but we got no feedback, this was over a month ago, and yaird
remains broken.

And to make things clear, if loading ide-generic on powerpc would ever be
*NEEDED*, then the case of not building ide-generic would not work, and it has
been working just fine.

So, the issue is double, first the upstream maintainer is MIA, which is not
nice, but second the debian maintainer is unable or unwilling to take his
maitainer job seriously and at least consider looking at the patches that are
submitted by the folk who have the hardware.

This jonas clearly said (and so loudly that folk in Erkelenz asked us to leave
the room) that he would not look at my patch without aproval from upstream,
that he didn't really understand yaird enough to be sure that nothing else
would break if he did that change (which just reverted a previously applied
hacky patch that broke this), and was thus not even considering looking it
over with me.

In these conditions, it is unacceptable to make yaird the default (or probably
even ship it with etch), if we don't get a change in maintainership, either
jonas becoming more responsible, or someone co-maintaining it or taking it
over, preferably someone with a clue and knowledgeable in perl.

Friendly,

Sven Luther
> 
> Ever so friendly,
> -- 
>  -----------------------------------------------------------------
> |   ,''`.                                            Stephen Gran |
> |  : :' :                                        sgran@debian.org |
> |  `. `'                        Debian user, admin, and developer |
> |    `-                                     http://www.debian.org |
>  -----------------------------------------------------------------

Message #120 received at 349354@bugs.debian.org (full text, mbox, reply):

From: Stephen Gran <sgran@debian.org>

To: Sven Luther <sven.luther@wanadoo.fr>

Cc: 349354@bugs.debian.org, Jonas Smedegaard <dr@jones.dk>

Subject: Re: Bug#349354: why not yaird by default?

Date: Tue, 28 Feb 2006 10:17:39 +0000

[Message part 1 (text/plain, inline)]

This one time, at band camp, friendly Sven Luther said:

[ a long unfriendly rant snipped ]

Frankly, I don't care whether or not yaird is the default ramdisk
generator for the kernel.  An MIA upstream is a good reason to decide
against it, in fact.  The entire rest of your argument sounds like hurt
feelings because Jonas won't take a broken patch, though, and I'm just
not interested in that sort of silliness.

The fact that this same bug exist(s|ed) in udev, mkinitramfs, and yaird
indicates that there is a real bug in the kernel that is merely being
triggered by all of these packages.  Can you, as kernel maintainer,
please spend your energy fixing the kernel bug that is causing all of
this, instead of wasting my time bickering with Jonas?  This bug
rendered my laptop unbootable until Md patched around it.

Very very friendly,
-- 
 -----------------------------------------------------------------
|   ,''`.                                            Stephen Gran |
|  : :' :                                        sgran@debian.org |
|  `. `'                        Debian user, admin, and developer |
|    `-                                     http://www.debian.org |
 -----------------------------------------------------------------

[signature.asc (application/pgp-signature, inline)]

Message #125 received at 349354@bugs.debian.org (full text, mbox, reply):

From: Sven Luther <sven.luther@wanadoo.fr>

To: Stephen Gran <sgran@debian.org>

Cc: Sven Luther <sven.luther@wanadoo.fr>, 349354@bugs.debian.org, Jonas Smedegaard <dr@jones.dk>

Subject: Re: Bug#349354: why not yaird by default?

Date: Tue, 28 Feb 2006 11:46:39 +0100

On Tue, Feb 28, 2006 at 10:17:39AM +0000, Stephen Gran wrote:
> This one time, at band camp, friendly Sven Luther said:
> 
> [ a long unfriendly rant snipped ]
> 
> Frankly, I don't care whether or not yaird is the default ramdisk
> generator for the kernel.  An MIA upstream is a good reason to decide
> against it, in fact.  The entire rest of your argument sounds like hurt
> feelings because Jonas won't take a broken patch, though, and I'm just
> not interested in that sort of silliness.

And who are you to say it is a broken patch ? Have you looked at it ? The main
problem is that jonas does not even want to look at the patch, so claiming it
is broken without looking at it, it kind of insulting in the first place.

Please have a look at the patch, and show me how it is broken.

> The fact that this same bug exist(s|ed) in udev, mkinitramfs, and yaird
> indicates that there is a real bug in the kernel that is merely being

I personally believe that the real bug is in ide-generic. Powerpc doesn't even
build ide-generic, so should be unaffected by all this silliness, and eric and
jonas decided to add some ugly hack to load ide-generic after the other
modules, without caring that the module doesn't exist.

Frankly, i have been running via-ide on powerpc without ide-generic since over
2 years now, and was never affected by this silly bug, so all i ask that x86
brokeness doesn't break powerpc in some ugly fixes done without understanding.

> triggered by all of these packages.  Can you, as kernel maintainer,
> please spend your energy fixing the kernel bug that is causing all of
> this, instead of wasting my time bickering with Jonas?  This bug
> rendered my laptop unbootable until Md patched around it.

Yeah, how does you like it ? And i am in a situation where my RL work does
include doing support for 1000+ pegasos users out there, whose debian install
gets broken by jonas and erik's half-backed patch, and erik is MIA, and jonas
is not even interested in thinking about fixing it. He never even replied to
the bug report until i pointed it out in erkelenz to him.

So, the thing you are complaining about, is exactly the same i am complaining
about here.

Friendly,

Sven Luther

Message #130 received at 349354@bugs.debian.org (full text, mbox, reply):

From: Stephen Gran <sgran@debian.org>

To: Sven Luther <sven.luther@wanadoo.fr>

Cc: 349354@bugs.debian.org, Jonas Smedegaard <dr@jones.dk>

Subject: Re: Bug#349354: why not yaird by default?

Date: Tue, 28 Feb 2006 11:17:36 +0000

[Message part 1 (text/plain, inline)]

This one time, at band camp, friendly Sven Luther said:
> On Tue, Feb 28, 2006 at 10:17:39AM +0000, Stephen Gran wrote:
> > This one time, at band camp, friendly Sven Luther said:
> > 
> > [ a long unfriendly rant snipped ]
> > 
> > Frankly, I don't care whether or not yaird is the default ramdisk
> > generator for the kernel.  An MIA upstream is a good reason to
> > decide against it, in fact.  The entire rest of your argument sounds
> > like hurt feelings because Jonas won't take a broken patch, though,
> > and I'm just not interested in that sort of silliness.
> 
> And who are you to say it is a broken patch ? Have you looked at it ?
> The main problem is that jonas does not even want to look at the
> patch, so claiming it is broken without looking at it, it kind of
> insulting in the first place.
> 
> Please have a look at the patch, and show me how it is broken.

Of course I've looked at the patch, that's how I came to the conclusion
it's broken.  Please don't jump to conclusions.  Your patch makes the
assumption that ide-generic will never be needed on any ppc hardware
ever.  This may be the case for you right now, but does not appear to me
to be a safe assumption.  This is exactly the sort of hack that leads to
more problems down the road, patched around with worse hacks then, ad
nauseum.  It is vastly more appropriate to fix the single real bug than
to patch around it in all the places that trigger it.

> > The fact that this same bug exist(s|ed) in udev, mkinitramfs, and
> > yaird indicates that there is a real bug in the kernel that is
> > merely being
> 
> I personally believe that the real bug is in ide-generic. 

Then fix it. You are a kernel maintainer, right?

> > triggered by all of these packages.  Can you, as kernel maintainer,
> > please spend your energy fixing the kernel bug that is causing all
> > of this, instead of wasting my time bickering with Jonas?  This bug
> > rendered my laptop unbootable until Md patched around it.
> 
> Yeah, how does you like it ? And i am in a situation where my RL work
> does include doing support for 1000+ pegasos users out there, whose
> debian install gets broken by jonas and erik's half-backed patch, and
> erik is MIA, and jonas is not even interested in thinking about fixing
> it. He never even replied to the bug report until i pointed it out in
> erkelenz to him.
> 
> So, the thing you are complaining about, is exactly the same i am
> complaining about here.

So, can you please fix it?  Since you're a kernel team member, you are
in a better position than either Jonas or myself to do something about
it.  Or is there some problem with fixing it the right way that I'm
missing?
-- 
 -----------------------------------------------------------------
|   ,''`.                                            Stephen Gran |
|  : :' :                                        sgran@debian.org |
|  `. `'                        Debian user, admin, and developer |
|    `-                                     http://www.debian.org |
 -----------------------------------------------------------------

[signature.asc (application/pgp-signature, inline)]

Message #135 received at 349354@bugs.debian.org (full text, mbox, reply):

From: md@Linux.IT (Marco d'Itri)

To: Stephen Gran <sgran@debian.org>, 349354@bugs.debian.org

Cc: Sven Luther <sven.luther@wanadoo.fr>, Jonas Smedegaard <dr@jones.dk>

Subject: Re: Bug#349354: why not yaird by default?

Date: Tue, 28 Feb 2006 12:38:09 +0100

[Message part 1 (text/plain, inline)]

What about you all stop Cc'ing this non-relevant bug? Thank you...


(FWIW my opinion is that yaird should not be the default because hardware
changes will make the system unbootable if the drivers needed to mount /
are not in the initramfs.)

-- 
ciao,
Marco

[signature.asc (application/pgp-signature, inline)]

Message #140 received at 349354@bugs.debian.org (full text, mbox, reply):

From: Sven Luther <sven.luther@wanadoo.fr>

To: Stephen Gran <sgran@debian.org>, 349354@bugs.debian.org

Cc: Sven Luther <sven.luther@wanadoo.fr>, Jonas Smedegaard <dr@jones.dk>

Subject: Re: Bug#349354: why not yaird by default?

Date: Tue, 28 Feb 2006 12:56:41 +0100

On Tue, Feb 28, 2006 at 11:17:36AM +0000, Stephen Gran wrote:
> > Please have a look at the patch, and show me how it is broken.
> 
> Of course I've looked at the patch, that's how I came to the conclusion
> it's broken.  Please don't jump to conclusions.  Your patch makes the
> assumption that ide-generic will never be needed on any ppc hardware

Ok. so you believe that there may be a remote chance that ide-generic will be
needed on powerpc, this would mean that there would be no ide working without
it right. I mean, look into your dictionary for 'needed', as i guess it is
safe to say that is something that is 'needed' is missing, then it doesn't
work. Since it is working right now, it is proof enough that it is not needed.

If this will change in a random future, then it will be time enough to fix it
for such an hypothetical situation, so basically you are breaking a currently
existing case for some hypothetical future case, how logical.

> ever.  This may be the case for you right now, but does not appear to me
> to be a safe assumption.  This is exactly the sort of hack that leads to

Ah, yes. That is also what jonas claims. Please explaqin to me a scenario
where this assumption will not be broken. I mean, face it, the 'let's include
ide-generic' hack was activated for piix, via-ide, and third one i don't
remember. None of them have vocation to work in the main case on powerpc
hardware. I guess you could have via-ide pci cards in a powermac, but this is
far from being common, compared to the 1000+ users we have out there and i
have to do support for.

> more problems down the road, patched around with worse hacks then, ad
> nauseum.  It is vastly more appropriate to fix the single real bug than
> to patch around it in all the places that trigger it.

Nope, the patch just disables the ugly hack erik and jonas enabled in the
first place. Notice also that even on x86 it is not clear that this hack is
needed in the majority of cases, as we only had a handful of reports about
this. 

> > > The fact that this same bug exist(s|ed) in udev, mkinitramfs, and
> > > yaird indicates that there is a real bug in the kernel that is
> > > merely being
> > 
> > I personally believe that the real bug is in ide-generic. 
> 
> Then fix it. You are a kernel maintainer, right?

The whole ide layer is going to go away in favour of the new libata
reimplementation, upstream is working on this, it is not quite mature enough
yet. 

> > > triggered by all of these packages.  Can you, as kernel maintainer,
> > > please spend your energy fixing the kernel bug that is causing all
> > > of this, instead of wasting my time bickering with Jonas?  This bug
> > > rendered my laptop unbootable until Md patched around it.
> > 
> > Yeah, how does you like it ? And i am in a situation where my RL work
> > does include doing support for 1000+ pegasos users out there, whose
> > debian install gets broken by jonas and erik's half-backed patch, and
> > erik is MIA, and jonas is not even interested in thinking about fixing
> > it. He never even replied to the bug report until i pointed it out in
> > erkelenz to him.
> > 
> > So, the thing you are complaining about, is exactly the same i am
> > complaining about here.
> 
> So, can you please fix it?  Since you're a kernel team member, you are
> in a better position than either Jonas or myself to do something about
> it.  Or is there some problem with fixing it the right way that I'm
> missing?

It is loadful of work, and it is not even clear what the problem is exactly,
and we don't have access to the hardware who exhibits the problem, and what
else more ...

So, instead of investigating this, both the yaird and initramfs-tools have
gone into doing ugly hacks, which broke the previously perfectly working
pegasos system, and jonas is plainly refusing to even think about it. I even
came quite friendly to him in erkelenz and said let's fix it together this WE,
and what, no he prefered to go into hours of polimicking about philospohical
reasons why it 'may' break in some undetermined future, and got angry at any
attempt on my part to show him the code or to explain to him that there is no
chance it may break. I mean he clearly decided that anything i may say is just
to be ignored, so what do you want ? And since the upstream is MIA, i only see
two solutions, takeover yaird, or let it be and go with initramfs-tools as
default, given that i don't speak perl, and even if i think yaird is the
better concept, well, there is not much choice of what to do.

Friendly,

Sven Luther

Message #145 received at 349354@bugs.debian.org (full text, mbox, reply):

From: md@Linux.IT (Marco d'Itri)

To: 349354@bugs.debian.org

Subject: Re: Bug#349354: initramfs-tools - kernel -udev dependency loop

Date: Thu, 2 Mar 2006 13:29:29 +0100

[Message part 1 (text/plain, inline)]

I implemented in udev 0.085-1 a first attempt to solve this problem.
It's totally untested and I will not able to test it myself soon, so
reports are appreciated.


The upgrade procedure should be something like:

# switch sources.list to testing
apt-get update
touch /etc/udev/kernel-upgrade
apt-get install udev linux-image-2.6.15-1-k7 initramfs-tools
# update the boot loader configuration if needed
reboot

-- 
ciao,
Marco

[signature.asc (application/pgp-signature, inline)]

Message #150 received at 349354@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: 349354@bugs.debian.org

Subject: Re: Bug#349354: initramfs-tools - kernel -udev dependency loop

Date: Thu, 02 Mar 2006 19:54:08 -0500

Greetings,

The new upgrade procedure fails on alpha, regardless of the kernel
workaround, there's still a udev - initramfs-tools dependency loop which
interrupts the udev postinst, and the failures cascade from there:

# touch /etc/udev/kernel-upgrade
# dselect
Reading package lists... Done
Building dependency tree... Done
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
8 not fully installed or removed.
Need to get 0B of archives.
After unpacking 0B of additional disk space will be used.
Do you want to continue [Y/n]?
Setting up udev (0.085-1) ...
Kernel upgrade mode, udevd has not been restarted.
Please reboot the system as soon as possible.
Kernel version too old.  initramfs-tools requires at least 2.6.12.
dpkg: error processing udev (--configure):
 subprocess post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of initramfs-tools:
 initramfs-tools depends on udev (>= 0.076-5); however:
  Package udev is not configured yet.
dpkg: error processing initramfs-tools (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of linux-image-2.6.15-1-alpha-generic:
 linux-image-2.6.15-1-alpha-generic depends on initramfs-tools | yaird | linux-initramfs-tool; however:
  Package initramfs-tools is not configured yet.
  Package yaird is not installed.
  Package linux-initramfs-tool is not installed.
  Package initramfs-tools which provides linux-initramfs-tool is not configured yet.
dpkg: error processing linux-image-2.6.15-1-alpha-generic (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of linux-image-2.6-alpha-generic:
 linux-image-2.6-alpha-generic depends on linux-image-2.6.15-1-alpha-generic (= 2.6.15-7); however:
  Package linux-image-2.6.15-1-alpha-generic is not configured yet.
dpkg: error processing linux-image-2.6-alpha-generic (--configure):
 dependency problems - leaving unconfigured

Cheers,
-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html

Message #155 received at 349354@bugs.debian.org (full text, mbox, reply):

From: md@Linux.IT (Marco d'Itri)

To: Adam C Powell IV <hazelsct@debian.org>, 349354@bugs.debian.org

Subject: Re: Bug#349354: initramfs-tools - kernel -udev dependency loop

Date: Fri, 3 Mar 2006 09:42:41 +0100

[Message part 1 (text/plain, inline)]

On Mar 03, Adam C Powell IV <hazelsct@debian.org> wrote:

> Kernel upgrade mode, udevd has not been restarted.
> Please reboot the system as soon as possible.
> Kernel version too old.  initramfs-tools requires at least 2.6.12.
> dpkg: error processing udev (--configure):
>  subprocess post-installation script returned error exit status 1

udev did its part, now it looks like that initramfs-tools too needs to
implement the upgrade procedure.
What is the reason for this requirement? I looked at the changelog but
could not find anything related.

-- 
ciao,
Marco

[signature.asc (application/pgp-signature, inline)]

Message #160 received at 349354@bugs.debian.org (full text, mbox, reply):

From: maximilian attems <maks@sternwelten.at>

To: Adam C Powell IV <hazelsct@debian.org>, 349354@bugs.debian.org

Subject: Re: Bug#349354: initramfs-tools - kernel -udev dependency loop

Date: Fri, 3 Mar 2006 11:18:46 +0100

On Thu, Mar 02, 2006 at 07:54:08PM -0500, Adam C Powell IV wrote:
> 
> The new upgrade procedure fails on alpha, regardless of the kernel
> workaround, there's still a udev - initramfs-tools dependency loop which
> interrupts the udev postinst, and the failures cascade from there:
> 
> # touch /etc/udev/kernel-upgrade
> # dselect
> Reading package lists... Done
> Building dependency tree... Done
> 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
> 8 not fully installed or removed.
> Need to get 0B of archives.
> After unpacking 0B of additional disk space will be used.
> Do you want to continue [Y/n]?
> Setting up udev (0.085-1) ...
> Kernel upgrade mode, udevd has not been restarted.
> Please reboot the system as soon as possible.
> Kernel version too old.  initramfs-tools requires at least 2.6.12.

hmm why?
could you put as local workaround an set -x on top in
/usr/sbin/mkinitramfs, would really like to know how we got called
there.

regards

--
maks

Message #165 received at 349354@bugs.debian.org (full text, mbox, reply):

From: md@Linux.IT (Marco d'Itri)

To: maximilian attems <maks@sternwelten.at>, 349354@bugs.debian.org

Cc: Adam C Powell IV <hazelsct@debian.org>

Subject: Re: Bug#349354: initramfs-tools - kernel -udev dependency loop

Date: Fri, 3 Mar 2006 11:39:29 +0100

[Message part 1 (text/plain, inline)]

On Mar 03, maximilian attems <maks@sternwelten.at> wrote:

> could you put as local workaround an set -x on top in
> /usr/sbin/mkinitramfs, would really like to know how we got called
> there.
The udev postinst always runs update-initramfs -u.

-- 
ciao,
Marco

[signature.asc (application/pgp-signature, inline)]

Message #170 received at 349354@bugs.debian.org (full text, mbox, reply):

From: maximilian attems <maks@sternwelten.at>

To: Marco d'Itri <md@Linux.IT>

Cc: 349354@bugs.debian.org, Adam C Powell IV <hazelsct@debian.org>

Subject: Re: Bug#349354: initramfs-tools - kernel -udev dependency loop

Date: Fri, 3 Mar 2006 23:42:34 +0100

On Fri, 03 Mar 2006, Marco d'Itri wrote:

> On Mar 03, maximilian attems <maks@sternwelten.at> wrote:
> 
> > could you put as local workaround an set -x on top in
> > /usr/sbin/mkinitramfs, would really like to know how we got called
> > there.
> The udev postinst always runs update-initramfs -u.

indeed you are right as there are more potential hooks in the time
of the etch release, initramfs-tools need to check for the
file you propsed, will do next week.

-- 
maks

Message #175 received at 349354@bugs.debian.org (full text, mbox, reply):

From: maximilian attems <maks@sternwelten.at>

To: Adam C Powell IV <hazelsct@debian.org>, 349354@bugs.debian.org

Cc: Marco d'Itri <md@Linux.IT>

Subject: Re: Bug#349354: initramfs-tools - kernel -udev dependency loop

Date: Sat, 4 Mar 2006 00:47:01 +0100

On Thu, 02 Mar 2006, Adam C Powell IV wrote:

> The new upgrade procedure fails on alpha, regardless of the kernel
> workaround, there's still a udev - initramfs-tools dependency loop which
> interrupts the udev postinst, and the failures cascade from there:

please upgrad initramfs-tools to latest 0.53 in testing/unstable.
 
> Setting up udev (0.085-1) ...
> Kernel upgrade mode, udevd has not been restarted.
> Please reboot the system as soon as possible.
> Kernel version too old.  initramfs-tools requires at least 2.6.12.

this could only happen because we had set takover=1 for the past days
with the revision 0.52.
(never the less this broken check needs fixing - as discussed with Md)

thanks for your feedback.

--
maks

Message #180 received at 349354@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: maximilian attems <maks@sternwelten.at>

Cc: 349354@bugs.debian.org, Marco d'Itri <md@Linux.IT>

Subject: Re: Bug#349354: initramfs-tools - kernel -udev dependency loop

Date: Sun, 05 Mar 2006 22:54:33 -0500

On Sat, 2006-03-04 at 00:47 +0100, maximilian attems wrote:
> On Thu, 02 Mar 2006, Adam C Powell IV wrote:
> 
> > The new upgrade procedure fails on alpha, regardless of the kernel
> > workaround, there's still a udev - initramfs-tools dependency loop which
> > interrupts the udev postinst, and the failures cascade from there:
> 
> please upgrad initramfs-tools to latest 0.53 in testing/unstable.

Okay, 0.53 is in testing now (maybe a day or two ago).  But again, with
the new initramfs-tools unpacked (but not configured):

Setting up udev (0.085-1) ...
Kernel version too old.  initramfs-tools requires at least 2.6.12.
dpkg: error processing udev (--configure):
 subprocess post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of initramfs-tools:
 initramfs-tools depends on udev (>= 0.076-5); however:
  Package udev is not configured yet.

I don't know whether this will prevent an upgrade from sarge, but it
does stop an upgrade from old etch to new etch.

Thanks,

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html

Message #185 received at 349354@bugs.debian.org (full text, mbox, reply):

From: maximilian attems <maks@sternwelten.at>

To: Adam C Powell IV <hazelsct@debian.org>

Cc: 349354@bugs.debian.org, Marco d'Itri <md@Linux.IT>

Subject: Re: Bug#349354: initramfs-tools - kernel -udev dependency loop

Date: Mon, 6 Mar 2006 08:01:27 +0100

On Sun, Mar 05, 2006 at 10:54:33PM -0500, Adam C Powell IV wrote:
> 
> Okay, 0.53 is in testing now (maybe a day or two ago).  But again, with
> the new initramfs-tools unpacked (but not configured):
> 
> Setting up udev (0.085-1) ...
> Kernel version too old.  initramfs-tools requires at least 2.6.12.
> dpkg: error processing udev (--configure):
>  subprocess post-installation script returned error exit status 1
> dpkg: dependency problems prevent configuration of initramfs-tools:
>  initramfs-tools depends on udev (>= 0.076-5); however:
>   Package udev is not configured yet.
> 
> I don't know whether this will prevent an upgrade from sarge, but it
> does stop an upgrade from old etch to new etch.

thanks for your testing, you catched me.
didn't reset takeover as declared in changelog...
ooh zut. you'll get an 0.53c today in unstable.

--
maks

Message #190 received at 349354@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: maximilian attems <maks@sternwelten.at>

Cc: 349354@bugs.debian.org, Marco d'Itri <md@Linux.IT>

Subject: Re: Bug#349354: initramfs-tools - kernel -udev dependency loop

Date: Fri, 10 Mar 2006 18:09:30 -0500

On Mon, 2006-03-06 at 08:01 +0100, maximilian attems wrote:
> On Sun, Mar 05, 2006 at 10:54:33PM -0500, Adam C Powell IV wrote:
> > 
> > Okay, 0.53 is in testing now (maybe a day or two ago).  But again, with
> > the new initramfs-tools unpacked (but not configured):
> > 
> > Setting up udev (0.085-1) ...
> > Kernel version too old.  initramfs-tools requires at least 2.6.12.
> > dpkg: error processing udev (--configure):
> >  subprocess post-installation script returned error exit status 1
> > dpkg: dependency problems prevent configuration of initramfs-tools:
> >  initramfs-tools depends on udev (>= 0.076-5); however:
> >   Package udev is not configured yet.
> > 
> > I don't know whether this will prevent an upgrade from sarge, but it
> > does stop an upgrade from old etch to new etch.
> 
> thanks for your testing, you catched me.
> didn't reset takeover as declared in changelog...
> ooh zut. you'll get an 0.53c today in unstable.

Terrific, 0.53c makes everything work.  udev configures, initramfs-tools
configures, and it builds the ramdisk for 2.6.15.

Thanks very much!

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html

Message #195 received at 349354@bugs.debian.org (full text, mbox, reply):

From: md@Linux.IT (Marco d'Itri)

To: 349354@bugs.debian.org

Cc: debian-kernel@lists.debian.org, debian-devel@lists.debian.org, debian-release@lists.debian.org

Subject: Re: Bug#349354: initramfs-tools - kernel -udev dependency loop

Date: Sun, 9 Apr 2006 19:11:30 +0200

[Message part 1 (text/plain, inline)]

This should have been fixed by udev 0.085-1 and initramfs-tools 0.53, so
unless somebody will report more problems soon I will close the bug.

-- 
ciao,
Marco

[signature.asc (application/pgp-signature, inline)]

Message #202 received at 349354@bugs.debian.org (full text, mbox, reply):

From: maximilian attems <maks@sternwelten.at>

To: 349354@bugs.debian.org

Subject: initramfs-tools - kernel -udev dependency loop

Date: Thu, 11 May 2006 22:26:03 +0200

as upgrades work out if you touch that special conf file
i would propose to check against a version range in which
the sarge release falls and allow those an smooth upgrade
without running kernel check.

of course with a big warning that the user should reboot soonest.

regards

-- 
maks

Message #209 received at 349354@bugs.debian.org (full text, mbox, reply):

From: md@Linux.IT (Marco d'Itri)

To: maximilian attems <maks@sternwelten.at>, 349354@bugs.debian.org

Subject: Re: Bug#349354: initramfs-tools - kernel -udev dependency loop

Date: Fri, 12 May 2006 00:02:37 +0200

[Message part 1 (text/plain, inline)]

On May 11, maximilian attems <maks@sternwelten.at> wrote:

> as upgrades work out if you touch that special conf file
> i would propose to check against a version range in which
> the sarge release falls and allow those an smooth upgrade
> without running kernel check.
> 
> of course with a big warning that the user should reboot soonest.
This does not work, because if for some reason the user were not ready
to upgrade the kernel then the would have already been upgraded and
would not start again at the next reboot. Is this what you really want?

Do you have more ideas to try before I close the bug again?

-- 
ciao,
Marco

[signature.asc (application/pgp-signature, inline)]

Message #214 received at 349354@bugs.debian.org (full text, mbox, reply):

From: maximilian attems <maks@sternwelten.at>

To: Marco d'Itri <md@Linux.IT>

Cc: 349354@bugs.debian.org

Subject: Re: Bug#349354: initramfs-tools - kernel -udev dependency loop

Date: Fri, 12 May 2006 00:18:18 +0200

On Fri, May 12, 2006 at 12:02:37AM +0200, Marco d'Itri wrote:
> On May 11, maximilian attems <maks@sternwelten.at> wrote:
> 
> > as upgrades work out if you touch that special conf file
> > i would propose to check against a version range in which
> > the sarge release falls and allow those an smooth upgrade
> > without running kernel check.
> > 
> > of course with a big warning that the user should reboot soonest.
> This does not work, because if for some reason the user were not ready
> to upgrade the kernel then the would have already been upgraded and
> would not start again at the next reboot. Is this what you really want?

do you propose linux-2.6.16 or whatever etch will ship to touch
that special /etc/udev/upgrade_from_hell.conf?
 
> Do you have more ideas to try before I close the bug again?

i'm fine to close the bugreport if and only if the bug is resolved,
which is clearly not the case until then work is required.
 
regards

--
maks

Message #219 received at 349354@bugs.debian.org (full text, mbox, reply):

From: md@Linux.IT (Marco d'Itri)

To: maximilian attems <maks@sternwelten.at>

Cc: 349354@bugs.debian.org

Subject: Re: Bug#349354: initramfs-tools - kernel -udev dependency loop

Date: Fri, 12 May 2006 01:35:57 +0200

[Message part 1 (text/plain, inline)]

On May 12, maximilian attems <maks@sternwelten.at> wrote:

> > This does not work, because if for some reason the user were not ready
> > to upgrade the kernel then the would have already been upgraded and
> > would not start again at the next reboot. Is this what you really want?
> do you propose linux-2.6.16 or whatever etch will ship to touch
> that special /etc/udev/upgrade_from_hell.conf?
This would not work since a package cannot assume anything about the
order in which packages are configured while upgrading. Next idea?

> > Do you have more ideas to try before I close the bug again?
> i'm fine to close the bugreport if and only if the bug is resolved,
> which is clearly not the case until then work is required.
I clearly explained that I consider it resolved and what you are
supposed to do it you disagree. Since you apparently feel strongly about
it and today I am feeling very diplomatic I will keep it open
considering it a wishlist as long as you can continue providing ideas to
improve the user interface, but that's all.

-- 
ciao,
Marco

[signature.asc (application/pgp-signature, inline)]

Message #224 received at 349354@bugs.debian.org (full text, mbox, reply):

From: maximilian attems <maks@sternwelten.at>

To: Marco d'Itri <md@Linux.IT>, 349354@bugs.debian.org

Subject: Re: Bug#349354: initramfs-tools - kernel -udev dependency loop

Date: Mon, 15 May 2006 09:27:24 +0200

On Fri, 12 May 2006, Marco d'Itri wrote:

> On May 12, maximilian attems <maks@sternwelten.at> wrote:
> 
> > > This does not work, because if for some reason the user were not ready
> > > to upgrade the kernel then the would have already been upgraded and
> > > would not start again at the next reboot. Is this what you really want?
> > do you propose linux-2.6.16 or whatever etch will ship to touch
> > that special /etc/udev/upgrade_from_hell.conf?
> This would not work since a package cannot assume anything about the
> order in which packages are configured while upgrading. Next idea?

if the kernel is to be upgraded we get a newer initramfs generator.
how about to check against to be installled initramfs-tools or yaird?
 

regards

-- 
maks

Message #229 received at 349354@bugs.debian.org (full text, mbox, reply):

From: md@Linux.IT (Marco d'Itri)

To: maximilian attems <maks@sternwelten.at>

Cc: 349354@bugs.debian.org

Subject: Re: Bug#349354: initramfs-tools - kernel -udev dependency loop

Date: Mon, 15 May 2006 09:54:25 +0200

[Message part 1 (text/plain, inline)]

On May 15, maximilian attems <maks@sternwelten.at> wrote:

> > > > This does not work, because if for some reason the user were not ready
> > > > to upgrade the kernel then the would have already been upgraded and
> > > > would not start again at the next reboot. Is this what you really want?
> > > do you propose linux-2.6.16 or whatever etch will ship to touch
> > > that special /etc/udev/upgrade_from_hell.conf?
> > This would not work since a package cannot assume anything about the
> > order in which packages are configured while upgrading. Next idea?
> if the kernel is to be upgraded we get a newer initramfs generator.
> how about to check against to be installled initramfs-tools or yaird?
These packages are not actually needed by udev, and again they may be
unpacked in the wrong order. Next?

-- 
ciao,
Marco

[signature.asc (application/pgp-signature, inline)]

Message #234 received at 349354@bugs.debian.org (full text, mbox, reply):

From: md@Linux.IT (Marco d'Itri)

To: maximilian attems <maks@sternwelten.at>

Cc: 349354@bugs.debian.org

Subject: Re: Bug#349354: initramfs-tools - kernel -udev dependency loop

Date: Wed, 24 May 2006 18:14:03 +0200

[Message part 1 (text/plain, inline)]

On May 15, Marco d'Itri <md@Linux.IT> wrote:

> These packages are not actually needed by udev, and again they may be
> unpacked in the wrong order. Next?
I am still waiting for your proposals.

-- 
ciao,
Marco

[signature.asc (application/pgp-signature, inline)]

Message #239 received at 349354@bugs.debian.org (full text, mbox, reply):

From: maximilian attems <maks@sternwelten.at>

To: Marco d'Itri <md@Linux.IT>, 349354@bugs.debian.org

Subject: Re: Bug#349354: initramfs-tools - kernel -udev dependency loop

Date: Thu, 25 May 2006 02:11:20 +0200

On Wed, 24 May 2006, Marco d'Itri wrote:

> On May 15, Marco d'Itri <md@Linux.IT> wrote:
> 
> > These packages are not actually needed by udev, and again they may be
> > unpacked in the wrong order. Next?

i know that these packages are not needed by udev itself,
they are going to be installed on an upgrade to a new linux-image

> I am still waiting for your proposals.

udev disables itself for 2.4 kernels, why can't it do that for 2.6.8?

otherwise stick that super special config in one of the package you depend
on aka initscripts or makedev or lsb-base..
 
regards

-- 
maks

Message #244 received at 349354@bugs.debian.org (full text, mbox, reply):

From: md@Linux.IT (Marco d'Itri)

To: maximilian attems <maks@sternwelten.at>, 349354@bugs.debian.org

Subject: Re: Bug#349354: initramfs-tools - kernel -udev dependency loop

Date: Thu, 25 May 2006 09:27:43 +0200

[Message part 1 (text/plain, inline)]

On May 25, maximilian attems <maks@sternwelten.at> wrote:

> > > These packages are not actually needed by udev, and again they may be
> > > unpacked in the wrong order. Next?
> i know that these packages are not needed by udev itself,
> they are going to be installed on an upgrade to a new linux-image
So what? udev still needs to check that they have been installed before
it can continue.

> udev disables itself for 2.4 kernels, why can't it do that for 2.6.8?
It does, but people do not expect that an udev upgrade will disable it,
and they are right.

> otherwise stick that super special config in one of the package you depend
> on aka initscripts or makedev or lsb-base..
I do not know what you are writing about.

-- 
ciao,
Marco

[signature.asc (application/pgp-signature, inline)]

Message #249 received at 349354@bugs.debian.org (full text, mbox, reply):

From: md@Linux.IT (Marco d'Itri)

To: maximilian attems <maks@sternwelten.at>, 349354@bugs.debian.org

Subject: Re: Bug#349354: initramfs-tools - kernel -udev dependency loop

Date: Fri, 26 May 2006 22:51:36 +0200

[Message part 1 (text/plain, inline)]

Any more bright ideas?

-- 
ciao,
Marco

[signature.asc (application/pgp-signature, inline)]

Message #254 received at 349354@bugs.debian.org (full text, mbox, reply):

From: Sven Luther <sven.luther@wanadoo.fr>

To: Marco d'Itri <md@Linux.IT>, 349354@bugs.debian.org

Cc: Sven Luther <luther@debian.org>, 369207-done@bugs.debian.org

Subject: Re: Bug#369207: sarge->sid dist-upgrade is impossible, gnome/udev/kernel circular dep

Date: Sun, 28 May 2006 11:38:50 +0200

On Sun, May 28, 2006 at 11:22:35AM +0200, Marco d'Itri wrote:
> On May 28, Sven Luther <luther@debian.org> wrote:
> 
> > Now, i tried installing the linux-image package, but apt didn't let me do
> > this, because of the above installability problems, resulting in a broken
> > apt/dpkg database, and no easy way to go out of this without removing the
> > whole gnome packages, which is not desired.
> If your system is already in this state I think you just need to install
> the kernel package (and its dependencies) using dpkg -i and then
> continue as usual.

I didn't read the message and didn't touch the magic file, so i couldn't
install a new kernel.

> > I beleive i will be able to go out of this by some creative apt/dpkg
> > overriding, and maybe hand intervention, but we can't release etch this way.
> So far nobody managed to propose anything better, anyway feel free to
> share your toughs in #349354 of which this bug is a duplicate.

As discussed on irc, the best solution for this is to use debconf to inform
the user about this problem, and ask him if he wants to upgrade all the same,
defaulting to no. IDeally this could be done in such a way as to not make the
system un-upgradable.

I don't know, maybe hal and co can pre-depend on the right udev version or
something ?

Friendly,

Sven Luther

Message #261 received at 349354-done@bugs.debian.org (full text, mbox, reply):

From: md@Linux.IT (Marco d'Itri)

To: maximilian attems <maks@sternwelten.at>, 349354-done@bugs.debian.org

Subject: Re: Bug#349354: initramfs-tools - kernel -udev dependency loop

Date: Fri, 2 Jun 2006 18:52:25 +0200

[Message part 1 (text/plain, inline)]

On May 26, Marco d'Itri <md@Linux.IT> wrote:

> Any more bright ideas?
Tought so. I'm closing this bug, since now we have #369479 which is
correctly tracking the UI improvement request.

-- 
ciao,
Marco

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.