Re: [arch-dev-public] [arch-general] [signoff] udev-145-1
Dan McGee wrote:
On Sun, Aug 2, 2009 at 9:21 PM, Gerardo Exequiel Pozzi<vmlinuz386@yahoo.com.ar> wrote:
Gerardo Exequiel Pozzi wrote:
Gerardo Exequiel Pozzi wrote:
Tobias Powalowski wrote:
Hi bump to latest udev version, please test it well. Has many new things included, which also dig in glib2 and libusb depend.
greetings tpowa
Sign-off both i686, x86_64.
All boot OK, (custom kernel no initrd) no special setups, like raid or lvm. My usb devices are with the correct perms (4-in-1 reader, pendrive, ipod, mp3 player). The firmware for my printer is loaded OK, and kvm-88 still boot both arches (Arch Linux kernel):)
One sidenote, this version support ACL, so I guess that is better now to switch /dev from ramfs to tmpfs in initscripts. (the current udev documentation talks about tmpfs not ramfs)
By the way, doing this also will help, at least in one step, this feature request (FS#15612 - better support for selinux) [#1]
I filled a FS [#1] with the patch
Sidenote2: This udev bump from minimal kernel version from 2.6.22 to 2.6.25 (mandatory) because use the signalfd(). An announce required?
Wowzers, I'm not so sure we want to do that. We just got scared with glibc from going past 2.6.18, this is a rather significant jump (and I know my current Xen kernel is .24).
Is there a way to build udev without requiring this call? The discussions with the minimal kernel version for our glibc did not even venture beyond the .24 version... Allan
On Mon, Aug 3, 2009 at 06:42, Allan McRae<allan@archlinux.org> wrote:
On Sun, Aug 2, 2009 at 9:21 PM, Gerardo Exequiel Pozzi<vmlinuz386@yahoo.com.ar> wrote:
Gerardo Exequiel Pozzi wrote: Sidenote2: This udev bump from minimal kernel version from 2.6.22 to 2.6.25 (mandatory) because use the signalfd(). An announce required? Wowzers, I'm not so sure we want to do that. We just got scared with glibc from going past 2.6.18, this is a rather significant jump (and I know my current Xen kernel is .24). Is there a way to build udev without requiring this call? The discussions with the minimal kernel version for our glibc did not even venture beyond
Dan McGee wrote: the .24 version...
I don't really understand why minimal .25 kernel is a problem? Aren't we the bleeding edge distro? -- Roman Kyrylych (Роман Кирилич)
On Mon, Aug 3, 2009 at 04:39, Roman Kyrylych<roman.kyrylych@gmail.com> wrote:
I don't really understand why minimal .25 kernel is a problem? Aren't we the bleeding edge distro?
For some virtualized providers (slicehost off the top of my head), they use their own kernel that isn't as up to date. This update would break all such hosted Arch servers.
On Mon, Aug 3, 2009 at 14:13, Daenyth Blank<daenyth+arch@gmail.com> wrote:
On Mon, Aug 3, 2009 at 04:39, Roman Kyrylych<roman.kyrylych@gmail.com> wrote:
I don't really understand why minimal .25 kernel is a problem? Aren't we the bleeding edge distro?
For some virtualized providers (slicehost off the top of my head), they use their own kernel that isn't as up to date. This update would break all such hosted Arch servers.
IgnorePkg? And how often are such hosted Arch servers updated anyway? And we do not support custom kernels officially anyway. What I'm trying to say is that holding updates because of this is not acceptable IMO. -- Roman Kyrylych (Роман Кирилич)
On Mon, 2009-08-03 at 15:47 +0300, Roman Kyrylych wrote:
On Mon, Aug 3, 2009 at 14:13, Daenyth Blank<daenyth+arch@gmail.com> wrote:
On Mon, Aug 3, 2009 at 04:39, Roman Kyrylych<roman.kyrylych@gmail.com> wrote:
I don't really understand why minimal .25 kernel is a problem? Aren't we the bleeding edge distro?
For some virtualized providers (slicehost off the top of my head), they use their own kernel that isn't as up to date. This update would break all such hosted Arch servers.
IgnorePkg? And how often are such hosted Arch servers updated anyway? And we do not support custom kernels officially anyway.
What I'm trying to say is that holding updates because of this is not acceptable IMO.
Not updating udev will keep us away from new innovations. For glibc, supporting kernel 2.6.18 means adding some compatibility code. For udev, staying compatible with 2.6.18 means no support for devicekit-* in the near future. People who are forced to use old kernels should just stick to an older udev, or use static /dev. These people will be locked out from new things like devicekit-power and devicekit-disks in the near future, but I assume people running old kernels because of virtualization won't run GNOME or KDE desktops on it.
On Mon, Aug 3, 2009 at 8:14 AM, Jan de Groot<jan@jgc.homeip.net> wrote:
On Mon, 2009-08-03 at 15:47 +0300, Roman Kyrylych wrote:
On Mon, Aug 3, 2009 at 14:13, Daenyth Blank<daenyth+arch@gmail.com> wrote:
On Mon, Aug 3, 2009 at 04:39, Roman Kyrylych<roman.kyrylych@gmail.com> wrote:
I don't really understand why minimal .25 kernel is a problem? Aren't we the bleeding edge distro?
For some virtualized providers (slicehost off the top of my head), they use their own kernel that isn't as up to date. This update would break all such hosted Arch servers.
IgnorePkg? And how often are such hosted Arch servers updated anyway? And we do not support custom kernels officially anyway.
What I'm trying to say is that holding updates because of this is not acceptable IMO.
I didn't say "holding updates", I just wanted to either find a workaround if available so as not to break user systems completely. Ever had to rescue a remote server because sshd didn't come up? Not supporting custom kernels *officially*? Of course. Not supporting custom kernels? Did something change in the past 4 years that I missed? I thought Arch was always a bit of a DIY distro, it's rather shortsighted to assume one kernel fits everyone...
Not updating udev will keep us away from new innovations. For glibc, supporting kernel 2.6.18 means adding some compatibility code. For udev, staying compatible with 2.6.18 means no support for devicekit-* in the near future. People who are forced to use old kernels should just stick to an older udev, or use static /dev. These people will be locked out from new things like devicekit-power and devicekit-disks in the near future, but I assume people running old kernels because of virtualization won't run GNOME or KDE desktops on it.
I'll shoot an email to Slicehost on my behalf to see what kernels they have available. What other VPS providers offer Arch? It isn't a tough thing to find out how much we can get away with here. -Dan
On Mon, Aug 3, 2009 at 16:46, Dan McGee<dpmcgee@gmail.com> wrote:
On Mon, Aug 3, 2009 at 8:14 AM, Jan de Groot<jan@jgc.homeip.net> wrote:
On Mon, 2009-08-03 at 15:47 +0300, Roman Kyrylych wrote:
On Mon, Aug 3, 2009 at 14:13, Daenyth Blank<daenyth+arch@gmail.com> wrote:
On Mon, Aug 3, 2009 at 04:39, Roman Kyrylych<roman.kyrylych@gmail.com> wrote:
I don't really understand why minimal .25 kernel is a problem? Aren't we the bleeding edge distro?
For some virtualized providers (slicehost off the top of my head), they use their own kernel that isn't as up to date. This update would break all such hosted Arch servers.
IgnorePkg? And how often are such hosted Arch servers updated anyway? And we do not support custom kernels officially anyway.
What I'm trying to say is that holding updates because of this is not acceptable IMO.
I didn't say "holding updates", I just wanted to either find a workaround if available so as not to break user systems completely.
I didn't mean you said that. My second sentence was more general.
Sidenote2: This udev bump from minimal kernel version from 2.6.22 to 2.6.25 (mandatory) because use the signalfd(). An announce required? Wowzers, I'm not so sure we want to do that.
We don't have a choice (at least I don't see it). I mean - suppose we patch udev to not use signalfd so it runs on 2.6.22 (which is a very bad idea IMO, but let's suppose) - we will have to bump our minimal kernel requirement at some time anyway, so I don't see a benefit in trying to workaround the version bump. I think people who use old kernels know what they are doing, and are smart enough to check the list of updates and read newsitems on the main site (which we should post about this) I don't think anyone blindly runs -Syu on a production server via ssh.
Ever had to rescue a remote server because sshd didn't come up?
I don't understand what your example has to do with this (udev vs sshd).
Not supporting custom kernels *officially*? Of course. Not supporting custom kernels? Did something change in the past 4 years that I missed? I thought Arch was always a bit of a DIY distro, it's rather shortsighted to assume one kernel fits everyone...
I didn't mean we should support only the latest and greatest default kernel. Rather I meant that we don't provide official out-of-the-box support for running on quite old or heavily customized kernels, so some user changes may be required, like in this case - adding udev to IgnorePkg until the hosting provider will update their kernel. I think such server could safely use old initscripts and udev and only update the required software like apache (due to security issues or bugfixes). P.S.: Since text cannot transfer intonation, I'd like to notice that my comments in this thread are by no means flaming. Just expressing some thoughts. -- Roman Kyrylych (Роман Кирилич)
Am Montag 03 August 2009 schrieb Roman Kyrylych:
On Mon, Aug 3, 2009 at 16:46, Dan McGee<dpmcgee@gmail.com> wrote:
On Mon, Aug 3, 2009 at 8:14 AM, Jan de Groot<jan@jgc.homeip.net> wrote:
On Mon, 2009-08-03 at 15:47 +0300, Roman Kyrylych wrote:
On Mon, Aug 3, 2009 at 14:13, Daenyth Blank<daenyth+arch@gmail.com> wrote:
On Mon, Aug 3, 2009 at 04:39, Roman Kyrylych<roman.kyrylych@gmail.com> wrote:
I don't really understand why minimal .25 kernel is a problem? Aren't we the bleeding edge distro?
For some virtualized providers (slicehost off the top of my head), they use their own kernel that isn't as up to date. This update would break all such hosted Arch servers.
IgnorePkg? And how often are such hosted Arch servers updated anyway? And we do not support custom kernels officially anyway.
What I'm trying to say is that holding updates because of this is not acceptable IMO.
I didn't say "holding updates", I just wanted to either find a workaround if available so as not to break user systems completely.
I didn't mean you said that. My second sentence was more general.
Sidenote2: This udev bump from minimal kernel version from 2.6.22 to 2.6.25 (mandatory) because use the signalfd(). An announce required?
Wowzers, I'm not so sure we want to do that.
We don't have a choice (at least I don't see it). I mean - suppose we patch udev to not use signalfd so it runs on 2.6.22 (which is a very bad idea IMO, but let's suppose) - we will have to bump our minimal kernel requirement at some time anyway, so I don't see a benefit in trying to workaround the version bump.
I think people who use old kernels know what they are doing, and are smart enough to check the list of updates and read newsitems on the main site (which we should post about this) I don't think anyone blindly runs -Syu on a production server via ssh.
Ever had to rescue a remote server because sshd didn't come up?
I don't understand what your example has to do with this (udev vs sshd).
Not supporting custom kernels *officially*? Of course. Not supporting custom kernels? Did something change in the past 4 years that I missed? I thought Arch was always a bit of a DIY distro, it's rather shortsighted to assume one kernel fits everyone...
I didn't mean we should support only the latest and greatest default kernel. Rather I meant that we don't provide official out-of-the-box support for running on quite old or heavily customized kernels, so some user changes may be required, like in this case - adding udev to IgnorePkg until the hosting provider will update their kernel. I think such server could safely use old initscripts and udev and only update the required software like apache (due to security issues or bugfixes).
P.S.: Since text cannot transfer intonation, I'd like to notice that my comments in this thread are by no means flaming. Just expressing some thoughts. Announcement on NEWS page was posted some time ago, shall we move it in?
-- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On Mon, 2009-08-10 at 14:39 +0200, Tobias Powalowski wrote:
Announcement on NEWS page was posted some time ago, shall we move it in?
Be sure to move util-linux-ng, e2fsprogs and hal also.
On Mon, Aug 10, 2009 at 15:49, Jan de Groot<jan@jgc.homeip.net> wrote:
On Mon, 2009-08-10 at 14:39 +0200, Tobias Powalowski wrote:
Announcement on NEWS page was posted some time ago, shall we move it in?
Be sure to move util-linux-ng, e2fsprogs and hal also.
Note that new mkswap will produce warning for users of encrypted swap on /dev/mapper, but the fix is need to be done in initscripts and new package needs to be tested etc., so IMHO it is okay to let a harmless warning appear for a small percentage of users. -- Roman Kyrylych (Роман Кирилич)
Am Montag 10 August 2009 schrieb Roman Kyrylych:
On Mon, Aug 10, 2009 at 15:49, Jan de Groot<jan@jgc.homeip.net> wrote:
On Mon, 2009-08-10 at 14:39 +0200, Tobias Powalowski wrote:
Announcement on NEWS page was posted some time ago, shall we move it in?
Be sure to move util-linux-ng, e2fsprogs and hal also.
Note that new mkswap will produce warning for users of encrypted swap on /dev/mapper, but the fix is need to be done in initscripts and new package needs to be tested etc., so IMHO it is okay to let a harmless warning appear for a small percentage of users. Due to the slicehost issue, shall we wait until they react on this? I'm don't like to depend on others for our package upgrades. Any other opinions?
greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On Mon, Aug 10, 2009 at 15:04, Tobias Powalowski<t.powa@gmx.de> wrote:
Due to the slicehost issue, shall we wait until they react on this? I'm don't like to depend on others for our package upgrades. Any other opinions?
As much as I dislike the idea of holding back an update, I think we really should in this case. Deploying it before hosting providers are ready (even if it's their own fault) is something that could, IMO, damage the credibility of Arch as a distro for production servers. We should give them a little time to roll out some sort of update.
Am Montag 10 August 2009 21:04:10 schrieb Tobias Powalowski:
Due to the slicehost issue, shall we wait until they react on this? I'm don't like to depend on others for our package upgrades. Any other opinions?
We cannot wait for every single provider to catch up; so why do this with this one here? We don't support keeping old versions of packages while updating all others; and that's what we have here in the end. -- Pierre Schmitz, http://users.archlinux.de/~pierre
On Mon, Aug 10, 2009 at 2:31 PM, Pierre Schmitz<pierre@archlinux.de> wrote:
Am Montag 10 August 2009 21:04:10 schrieb Tobias Powalowski:
Due to the slicehost issue, shall we wait until they react on this? I'm don't like to depend on others for our package upgrades. Any other opinions?
We cannot wait for every single provider to catch up; so why do this with this one here? We don't support keeping old versions of packages while updating all others; and that's what we have here in the end.
I agree with Pierre here. Even though I do have a slice, management of that slice is _my_ job. I've already attempted (and failed) the upgrade, so am aware of the problem. Adding udev to IgnorePkg isn't too hard, and that's kinda what it's made for
On Mon, 2009-08-10 at 14:33 -0500, Aaron Griffin wrote:
On Mon, Aug 10, 2009 at 2:31 PM, Pierre Schmitz<pierre@archlinux.de> wrote:
Am Montag 10 August 2009 21:04:10 schrieb Tobias Powalowski:
Due to the slicehost issue, shall we wait until they react on this? I'm don't like to depend on others for our package upgrades. Any other opinions?
We cannot wait for every single provider to catch up; so why do this with this one here? We don't support keeping old versions of packages while updating all others; and that's what we have here in the end.
I agree with Pierre here. Even though I do have a slice, management of that slice is _my_ job. I've already attempted (and failed) the upgrade, so am aware of the problem. Adding udev to IgnorePkg isn't too hard, and that's kinda what it's made for
The new udev will be a dependency for things like devicekit-power and devicekit-disks, but since those are things for the desktop stack, I don't see reason to have it on a slicehost server. BTW: Did anyone actually try to run this version of udev on an older kernel?
On Mon, Aug 10, 2009 at 2:36 PM, Jan de Groot<jan@jgc.homeip.net> wrote:
On Mon, 2009-08-10 at 14:33 -0500, Aaron Griffin wrote:
On Mon, Aug 10, 2009 at 2:31 PM, Pierre Schmitz<pierre@archlinux.de> wrote:
Am Montag 10 August 2009 21:04:10 schrieb Tobias Powalowski:
Due to the slicehost issue, shall we wait until they react on this? I'm don't like to depend on others for our package upgrades. Any other opinions?
We cannot wait for every single provider to catch up; so why do this with this one here? We don't support keeping old versions of packages while updating all others; and that's what we have here in the end.
I agree with Pierre here. Even though I do have a slice, management of that slice is _my_ job. I've already attempted (and failed) the upgrade, so am aware of the problem. Adding udev to IgnorePkg isn't too hard, and that's kinda what it's made for
The new udev will be a dependency for things like devicekit-power and devicekit-disks, but since those are things for the desktop stack, I don't see reason to have it on a slicehost server.
BTW: Did anyone actually try to run this version of udev on an older kernel?
Yeah, I tried it on my slice and it failed miserably. Posted this in another thread about this: (signalfd man page has sample code) agriffin@snarf:~$ man signalfd agriffin@snarf:~$ vim signalfd_demo.c agriffin@snarf:~$ gcc signalfd_demo.c -o signalfd_demo agriffin@snarf:~$ ./signalfd_demo signalfd: Function not implemented agriffin@snarf:~$ uname -a Linux snarf 2.6.24-24-xen #1 SMP Tue Jun 30 21:53:02 UTC 2009 x86_64 Dual-Core AMD Opteron(tm) Processor 2212 HE AuthenticAMD GNU/Linux
On Mon, Aug 10, 2009 at 22:33, Aaron Griffin<aaronmgriffin@gmail.com> wrote:
On Mon, Aug 10, 2009 at 2:31 PM, Pierre Schmitz<pierre@archlinux.de> wrote:
Am Montag 10 August 2009 21:04:10 schrieb Tobias Powalowski:
Due to the slicehost issue, shall we wait until they react on this? I'm don't like to depend on others for our package upgrades. Any other opinions?
We cannot wait for every single provider to catch up; so why do this with this one here? We don't support keeping old versions of packages while updating all others; and that's what we have here in the end.
I agree with Pierre here. Even though I do have a slice, management of that slice is _my_ job. I've already attempted (and failed) the upgrade, so am aware of the problem. Adding udev to IgnorePkg isn't too hard, and that's kinda what it's made for
BTW, can anyone explain why it is not possible to use newer kernel compiled with support for running under Xen instead of provided? I thought that only OpenVZ and similar stuff requires the same kernel as on host. -- Roman Kyrylych (Роман Кирилич)
On Mon, 2009-08-10 at 22:36 +0300, Roman Kyrylych wrote:
On Mon, Aug 10, 2009 at 22:33, Aaron Griffin<aaronmgriffin@gmail.com> wrote:
On Mon, Aug 10, 2009 at 2:31 PM, Pierre Schmitz<pierre@archlinux.de> wrote:
Am Montag 10 August 2009 21:04:10 schrieb Tobias Powalowski:
Due to the slicehost issue, shall we wait until they react on this? I'm don't like to depend on others for our package upgrades. Any other opinions?
We cannot wait for every single provider to catch up; so why do this with this one here? We don't support keeping old versions of packages while updating all others; and that's what we have here in the end.
I agree with Pierre here. Even though I do have a slice, management of that slice is _my_ job. I've already attempted (and failed) the upgrade, so am aware of the problem. Adding udev to IgnorePkg isn't too hard, and that's kinda what it's made for
BTW, can anyone explain why it is not possible to use newer kernel compiled with support for running under Xen instead of provided? I thought that only OpenVZ and similar stuff requires the same kernel as on host.
The kernel has to match the interface and architecture of the hypervisor. Besides that, the kernel usually doesn't get booted from your installation, but from the host installation. You can't just replace a xen kernel from the domU side, it has to happen from dom0.
participants (8)
-
Aaron Griffin
-
Allan McRae
-
Daenyth Blank
-
Dan McGee
-
Jan de Groot
-
Pierre Schmitz
-
Roman Kyrylych
-
Tobias Powalowski