Re: [arch-general] [arch-dev-public] final leg of /lib removal
Op dinsdag 3 juli 2012 11:41:08 schreef Dave Reisner:
Hey all,
*** If you use a custom kernel, this will affect you. Please read the big scary note at the end ***
I'm taking today to work on the last roadblock before Allan can move glibc out of /lib. This basically consists of a rebuild of:
- kmod (to drop our local patch) - linux, linux-lts (diff for linux here: http://paste.xinu.at/LLd/) - all OOT kernel modules (for /usr/lib/modules/extramodules-*) - bash-completion (temp patch until /lib is a symlink: http://paste.xinu.at/xEs/)
I'll be doing this all locally to avoid building against allan's new toolchain in [staging]. This will hopefully all hit [testing] by the end of the day. You know where to find me if you have any questions or angry rants.
If you'd like to do some early testing, I'm leaving the rebuilt kmod and kernel packages on gerolde:
http://dev.archlinux.org/~dreisner/linux-usrmove/
(i686 packages are lagging behind at the moment)
BIG SCARY NOTE: Due to the kmod changes, this will BREAK all module tools for users with their own kernels. If you do not rebuild your kernel after pulling in the new kmod, you're going to have a bad time. See the paste link above for inspiration.
Cheers! Dave
I'm replying on this in arch-general and aur-general because i cant post in arch-dev. So if i understand correctly we (the people running custom kernels) can't prepare for this ? There is no way of moving the modules already to /usr/lib ? I assume kmod now only looks in /lib. Another note, people with custom repositories should move their kernels in sync with the official repositories ? --Ike
On Tue, Jul 03, 2012 at 07:56:32PM +0200, Ike Devolder wrote:
Op dinsdag 3 juli 2012 11:41:08 schreef Dave Reisner:
Hey all,
*** If you use a custom kernel, this will affect you. Please read the big scary note at the end ***
I'm taking today to work on the last roadblock before Allan can move glibc out of /lib. This basically consists of a rebuild of:
- kmod (to drop our local patch) - linux, linux-lts (diff for linux here: http://paste.xinu.at/LLd/) - all OOT kernel modules (for /usr/lib/modules/extramodules-*) - bash-completion (temp patch until /lib is a symlink: http://paste.xinu.at/xEs/)
I'll be doing this all locally to avoid building against allan's new toolchain in [staging]. This will hopefully all hit [testing] by the end of the day. You know where to find me if you have any questions or angry rants.
If you'd like to do some early testing, I'm leaving the rebuilt kmod and kernel packages on gerolde:
http://dev.archlinux.org/~dreisner/linux-usrmove/
(i686 packages are lagging behind at the moment)
BIG SCARY NOTE: Due to the kmod changes, this will BREAK all module tools for users with their own kernels. If you do not rebuild your kernel after pulling in the new kmod, you're going to have a bad time. See the paste link above for inspiration.
Cheers! Dave
I'm replying on this in arch-general and aur-general because i cant post in arch-dev.
So if i understand correctly we (the people running custom kernels) can't prepare for this ?
I posted the new kmod package here explicitly so that users can get this package in preparation... I'll post it again since I changed the server I'm hosting these on: updated URL: http://pkgbuild.com/~dreisner/linux-usrmove/
There is no way of moving the modules already to /usr/lib ? I assume kmod now only looks in /lib.
Currently, kmod is patched to respect config dirs in /usr/lib, but modules in /lib. After removing the patch, it uniformly searches /usr/lib for everything (I'm intentionally ignoring /etc and /run here).
Another note, people with custom repositories should move their kernels in sync with the official repositories ?
--Ike
As with any large change, I'll mention on dev-public when this goes to testing, and there will be an associated news item when it moves to core. I realize this is a harsh change, but I don't really have many options for doing this more smoothly. If you're using the stock kernel, this should all just work. mkinitcpio has supported this setup for months now, and I've had my own kernel in /usr/lib/modules for almost as long. Worst case scenario, users of custom kernels can: - manually move /lib/modules/mycustomkernel to /usr/lib/modules/ until they can do a proper rebuild. - boot a stock -ARCH kernel (you DO have it listed as a fallback, right?) until they can do a proper rebuild. Emphasis on "until they can do a proper rebuild". It's important that this all gets done before we introduce a new glibc package that wipes out /lib entirely. If you have custom kernel bits lying around in /lib/modules, it's going to block the eventual glibc upgrade that brings this (no, it won't be immediately with 2.16). dave
On Jul 3, 2012 8:18 PM, "Dave Reisner" <d@falconindy.com> wrote:
On Tue, Jul 03, 2012 at 07:56:32PM +0200, Ike Devolder wrote:
Op dinsdag 3 juli 2012 11:41:08 schreef Dave Reisner:
Hey all,
*** If you use a custom kernel, this will affect you. Please read the big scary note at the end ***
I'm taking today to work on the last roadblock before Allan can move glibc out of /lib. This basically consists of a rebuild of:
- kmod (to drop our local patch) - linux, linux-lts (diff for linux here: http://paste.xinu.at/LLd/) - all OOT kernel modules (for /usr/lib/modules/extramodules-*) - bash-completion (temp patch until /lib is a symlink: http://paste.xinu.at/xEs/)
I'll be doing this all locally to avoid building against allan's new toolchain in [staging]. This will hopefully all hit [testing] by the end of the day. You know where to find me if you have any questions or angry rants.
If you'd like to do some early testing, I'm leaving the rebuilt kmod
and
kernel packages on gerolde:
http://dev.archlinux.org/~dreisner/linux-usrmove/
(i686 packages are lagging behind at the moment)
BIG SCARY NOTE: Due to the kmod changes, this will BREAK all module tools for users with their own kernels. If you do not rebuild your kernel after pulling in the new kmod, you're going to have a bad time. See the paste link above for inspiration.
Cheers! Dave
I'm replying on this in arch-general and aur-general because i cant post in arch-dev.
So if i understand correctly we (the people running custom kernels) can't prepare for this ?
I posted the new kmod package here explicitly so that users can get this package in preparation... I'll post it again since I changed the server I'm hosting these on:
updated URL: http://pkgbuild.com/~dreisner/linux-usrmove/
There is no way of moving the modules already to /usr/lib ? I assume kmod now only looks in /lib.
Currently, kmod is patched to respect config dirs in /usr/lib, but modules in /lib. After removing the patch, it uniformly searches /usr/lib for everything (I'm intentionally ignoring /etc and /run here).
Another note, people with custom repositories should move their kernels in sync with the official repositories ?
--Ike
As with any large change, I'll mention on dev-public when this goes to testing, and there will be an associated news item when it moves to core.
And a post upgrade message from kmod?
I realize this is a harsh change, but I don't really have many options for doing this more smoothly. If you're using the stock kernel, this should all just work. mkinitcpio has supported this setup for months now, and I've had my own kernel in /usr/lib/modules for almost as long.
Worst case scenario, users of custom kernels can:
- manually move /lib/modules/mycustomkernel to /usr/lib/modules/ until they can do a proper rebuild. - boot a stock -ARCH kernel (you DO have it listed as a fallback, right?) until they can do a proper rebuild.
Emphasis on "until they can do a proper rebuild". It's important that this all gets done before we introduce a new glibc package that wipes out /lib entirely. If you have custom kernel bits lying around in /lib/modules, it's going to block the eventual glibc upgrade that brings this (no, it won't be immediately with 2.16).
dave
On Tue, Jul 3, 2012 at 8:18 PM, Dave Reisner <d@falconindy.com> wrote:
As with any large change, I'll mention on dev-public when this goes to testing, and there will be an associated news item when it moves to core.
I suggest also adding a post-upgrade message to kmod. Something like: "Kernel modules are now read from /usr/lib/modules, all custom built modules must be moved there before rebooting." We all know that no one reads the news items, nor dev-public, so I think adding an extra warning should save us a few hundred mails/forumposts/IRC conversations. -t
On Jul 4, 2012 3:38 AM, "Tom Gundersen" <teg@jklm.no> wrote:
We all know that no one reads the news items, nor dev-public, so I think adding an extra warning should save us a few hundred mails/forumposts/IRC conversations.
-t
I see a good opportunity to start pruning the list of users of all the above channels =). The same users who don't read the above may not notice post-upgrade messages either. On the flip side, most custom kernel users should be more savvy than the average, do I don't see much of a problem. I maintain two aur kennels, shall I implement the move now (seems like it'd work even before kmod upgrades)?
On Wed, Jul 04, 2012 at 06:42:09AM +0800, Oon-Ee Ng wrote:
On Jul 4, 2012 3:38 AM, "Tom Gundersen" <teg@jklm.no> wrote:
We all know that no one reads the news items, nor dev-public, so I think adding an extra warning should save us a few hundred mails/forumposts/IRC conversations.
-t
I see a good opportunity to start pruning the list of users of all the above channels =). The same users who don't read the above may not notice post-upgrade messages either.
On the flip side, most custom kernel users should be more savvy than the average, do I don't see much of a problem. I maintain two aur kennels, shall I implement the move now (seems like it'd work even before kmod upgrades)?
No, this won't work pre-kmod update. You either read modules from /lib/modules or /usr/lib/modules. Not both.
On 04/07/12 00:43, Dave Reisner wrote:
On Wed, Jul 04, 2012 at 06:42:09AM +0800, Oon-Ee Ng wrote:
On the flip side, most custom kernel users should be more savvy than the average, do I don't see much of a problem. I maintain two aur kennels, shall I implement the move now (seems like it'd work even before kmod upgrades)? No, this won't work pre-kmod update. You either read modules from /lib/modules or /usr/lib/modules. Not both. I guess you could rebuild it now with a depends on kmod >= 9-2 to avoid a premature update. kmod should probably also have a depends on the newer linux package version so that you can't install the new linux package with older kmod, or old linux with new kmod.
After the latest glibc update in testing I found the following issue. The udpate to glibc 2.16.0-2 went well - and /lib is now a soft link to /usr/lib. Things seemed to be fine - I was using computer with no problems, then after a sleep/resume cycle my kde session logged me out. I rebooted for good measure. Now certain bash commands (e.g. "su -") give this error (sorry for wrap) -bash: warning: setlocale: LC_CTYPE: cannot change locale (en_US.UTF-8): No such file or directory -bash: warning: setlocale: LC_NUMERIC: cannot change locale (en_US.UTF-8): No such file or directory -bash: warning: setlocale: LC_TIME: cannot change locale (en_US.UTF-8): No such file or directory -bash: warning: setlocale: LC_COLLATE: cannot change locale (en_US.UTF-8): No such file or directory -bash: warning: setlocale: LC_MESSAGES: cannot change locale (en_US.UTF-8): No such file or directory Any suggestions how I can fix it? The udpate to glibc 2.16.0-2 went well - and /lib is now a soft link to /usr/lib. Thanks gene/
On Mon, Jul 9, 2012 at 2:38 PM, Genes MailLists <lists@sapience.com> wrote:
-bash: warning: setlocale: LC_CTYPE: cannot change locale (en_US.UTF-8): No such file or directory -bash: warning: setlocale: LC_NUMERIC: cannot change locale (en_US.UTF-8): No such file or directory -bash: warning: setlocale: LC_TIME: cannot change locale (en_US.UTF-8): No such file or directory -bash: warning: setlocale: LC_COLLATE: cannot change locale (en_US.UTF-8): No such file or directory -bash: warning: setlocale: LC_MESSAGES: cannot change locale (en_US.UTF-8): No such file or directory
Any suggestions how I can fix it?
`locale-gen` should help. -- Mantas Mikulėnas
On lun 09/07/12, 07:38, Genes MailLists wrote:
Now certain bash commands (e.g. "su -") give this error (sorry for wrap)
-bash: warning: setlocale: LC_CTYPE: cannot change locale (en_US.UTF-8): No such file or directory -bash: warning: setlocale: LC_NUMERIC: cannot change locale (en_US.UTF-8): No such file or directory -bash: warning: setlocale: LC_TIME: cannot change locale (en_US.UTF-8): No such file or directory -bash: warning: setlocale: LC_COLLATE: cannot change locale (en_US.UTF-8): No such file or directory -bash: warning: setlocale: LC_MESSAGES: cannot change locale (en_US.UTF-8): No such file or directory The udpate to glibc 2.16.0-2 went well - and /lib is now a soft link to /usr/lib.
I do not think that your glibc update went really well, because the locales have not been generated (and this should have happened when glibc was updated). Since you are nonetheless out of the /lib-symlinks hell, I think that reinstalling glibc should be safe for you and perhaps solve your issue: #pacman -S glibc Giorgio
Worst case scenario, users of custom kernels can:
- manually move /lib/modules/mycustomkernel to /usr/lib/modules/ until they can do a proper rebuild. - boot a stock -ARCH kernel (you DO have it listed as a fallback, right?) until they can do a proper rebuild.
Wouldn't another option be to build all important modules into the kernel? -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________
On Wed, Jul 4, 2012 at 1:34 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
Worst case scenario, users of custom kernels can:
- manually move /lib/modules/mycustomkernel to /usr/lib/modules/ until they can do a proper rebuild. - boot a stock -ARCH kernel (you DO have it listed as a fallback, right?) until they can do a proper rebuild.
Wouldn't another option be to build all important modules into the kernel?
Sure, it would let you boot, but you'll still have to move over all the "unimportant" ones... -t
On Tue, Jul 03, 2012 at 14:18:07 -0400, Dave Reisner wrote:
Worst case scenario, users of custom kernels can:
- manually move /lib/modules/mycustomkernel to /usr/lib/modules/ until they can do a proper rebuild. - boot a stock -ARCH kernel (you DO have it listed as a fallback, right?) until they can do a proper rebuild.
Emphasis on "until they can do a proper rebuild". It's important that this all gets done before we introduce a new glibc package that wipes out /lib entirely. If you have custom kernel bits lying around in /lib/modules, it's going to block the eventual glibc upgrade that brings this (no, it won't be immediately with 2.16).
dave
What will be the situation for VM users, where /lib/modules is managed externally by the VM hoster, but the kmod package by the VM customer? After moving the current modules manually, will we get away with a symlink /lib/modules -> /usr/lib/modules to support future kernel upgrades? (the kernel upgrade procedure will typically take down the VM, mount the filesystem on the host directly to install new modules, and boot the VM with the new kernel, so no opportunity for the VM customer to manually interact before boot.) Geert -- geert.hendrickx.be :: geert@hendrickx.be :: PGP: 0xC4BB9E9F This e-mail was composed using 100% recycled spam messages!
participants (10)
-
Dave Reisner
-
Geert Hendrickx
-
Genes MailLists
-
Giorgio Lando
-
Ike Devolder
-
Kevin Chadwick
-
Linas
-
Mantas Mikulėnas
-
Oon-Ee Ng
-
Tom Gundersen