FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 07-03-2012, 10:43 PM
Dave Reisner
 
Default final leg of /lib removal

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.
 
Old 07-03-2012, 10:43 PM
Dave Reisner
 
Default final leg of /lib removal

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.
 
Old 07-03-2012, 11:34 PM
Kevin Chadwick
 
Default final leg of /lib removal

> 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.
__________________________________________________ ______
 
Old 07-04-2012, 12:55 AM
Dave Reisner
 
Default final leg of /lib removal

On Tue, Jul 03, 2012 at 11:41:08AM -0400, Dave Reisner wrote:
> 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

This is all complete, and is slowly moving into [testing] over the next
half hour or so. Final rebuild list looks like this:

kmod
linux
linux-lts
bash-completion
fcpci
fcpcmcia
nvidia
nvidia-lts
lirc

cdfs
ndiswrapper
r8168
r8168-lts
rt3562sta
vhba-module
virtualbox-modules
virtualbox-modules-lts

open-vm-tools-modules is a pain in the butt and has NOT been rebuilt
yet. I'll get to this tonight but just a heads up that there will be
some sort of a lag period before this is updated.

Again, please heed the warning from my original message if you're a
custom kernel user. If you can't immediately rebuild your kernel, a
quick *temporary* solution is to either move the module dir yourself or
symlink /usr/lib/modules back to /lib/modules. This *must* be done in
the near future (ominous!).

cheers,
Dave
 
Old 07-04-2012, 01:33 AM
Geert Hendrickx
 
Default final leg of /lib removal

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!
 
Old 07-04-2012, 05:47 AM
Oon-Ee Ng
 
Default final leg of /lib removal

On Tue, Jul 3, 2012 at 11:41 PM, Dave Reisner <d@falconindy.com> wrote:
<snip>
> - linux, linux-lts (diff for linux here: http://paste.xinu.at/LLd/)
<snip>

I'm basing my modifications to my PKGBUILDs on this, simple enough,
but a simple observation - ${pkgdir} is used throughout the PKGBUILD
except in the diff =) ditto for ${_kernver}
 
Old 07-04-2012, 08:18 AM
Thomas Bächler
 
Default final leg of /lib removal

Am 03.07.2012 18:22, schrieb Dave Reisner:
>> Why do we want /lib as a symlink to /usr/lib anyway? You could have the
>> directory /lib, only containing the symlinks for ld-linux.so.2 ->
>> /usr/lib/ld-linux.so.2 and ld-linux-x86_64.so.2 ->
>> /usr/lib/ld-linux-x86_64.so.2 (and, of course
>> /lib64/ld-linux-x86_64.so.2 for compatibility).
>>
>> I don't see any advantage in having the symlink /lib -> /usr/lib, except
>> a harder upgrade path where so many things could go wrong.
>>
>
> No offense, but you're a bit late to be trying to shoot this down only
> now.

Not trying to shoot anything down, I am just confused why the upgrade
path here was not made smoother. This will lead to problems and
shitstorms, and you know it.

> Perhaps you recall Tom's post (and ensuing discussion) from a few
> months ago:

I remember the discussion and the plan. I just still don't think it's a
good plan. Didn't I say something back then? Maybe not.
 
Old 07-04-2012, 08:36 AM
Allan McRae
 
Default final leg of /lib removal

On 04/07/12 18:18, Thomas Bächler wrote:
> Am 03.07.2012 18:22, schrieb Dave Reisner:
>>> Why do we want /lib as a symlink to /usr/lib anyway? You could have the
>>> directory /lib, only containing the symlinks for ld-linux.so.2 ->
>>> /usr/lib/ld-linux.so.2 and ld-linux-x86_64.so.2 ->
>>> /usr/lib/ld-linux-x86_64.so.2 (and, of course
>>> /lib64/ld-linux-x86_64.so.2 for compatibility).
>>>
>>> I don't see any advantage in having the symlink /lib -> /usr/lib, except
>>> a harder upgrade path where so many things could go wrong.
>>>
>>
>> No offense, but you're a bit late to be trying to shoot this down only
>> now.
>
> Not trying to shoot anything down, I am just confused why the upgrade
> path here was not made smoother. This will lead to problems and
> shitstorms, and you know it.
>

Note: the upgrade is simple when using supported packages... We don't
rebuild peoples packages for library soname bumps. Why would this be
any different?

Allan
 
Old 07-04-2012, 08:33 PM
Linas
 
Default final leg of /lib removal

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.
 
Old 07-09-2012, 11:38 AM
Genes MailLists
 
Default final leg of /lib removal

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/
 

Thread Tools




All times are GMT. The time now is 03:59 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org