making udev require 2.6.15 kernels
Marco d'Itri
requirement for the udev package from 2.6.12 to 2.6.15 as soon as a new
version of udev will have entered testing.
This will let me remove a lot of cruft from the package.
Does anybody have a reason to wait some more time?
--
ciao,
Marco
--
To UNSUBSCRIBE, email to debian-ker...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Otavio Salvador
> Now that 2.6.15 kernels are in testing I'd like to raise the kernel
> requirement for the udev package from 2.6.12 to 2.6.15 as soon as a new
> version of udev will have entered testing.
> This will let me remove a lot of cruft from the package.
> Does anybody have a reason to wait some more time?
But udev will refuse to start or to install if the running kernel is
older then it?
--
O T A V I O S A L V A D O R
---------------------------------------------
E-mail: ota...@debian.org UIN: 5906116
GNU/Linux User: 239058 GPG ID: 49A5F855
Home Page: http://www.freedom.ind.br/otavio
---------------------------------------------
"Microsoft gives you Windows ... Linux gives
you the whole house."
Marco d'Itri
> But udev will refuse to start or to install if the running kernel is
> older then it?
As it currently happens, it will either:
- refuse to be upgraded
- be installed but not started if it was not installed yet
- not be started at boot time if the kernel is downgraded
--
ciao,
Marco
Sven Luther
Marco, we need to have a serious discussion about this udev thing. Now that
the ramdisk generator thingy is fixed or almost so, udev will be the next
major cause of pain for our users.
We need something which upgrades seamlessly, and the above solution is not
acceptable for the etch release, as has been said already in the past.
So, let's start to look for a real solution here, knowing that a kernel
upgrade will mean a reboot anyway, but there is really no need to impose two
reboots on the user.
You are the best placed to lead this discussion, so please contribute to it
with an open mind, and be tolerant if we propose stupid sollutions you already
rejected or such, as we (well at least i) don't know udev as well as you.
The facts as i understand them are (correct me if i am wrong) :
- older udev with newer kernel works mostly, but some events are lost.
- newer udev with older kernel breaks big time (no idea how it breaks
though).
- when upgrading newer udev, the older one is removed, thus triggering the
newer udev with older kernel problem.
=> this would mean that the only sane solution, as you proposed is to install
the newer udev after the kernel upgrade, but this is not practical.
Is it not possible to have a newer udev which is not removing the older udev,
so you have both installed, and the older udev will work with older kernels
and the newer udev will work with newer kernels ? This sounds like the sanest
solution (having udev install in /etc/udev and old-udev install in
/etc/udev-legacy or something ?).
Also, what about 2.4 kernels, they don't use udev right ? so the point is moot
with them, and the only problem is the sarge 2.6.8 -> etch 2.6.15+ upgrade
path.
Also, could you comment more about the many breakage we have recently seen
with udev, and if we can expect this to stabilize in the etch timeframe, or if
it will continue to be problematic ?
Thanks for your work on the udev package.
Friendly,
Sven Luther
Steve Langasek
> Now that 2.6.15 kernels are in testing I'd like to raise the kernel
> requirement for the udev package from 2.6.12 to 2.6.15 as soon as a new
> version of udev will have entered testing.
> This will let me remove a lot of cruft from the package.
> Does anybody have a reason to wait some more time?
Aside from it being a pain in my ass personally to have to constantly reboot
to continue using a non-chrooted up-to-date unstable system for development,
I suppose it doesn't make much difference whether 2.6.12 or 2.6.15 is the
break point, no. :P
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vor...@debian.org http://www.debian.org/
Bastian Blank
> We need something which upgrades seamlessly, and the above solution is not
> acceptable for the etch release, as has been said already in the past.
Hmm. Are there problems with the following:
- Upgrade works but asks the not yet completed dkt to disable old images
which raises a big fat warning that it needs a reboot.
- Refuse to start on startup if no compatible version is found.
It will also work with hand made kernels.
Bastian
--
Witch! Witch! They'll burn ya!
-- Hag, "Tomorrow is Yesterday", stardate unknown
Marco d'Itri
> We need something which upgrades seamlessly, and the above solution is not
> acceptable for the etch release, as has been said already in the past.
This would be nice, but so far nobody has been able to design anything
better, myself included.
> So, let's start to look for a real solution here, knowing that a kernel
> upgrade will mean a reboot anyway, but there is really no need to impose two
> reboots on the user.
My only alternate proposal is:
# disables the kernel version check
touch /etc/udev/force-upgrade
# this will also pull new initramfs, hal and $DEITY knows what else
apt-get install udev linux-image-whatever
# ASAP
reboot
But I am not sure about its merit.
It probably needs a few more tweaks to the package because postinst will
not be able to start udevd.
> - older udev with newer kernel works mostly, but some events are lost.
Not really. udev versions older than 072 do not support the new nested
classes used by the input subsystem in kernels >= 2.6.15.
The effect is that device nodes in /dev/input/ will not be created, and
the respective drivers will not be loaded.
Also, udev versions older than 059 have some bugs which break
referencing sysfs attributes since kernel 2.6.12.
The first problem is the important one.
> - newer udev with older kernel breaks big time (no idea how it breaks
> though).
They will not even start, because they depend on recent kernel features
like $MODALIAS variables and netlink uevents.
> - when upgrading newer udev, the older one is removed, thus triggering the
> newer udev with older kernel problem.
Correct.
> Is it not possible to have a newer udev which is not removing the older udev,
> so you have both installed, and the older udev will work with older kernels
> and the newer udev will work with newer kernels ?
I do not believe that this would be possible, at least for the general
case, because the version of udev in stable is almost a different
program with different interfaces with other system components.
> Also, what about 2.4 kernels, they don't use udev right ? so the point is moot
> with them, and the only problem is the sarge 2.6.8 -> etch 2.6.15+ upgrade
> path.
Correct.
> Also, could you comment more about the many breakage we have recently seen
> with udev, and if we can expect this to stabilize in the etch timeframe, or if
> it will continue to be problematic ?
Can you be more specific? I do not remember many breakages recently.
I am sure that I can manage to have a stable package ready in time for
the release, just like I did for sarge.
As a plus, udev and the related kernel interfaces are much more mature
and much less a moving target than two years ago, so I do not expect
more troubles in the future.
--
ciao,
Marco
Steve Langasek
> On Fri, Feb 10, 2006 at 07:57:25AM +0100, Sven Luther wrote:
> > We need something which upgrades seamlessly, and the above solution is not
> > acceptable for the etch release, as has been said already in the past.
> Hmm. Are there problems with the following:
> - Upgrade works but asks the not yet completed dkt to disable old images
> which raises a big fat warning that it needs a reboot.
Context from IRC:
01:55 < svenl> waldi: dkt ?
01:56 < waldi> svenl: the piece of software I just work on
01:56 < vorlon> which does what?
01:56 < waldi> https://lophos.multibuild.org/svn/dkt/trunk/doc/design
01:56 < waldi> it is mostly a generic replacement of update-grub
Anyway, I don't see that this is a very good solution. Disabling all of the
available boot options for the system doesn't prevent incidental breakage,
it just changes the *kind* of incidental breakage you get. The *least* bad
solution we have today is that some packages (lvm, udev) refuse in the
preinst to continue being installed when upgrading from sarge (lvm for
upgrades from either 2.4.27 or 2.6.8; udev from 2.6.8 only), and then the
user is left to figure out how to get a viable 2.6.1x kernel package onto
their system after a dist-upgrade has left God knows how many packages in an
unconfigured or inconsistent state.
Anything that introduces the possibility of the system breaking on
reboot/power failure is *worse* than this.
> - Refuse to start on startup if no compatible version is found.
What does this mean, exactly? Should that be "upgrade" instead of
"startup"? And how does that help us improve users' experience when
upgrading?
Bastian Blank
> Anyway, I don't see that this is a very good solution. Disabling all of the
> available boot options for the system doesn't prevent incidental breakage,
> it just changes the *kind* of incidental breakage you get.
It makes it impossible to break by accident. It don't help against hand
made breakages. This is a social problem which can't be fixed by a
technical solution.
> Anything that introduces the possibility of the system breaking on
> reboot/power failure is *worse* than this.
Hu? The kernel image have to be configured already.
> > - Refuse to start on startup if no compatible version is found.
> What does this mean, exactly? Should that be "upgrade" instead of
> "startup"? And how does that help us improve users' experience when
> upgrading?
Okay, both. It have to fail without error on upgrades to not break the
complete upgrade.
Bastian
--
He's dead, Jim.
-- McCoy, "The Devil in the Dark", stardate 3196.1
Steve Langasek
> On Fri, Feb 10, 2006 at 02:37:21AM -0800, Steve Langasek wrote:
> > Anyway, I don't see that this is a very good solution. Disabling all of the
> > available boot options for the system doesn't prevent incidental breakage,
> > it just changes the *kind* of incidental breakage you get.
> It makes it impossible to break by accident. It don't help against hand
> made breakages. This is a social problem which can't be fixed by a
> technical solution.
Then what does this have to do with the problem people are trying to solve?
The problem is that there is *no* kernel available in sarge that meets the
needs of the etch udev and lvm packages, and as a result people have to
install a new kernel, reboot, and then continue with the upgrade -- and
failing to follow these directions means hours of pain trying to recover
from an interrupted dist-upgrade (in particular for those users who have
little or no dpkg knowledge/experience).
> > Anything that introduces the possibility of the system breaking on
> > reboot/power failure is *worse* than this.
> Hu? The kernel image have to be configured already.
*What* kernel image?
Stephen Gran
> On Feb 10, Sven Luther <sven....@wanadoo.fr> wrote:
>
> > We need something which upgrades seamlessly, and the above solution is not
> > acceptable for the etch release, as has been said already in the past.
> This would be nice, but so far nobody has been able to design anything
> better, myself included.
[...]
> > Is it not possible to have a newer udev which is not removing the older udev,
> > so you have both installed, and the older udev will work with older kernels
> > and the newer udev will work with newer kernels ?
> I do not believe that this would be possible, at least for the general
> case, because the version of udev in stable is almost a different
> program with different interfaces with other system components.
In this case, does itmake any sense to treat the two versions of udev
similarly to how we treat library transitions? I.e., rename the new
udev to udev-$min-kernel-ver or something? (the name is ugly, but you
get the idea). The upgrade path won't be perfect, but it will have the
benefit of leaving the user with their current kernel + current udev at
the end, at which point they will need to install the newer udev and
newer kernel and reboot.
Just a thought,
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sg...@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
Sven Luther
> On Feb 10, Sven Luther <sven....@wanadoo.fr> wrote:
>
> > We need something which upgrades seamlessly, and the above solution is not
> > acceptable for the etch release, as has been said already in the past.
> This would be nice, but so far nobody has been able to design anything
> better, myself included.
Yeah, but more heads together searching actively may find a solution where
people alone have not.
More to this later, as i am busy, just a few comments now.
> > Is it not possible to have a newer udev which is not removing the older udev,
> > so you have both installed, and the older udev will work with older kernels
> > and the newer udev will work with newer kernels ?
> I do not believe that this would be possible, at least for the general
> case, because the version of udev in stable is almost a different
> program with different interfaces with other system components.
Notice, the only case we really have to deal with is the case where the system
is already running with a 2.6.8 (or random self built) kernel, using the older
udev, and we are installing a newer kernel and udev.
The 2.6.8 kernel is already running, and the kernel upgrade needs a reboot
anyway, so, we only need something that :
- don't mess up the currently running stuff, is it possible to have udev
installed to take effect after the next reboot, and keep the old udev live
until then ?
- installs without trouble.
- works fine when the newer kernel is booted into.
This should be possible without too much pain, it mostly depends on the first
item, which doesn't need a fully concurent udev, just that the currently
running one is kept upto the reboot.
Naturally, the problem with this approach is that if the reboot with the newer
kernel fails, then the user is hosed, but this can be worked with in some
manner.
So let's imagine the following scenario :
1) sarge-udev & etch-udev install concurently, maybe using the divert or
alternative mechanism to not overwrite their files.
2) when etch-udev is installed, it doesn't remove the older one, but also
doesn't activate itself.
3) at boot time, before any of the udev thingy is called, a script is run,
which checks the kernel version, and activate one of the two alternatives.
Well, it may even work in the general case, upto a point, not sure, but it
should be helpful at least in the sarge->etch upgrade scenario.
> > Also, what about 2.4 kernels, they don't use udev right ? so the point is moot
> > with them, and the only problem is the sarge 2.6.8 -> etch 2.6.15+ upgrade
> > path.
> Correct.
>
> > Also, could you comment more about the many breakage we have recently seen
> > with udev, and if we can expect this to stabilize in the etch timeframe, or if
> > it will continue to be problematic ?
> Can you be more specific? I do not remember many breakages recently.
I got a guy complaining about powerpc/alsa being broken this past week for
example, but i vaguely remember other issues these past month too.
> I am sure that I can manage to have a stable package ready in time for
> the release, just like I did for sarge.
Ah, it needs to be ready at etch freeze time, that is end of july.
> As a plus, udev and the related kernel interfaces are much more mature
> and much less a moving target than two years ago, so I do not expect
> more troubles in the future.
Which sounds cool, but doesn't help with sarge->etch upgrades sadly.
Mmm, this became longer than i thought it would.
Marco d'Itri
> The 2.6.8 kernel is already running, and the kernel upgrade needs a reboot
> anyway, so, we only need something that :
>
> - don't mess up the currently running stuff, is it possible to have udev
> installed to take effect after the next reboot, and keep the old udev live
> until then ?
>
> - installs without trouble.
>
> - works fine when the newer kernel is booted into.
I think that this can be arranged easily (by not killing the old udevd)
with a few package tweaks and should not cause any problems as long as
the next reboot will happen "soon".
I'm just not sure if it can/should be automatic too.
Even if for some reason the old daemon could not be kept running then
/dev will continue working until the next reboot.
> Naturally, the problem with this approach is that if the reboot with the newer
> kernel fails, then the user is hosed, but this can be worked with in some
> manner.
If the new kernel fails and users reboot again with the old kernel then
the system will boot using the static /dev. How much this will break is
system-dependent and impossible to predict.
> 1) sarge-udev & etch-udev install concurently, maybe using the divert or
> alternative mechanism to not overwrite their files.
As I explained, I do not believe that on-disk co-existence of two udev
packages is feasible.
> I got a guy complaining about powerpc/alsa being broken this past week for
Nobody reported this to me.
> Ah, it needs to be ready at etch freeze time, that is end of july.
This is a lot of time.
--
ciao,
Marco
Marco d'Itri
>In this case, does itmake any sense to treat the two versions of udev
>similarly to how we treat library transitions? I.e., rename the new
>udev to udev-$min-kernel-ver or something? (the name is ugly, but you
It's not clear which problem this would solve, exactly.
--
ciao,
Marco
--
To UNSUBSCRIBE, email to debian-rele...@lists.debian.org
Sven Luther
> On Feb 10, Sven Luther <sven....@wanadoo.fr> wrote:
>
> > The 2.6.8 kernel is already running, and the kernel upgrade needs a reboot
> > anyway, so, we only need something that :
> >
> > - don't mess up the currently running stuff, is it possible to have udev
> > installed to take effect after the next reboot, and keep the old udev live
> > until then ?
> >
> > - installs without trouble.
> >
> > - works fine when the newer kernel is booted into.
> I think that this can be arranged easily (by not killing the old udevd)
> with a few package tweaks and should not cause any problems as long as
> the next reboot will happen "soon".
> I'm just not sure if it can/should be automatic too.
Well, we put a pre-inst debconf question here, where we ask the user if he
wants to go ahead and reboot as soon after the install, or abort.
If he wants to go ahead, we doit and put a postinst deconf note stressing he
should reboot with the newer kernel ASAP (in the do-it-now style).
> Even if for some reason the old daemon could not be kept running then
> /dev will continue working until the next reboot.
Cool.
> > Naturally, the problem with this approach is that if the reboot with the newer
> > kernel fails, then the user is hosed, but this can be worked with in some
> > manner.
> If the new kernel fails and users reboot again with the old kernel then
> the system will boot using the static /dev. How much this will break is
> system-dependent and impossible to predict.
Ok, but there is a sane setup to fall back on. As i mentioned to Jonas, the
best way to recover from this is probably to boot into the recovery mode of
d-i anyway.
> > 1) sarge-udev & etch-udev install concurently, maybe using the divert or
> > alternative mechanism to not overwrite their files.
> As I explained, I do not believe that on-disk co-existence of two udev
> packages is feasible.
Mmm, even if for a short time as planed here ?
> > I got a guy complaining about powerpc/alsa being broken this past week for
> Nobody reported this to me.
Yeah, i asked him to file a bug report though, but you can't thrust those
powerpc guys to do that :)
> > Ah, it needs to be ready at etch freeze time, that is end of july.
> This is a lot of time.
Well, less than 6 months now, so now is the best time to handle this. We still
need to tackle the out-of-tree module issues, and the non-free firmware too.
Marco d'Itri
> > > 1) sarge-udev & etch-udev install concurently, maybe using the divert or
> > > alternative mechanism to not overwrite their files.
> > As I explained, I do not believe that on-disk co-existence of two udev
> > packages is feasible.
> Mmm, even if for a short time as planed here ?
I can't see how this would change anything.
> Well, less than 6 months now, so now is the best time to handle this. We still
> need to tackle the out-of-tree module issues, and the non-free firmware too.
FWIW, I plan to propose a GR to allow temporary distribution of
binary-only firmwares on our official install media.
--
ciao,
Marco
Sven Luther
> On Feb 10, Sven Luther <sven....@wanadoo.fr> wrote:
>
> > > > 1) sarge-udev & etch-udev install concurently, maybe using the divert or
> > > > alternative mechanism to not overwrite their files.
> > > As I explained, I do not believe that on-disk co-existence of two udev
> > > packages is feasible.
> > Mmm, even if for a short time as planed here ?
> I can't see how this would change anything.
Well, this could be part of a more generic roll-back of upgrades framework,
which i believe would have interest beyond the kernel/udev issue, but this is
vastly more work and time and effort than what we are speaking here.
> > Well, less than 6 months now, so now is the best time to handle this. We still
> > need to tackle the out-of-tree module issues, and the non-free firmware too.
> FWIW, I plan to propose a GR to allow temporary distribution of
> binary-only firmwares on our official install media.
Well, given that we voted twice about this, and that it needs a 3:1
super-majority, i have some doubts of this passing.
Bastian Blank
> Then what does this have to do with the problem people are trying to solve?
> The problem is that there is *no* kernel available in sarge that meets the
> needs of the etch udev and lvm packages, and as a result people have to
> install a new kernel, reboot, and then continue with the upgrade
No, they need to reboot after installing udev/lvm, not before.
> > Hu? The kernel image have to be configured already.
> *What* kernel image?
Which should be used.
Bastian
--
No one wants war.
-- Kirk, "Errand of Mercy", stardate 3201.7
Steve Langasek
> On Fri, Feb 10, 2006 at 03:45:28AM -0800, Steve Langasek wrote:
> > Then what does this have to do with the problem people are trying to solve?
> > The problem is that there is *no* kernel available in sarge that meets the
> > needs of the etch udev and lvm packages, and as a result people have to
> > install a new kernel, reboot, and then continue with the upgrade
> No, they need to reboot after installing udev/lvm, not before.
Then you've once again left the user without any assurance that their system
is bootable at the end of the udev/lvm install. We *must* avoid leaving the
user in a state where rebooting the system could leave /usr and /var
unmountable, the network inaccesible, and so on.
> > > Hu? The kernel image have to be configured already.
> > *What* kernel image?
> Which should be used.
I don't see anywhere you've specified a mechanism for determining what
kernel image this is, or ensuring that it is configured first.
Sven Luther
> - Doesn't fuck the system if you lose power part-way through the
> dist-upgrade after udev has been unpacked and no newer kernel has been
> installed.
Hehe, never thougth about that. i guess that having udev depend on a kernel
image of at least version foo, you solve this problem.
Naturally, if you have i-t include klibc and udev, then you are faced with a
chicken-and-egg problem :)
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to debian-rele...@lists.debian.org
Bastian Blank
> > No, they need to reboot after installing udev/lvm, not before.
> Then you've once again left the user without any assurance that their system
> is bootable at the end of the udev/lvm install.
Which is the same than the other way around. (For example the device
mapper api version changed around 2.6.5 and older devmapper versions was
not longer able to work.)
> We *must* avoid leaving the
> user in a state where rebooting the system could leave /usr and /var
> unmountable, the network inaccesible, and so on.
The old initrd is not changed at this time and can mount at least /.
> > Which should be used.
> I don't see anywhere you've specified a mechanism for determining what
> kernel image this is, or ensuring that it is configured first.
Hu?
Bastian
--
Killing is stupid; useless!
-- McCoy, "A Private Little War", stardate 4211.8
Steve Langasek
> On Fri, Feb 10, 2006 at 01:21:22PM -0800, Steve Langasek wrote:
> > - Doesn't fuck the system if you lose power part-way through the
> > dist-upgrade after udev has been unpacked and no newer kernel has been
> > installed.
> Hehe, never thougth about that. i guess that having udev depend on a kernel
> image of at least version foo, you solve this problem.
> Naturally, if you have i-t include klibc and udev, then you are faced with a
> chicken-and-egg problem :)
Yes, that's the circular dependency loop bug that's currently open on these
packages. AIUI, maks has already agreed to try to break this loop by making
i-t work with older udev.
Steve Langasek
> On Fri, Feb 10, 2006 at 01:30:51PM -0800, Steve Langasek wrote:
> > > No, they need to reboot after installing udev/lvm, not before.
> > Then you've once again left the user without any assurance that their system
> > is bootable at the end of the udev/lvm install.
> Which is the same than the other way around. (For example the device
> mapper api version changed around 2.6.5 and older devmapper versions was
> not longer able to work.)
Does this mean that the sarge lvm2 package doesn't work with kernels from
etch? If so, then bug #351679 *is* RC.
> > We *must* avoid leaving the
> > user in a state where rebooting the system could leave /usr and /var
> > unmountable, the network inaccesible, and so on.
> The old initrd is not changed at this time and can mount at least /.
This means you're not guaranteed to get /usr/sbin/sshd, which many admins
use exclusively for system administration where remote kvm is not an
affordable option. That's a pretty big problem.
> > > Which should be used.
> > I don't see anywhere you've specified a mechanism for determining what
> > kernel image this is, or ensuring that it is configured first.
> Hu?
The stated problem is that upgrades from sarge to etch require the user to
go to a bunch of extra work to change out their kernel before they can
dist-upgrade. I haven't heard you say "lvm will depend on the linux-image
package it needs", or anything equivalent, which means the preinst check for
running kernel version is the only protection against a completely broken
system.
Steve Langasek
Why temporary, out of curiosity? This doesn't seem like a temporary
problem; I think this is an issue that will be just as applicable for etch+1
as it is for etch, and I think we should be honest about that.
I also think it's within the realm of reason for us to decide that source
for things like firmware, fonts, and documentation is less important than it
is for programs.
Sven Luther
> This means you're not guaranteed to get /usr/sbin/sshd, which many admins
> use exclusively for system administration where remote kvm is not an
> affordable option. That's a pretty big problem.
Maybe we need a sshd in /sbin then, since as i understand there is no real
guarantee that /usr is mounted always in case of problems ?
> The stated problem is that upgrades from sarge to etch require the user to
> go to a bunch of extra work to change out their kernel before they can
> dist-upgrade. I haven't heard you say "lvm will depend on the linux-image
> package it needs", or anything equivalent, which means the preinst check for
> running kernel version is the only protection against a completely broken
> system.
Yeah, all that is the same problem, and we need to find a way of fixing it
before the sarge release.
Maybe generalizing the --supported-version used by the ramdisk-generator tools
would be an idea.
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to debian-rele...@lists.debian.org
Marco d'Itri
> Why temporary, out of curiosity? This doesn't seem like a temporary
> problem; I think this is an issue that will be just as applicable for etch+1
> as it is for etch, and I think we should be honest about that.
Because maybe in 5-10 years from now most hardware devices will have a
free firmware. I do not really believe that this will happen, but by
proposing an exception with a much limited scope than the past GR I hope
that it will be less controverial and easier to be approved.
Also note that I wrote "distribute on install media" and not "allow in
main".
> I also think it's within the realm of reason for us to decide that source
> for things like firmware, fonts, and documentation is less important than it
> is for programs.
I also plan a GR to accept in main "less free" artwork which if removed
does not change the functionality of the software using it (e.g. the
firefox logo).
--
ciao,
Marco
Sven Luther
> On Feb 11, Steve Langasek <vor...@debian.org> wrote:
>
> > Why temporary, out of curiosity? This doesn't seem like a temporary
> > problem; I think this is an issue that will be just as applicable for etch+1
> > as it is for etch, and I think we should be honest about that.
> Because maybe in 5-10 years from now most hardware devices will have a
> free firmware. I do not really believe that this will happen, but by
> proposing an exception with a much limited scope than the past GR I hope
> that it will be less controverial and easier to be approved.
> Also note that I wrote "distribute on install media" and not "allow in
> main".
As the install media are built our of main though, this is probably not going
to cut it without proof that it can be done on a technical point of view.
Why not simply have a non-free set of install media, and be done with it,
sounds like a much sanner proposal, without legal hurdle, just in need of
technical work.
Friendly,
Svne Luther
--
To UNSUBSCRIBE, email to debian-rele...@lists.debian.org
Marco d'Itri
> As the install media are built our of main though, this is probably not going
> to cut it without proof that it can be done on a technical point of view.
It could be main or a subset of non-free or a new section, it's just a
detail which I do not consider important.
> Why not simply have a non-free set of install media, and be done with it,
> sounds like a much sanner proposal, without legal hurdle, just in need of
> technical work.
Because I am interested in improving Debian, not some non-free
derivative.
--
ciao,
Marco
Mike Hommey
> I also plan a GR to accept in main "less free" artwork which if removed
> does not change the functionality of the software using it (e.g. the
> firefox logo).
The main problem with the firefox logo is not its non-freeness, but the
trademarks infringment associated with its use.
Mike
--
To UNSUBSCRIBE, email to debian-rele...@lists.debian.org
Sven Luther
> On Feb 11, Sven Luther <sven....@wanadoo.fr> wrote:
>
> > As the install media are built our of main though, this is probably not going
> > to cut it without proof that it can be done on a technical point of view.
> It could be main or a subset of non-free or a new section, it's just a
> detail which I do not consider important.
well, as the installer packages (and thus the install media) are autobuilt in
main, i think this is the clue of the problem.
> > Why not simply have a non-free set of install media, and be done with it,
> > sounds like a much sanner proposal, without legal hurdle, just in need of
> > technical work.
> Because I am interested in improving Debian, not some non-free
> derivative.
So, what is the difference in having non-free firmware in the non-free section
of the debian archive, or having non-free firmware somewhere as of yet
undefined, and then magically added to the installation media, which would
then be held in the debian archive.
I think having a non-free set of installation media together with a free one
is by far the more promising solution, and the more honest as well, and on top
of that doesn't need a GR.
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to debian-ker...@lists.debian.org
Stephen Gran
>
> >In this case, does it make any sense to treat the two versions of udev
> >similarly to how we treat library transitions? I.e., rename the new
> >udev to udev-$min-kernel-ver or something? (the name is ugly, but
> >you
> It's not clear which problem this would solve, exactly.
It could solve the 'I have overwritten the udev that worked with this
kernel with a udev that dies and leaves me unable to function' problem.
It is not a perfect idea, and I don't particularly like it (for
aesthetic reasons if nothing else). But if the best we can do is run
time checks to determine which kernel we are running on, then we may
need to support multiple udev versions.
Steve Langasek
> This one time, at band camp, Marco d'Itri said:
> > sg...@debian.org wrote:
> > >In this case, does it make any sense to treat the two versions of udev
> > >similarly to how we treat library transitions? I.e., rename the new
> > >udev to udev-$min-kernel-ver or something? (the name is ugly, but
> > >you
> > It's not clear which problem this would solve, exactly.
> It could solve the 'I have overwritten the udev that worked with this
> kernel with a udev that dies and leaves me unable to function' problem.
> It is not a perfect idea, and I don't particularly like it (for
> aesthetic reasons if nothing else). But if the best we can do is run
> time checks to determine which kernel we are running on, then we may
> need to support multiple udev versions.
The difficulty is in allowing multiple such udev packages to coexist
sensibly on the filesystem.
Stephen Gran
> On Sat, Feb 11, 2006 at 05:26:27PM +0000, Stephen Gran wrote:
> > This one time, at band camp, Marco d'Itri said:
> > > sg...@debian.org wrote:
>
> > > >In this case, does it make any sense to treat the two versions of
> > > >udev similarly to how we treat library transitions? I.e., rename
> > > >the new udev to udev-$min-kernel-ver or something? (the name is
> > > >ugly, but you
> > > It's not clear which problem this would solve, exactly.
>
> > It could solve the 'I have overwritten the udev that worked with
> > this kernel with a udev that dies and leaves me unable to function'
> > problem.
>
> > It is not a perfect idea, and I don't particularly like it (for
> > aesthetic reasons if nothing else). But if the best we can do is
> > run time checks to determine which kernel we are running on, then we
> > may need to support multiple udev versions.
>
> The difficulty is in allowing multiple such udev packages to coexist
> sensibly on the filesystem.
Trust me, I know - that's why I said I am not happy with this solution.
I am also not intimately familiar with the internals of udev to make
these sorts of decisions. My understanding of the problem is that
version foo of udev works with kernel version >= a and <= b, while
version bar of udev works with kernel versions > b. Making seperate
udev packages be coinstallable, and having the inappropriate one refuse
to start based on running kernel version was the first approach that
occured to me, but I do hope there are other ways to solve this. Making
a single udev that could handle events generated by both kernel
generations would be nice, for instance. I don't know how realistic
that idea is, though.
Either of these problems could probably be solved with something ugly
like putting the udev binaries in /lib/udev-$version and putting the
wrapper that selects the right version to run in /sbin, but again, it's
not perfectly pretty.
Take care,
Marco d'Itri
>Trust me, I know - that's why I said I am not happy with this solution.
>I am also not intimately familiar with the internals of udev to make
>these sorts of decisions. My understanding of the problem is that
Your understanding of the problem is very limited. A much bigger problem
is that "old udev" and "new udev" are programs which provide very
different features and have very different system interfaces.
Sven Luther
On Fri, Feb 10, 2006 at 11:27:12AM +0100, Marco d'Itri wrote:
> > - older udev with newer kernel works mostly, but some events are lost.
> Not really. udev versions older than 072 do not support the new nested
> classes used by the input subsystem in kernels >= 2.6.15.
> The effect is that device nodes in /dev/input/ will not be created, and
> the respective drivers will not be loaded.
> Also, udev versions older than 059 have some bugs which break
> referencing sysfs attributes since kernel 2.6.12.
> The first problem is the important one.
I have tried building a newer udev as a sarge backport, since i kind of lost
some functionality (like usb hotplug and autoloading of mass storage devices,
but it may be due to other issues), but i failed lamentability, since udev
pulled in a new module-init-tools and hald/dbus, which in turn pulled in qt4,
at which point i stopped.
Do you have already done backport packages, for running 2.6.15 and beyond
kernels on a sarge system, or are there real problem with trying to do this ?
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to debian-ker...@lists.debian.org
Marco d'Itri
> Do you have already done backport packages, for running 2.6.15 and beyond
> kernels on a sarge system, or are there real problem with trying to do this ?
I do not believe in backports, but here you can find a backported udev:
http://www.backports.org/debian/pool/main/u/udev/
I do not know nor I care how it works, but you can find in the
changelog some notes about why the versioned dependencies are required
and you can easily drop the m-i-t and dbus ones with minor fixes to their
configurations.
--
ciao,
Marco
Sven Luther
> On Feb 13, Sven Luther <sven....@wanadoo.fr> wrote:
>
> > Do you have already done backport packages, for running 2.6.15 and beyond
> > kernels on a sarge system, or are there real problem with trying to do this ?
> I do not believe in backports, but here you can find a backported udev:
>
> http://www.backports.org/debian/pool/main/u/udev/
Mmm, nice, but didn't work, built fine, but wanted to pull in m-i-t, and then
hal, ...
> I do not know nor I care how it works, but you can find in the
> changelog some notes about why the versioned dependencies are required
> and you can easily drop the m-i-t and dbus ones with minor fixes to their
> configurations.
What about the need for hal ? Which is the one which indirectly pulled in
dbus.
Marco d'Itri
> > I do not know nor I care how it works, but you can find in the
> > changelog some notes about why the versioned dependencies are required
> > and you can easily drop the m-i-t and dbus ones with minor fixes to their
> > configurations.
> What about the need for hal ? Which is the one which indirectly pulled in
> dbus.
Yes, I was thinking about hal. In this case you need to add
$env{SUBSYSTEM} as the argument to the programs run by its rules file.
--
ciao,
Marco
Steve Langasek
> On Fri, Feb 10, 2006 at 04:20:02PM -0800, Steve Langasek wrote:
> > This means you're not guaranteed to get /usr/sbin/sshd, which many admins
> > use exclusively for system administration where remote kvm is not an
> > affordable option. That's a pretty big problem.
> Maybe we need a sshd in /sbin then, since as i understand there is no real
> guarantee that /usr is mounted always in case of problems ?
No, we need to do a good job of *ensuring the system is safely rebootable
at all times*. Why should we be satisfied with upgrades that have to come
with a big warning label, "system may not boot back up completely if you
leave your desk for coffee and the power goes out"? I think we have every
right to expect more from Debian (and ourselves) than that.
Sven Luther
> On Sat, Feb 11, 2006 at 08:11:34AM +0100, Sven Luther wrote:
> > On Fri, Feb 10, 2006 at 04:20:02PM -0800, Steve Langasek wrote:
> > > This means you're not guaranteed to get /usr/sbin/sshd, which many admins
> > > use exclusively for system administration where remote kvm is not an
> > > affordable option. That's a pretty big problem.
>
> > Maybe we need a sshd in /sbin then, since as i understand there is no real
> > guarantee that /usr is mounted always in case of problems ?
>
> No, we need to do a good job of *ensuring the system is safely rebootable
> at all times*. Why should we be satisfied with upgrades that have to come
> with a big warning label, "system may not boot back up completely if you
> leave your desk for coffee and the power goes out"? I think we have every
> right to expect more from Debian (and ourselves) than that.
So, you want /usr/sbin/sshd to be runable even if /usr is not mounted ? What
about the case you have a corruption in /usr and only / is mounted read-only ?
I mean, that is what /bin and /sbin are for, to put in them whatever tools are
always needed by the system administrator, even if something has gone terribly
wrong.
Nathan Gray
half-configured system and no upgrade path.
I have kernel 2.6.10, but some program I was upgrading required a
newer udev than 056, or whatever I have now.
But, udev 084 (I believe that is the version) won't install because I
am not running a kernel 2.6.12 or higher, and kernel-image 2.6.15
won't install because it requires a newer udev than I have.
(Having packages.debian.org down doesn't help the situation, but that
is a different matter.)
In any case, I am unable to find any kernel images between 2.6.10 and
2.6.15 that I could try to install. Nor could I find any udev
packages between the version in stable (056?) and unstable (084?).
So, what can I do?
I don't know what is only half-configured, but my flatbed scanner is
now undetected.
Please CC replies to me, since I am not subscribed to the list.
If you need more information, please tell me which commands to run so
I can supply you with more information.
-kolibrie
Steve Langasek
> Well, here I am, the unknowledgeable user who is stuck with a
> half-configured system and no upgrade path.
> I have kernel 2.6.10, but some program I was upgrading required a
> newer udev than 056, or whatever I have now.
> But, udev 084 (I believe that is the version) won't install because I
> am not running a kernel 2.6.12 or higher, and kernel-image 2.6.15
> won't install because it requires a newer udev than I have.
> (Having packages.debian.org down doesn't help the situation, but that
> is a different matter.)
> In any case, I am unable to find any kernel images between 2.6.10 and
> 2.6.15 that I could try to install. Nor could I find any udev
> packages between the version in stable (056?) and unstable (084?).
This is bug #349354.
> So, what can I do?
Because you're upgrading from a 2.6.10 kernel, you can install yaird, which
should satisfy the dependencies of the new 2.6.15 kernel package without
requiring udev to be upgraded first.
You can also force the upgrade of udev by touching /etc/udev/force-upgrade
and calling dpkg --configure -a.
This is not a discussion list. If you have any other questions, please
follow up either to that bug report, or to debian-user.
Thanks,
Nathan Gray
> Because you're upgrading from a 2.6.10 kernel, you can install yaird, which
> should satisfy the dependencies of the new 2.6.15 kernel package without
> requiring udev to be upgraded first.
That worked. Thank you very much.
> This is not a discussion list. If you have any other questions, please
> follow up either to that bug report, or to debian-user.
Please forgive me for posting to the wrong list. Thank you for your
help in finding a solution.
-kolibrie