Profile 17.1 fails at the analyse stage

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Profile 17.1 fails at the analyse stage

William Kenworthy
I have converted 4 systems to the 17.1 profile but this one fails at the
first hurdle:

wifi ~ # eselect profile list
Available profile symlink targets:
  [1]   olympus:default/linux/amd64/17.0 (stable) *
  [2]   olympus:default/linux/amd64/17.0/selinux (stable)
  [3]   olympus:default/linux/amd64/17.0/hardened (stable)
  [4]   olympus:default/linux/amd64/17.0/hardened/selinux (stable)
  [5]   olympus:default/linux/amd64/17.0/desktop (stable)
  [6]   olympus:default/linux/amd64/17.0/desktop/gnome (stable)
  [7]   olympus:default/linux/amd64/17.0/desktop/gnome/systemd (stable)
  [8]   olympus:default/linux/amd64/17.0/desktop/plasma (stable)
  [9]   olympus:default/linux/amd64/17.0/desktop/plasma/systemd (stable)
  [10]  olympus:default/linux/amd64/17.0/developer (stable)
  [11]  olympus:default/linux/amd64/17.0/no-multilib (stable)
  [12]  olympus:default/linux/amd64/17.0/no-multilib/hardened (stable)
  [13]  olympus:default/linux/amd64/17.0/no-multilib/hardened/selinux
(stable)
  [14]  olympus:default/linux/amd64/17.0/systemd (stable)
  [15]  olympus:default/linux/amd64/17.0/x32 (dev)
  [16]  olympus:default/linux/amd64/17.1 (stable)
  [17]  olympus:default/linux/amd64/17.1/selinux (stable)
  [18]  olympus:default/linux/amd64/17.1/hardened (stable)
  [19]  olympus:default/linux/amd64/17.1/hardened/selinux (stable)
  [20]  olympus:default/linux/amd64/17.1/desktop (stable)
  [21]  olympus:default/linux/amd64/17.1/desktop/gnome (stable)
  [22]  olympus:default/linux/amd64/17.1/desktop/gnome/systemd (stable)
  [23]  olympus:default/linux/amd64/17.1/desktop/plasma (stable)
  [24]  olympus:default/linux/amd64/17.1/desktop/plasma/systemd (stable)
  [25]  olympus:default/linux/amd64/17.1/developer (stable)
  [26]  olympus:default/linux/amd64/17.1/no-multilib (stable)
  [27]  olympus:default/linux/amd64/17.1/no-multilib/hardened (stable)
  [28]  olympus:default/linux/amd64/17.1/no-multilib/hardened/selinux
(stable)
  [29]  olympus:default/linux/amd64/17.1/systemd (stable)
  [30]  olympus:default/linux/amd64/17.0/musl (exp)
  [31]  olympus:default/linux/amd64/17.0/musl/hardened (exp)
  [32]  olympus:default/linux/amd64/17.0/musl/hardened/selinux (exp)
  [33]  olympus:default/linux/amd64/17.0/uclibc (exp)
  [34]  olympus:default/linux/amd64/17.0/uclibc/hardened (exp)
wifi ~ # unsymlink-lib --analyze
/usr/lib needs to be a symlink to lib64!
wifi ~ # ls -al /usr/lib
lrwxrwxrwx 1 root root 10 Jan  4 13:37 /usr/lib -> /usr/lib64
wifi ~ #

The symlink looks the same as another unconverted system - so whats the
problem?


BillK'



Reply | Threaded
Open this post in threaded view
|

Re: Profile 17.1 fails at the analyse stage

Neil Bothwick
On Wed, 19 Jun 2019 20:45:03 +0800, Bill Kenworthy wrote:

> wifi ~ # unsymlink-lib --analyze
> /usr/lib needs to be a symlink to lib64!
> wifi ~ # ls -al /usr/lib
> lrwxrwxrwx 1 root root 10 Jan  4 13:37 /usr/lib -> /usr/lib64
> wifi ~ #
>
> The symlink looks the same as another unconverted system - so whats the
> problem?

On this system, /usr/lib is a symlink to lib64, as the message states,
not /usr/lib64

% ls -ld /usr/lib
lrwxrwxrwx 1 root root 5 Jul 16  2015 /usr/lib -> lib64


--
Neil Bothwick

TEXAS VIRUS: Makes sure that it's bigger than any other file.

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Profile 17.1 fails at the analyse stage

Jack
On 2019.06.19 14:10, Neil Bothwick wrote:

> On Wed, 19 Jun 2019 20:45:03 +0800, Bill Kenworthy wrote:
>
> > wifi ~ # unsymlink-lib --analyze
> > /usr/lib needs to be a symlink to lib64!
> > wifi ~ # ls -al /usr/lib
> > lrwxrwxrwx 1 root root 10 Jan  4 13:37 /usr/lib -> /usr/lib64
> > wifi ~ #
> >
> > The symlink looks the same as another unconverted system - so whats  
> the
> > problem?
>
> On this system, /usr/lib is a symlink to lib64, as the message states,
> not /usr/lib64
>
> % ls -ld /usr/lib
> lrwxrwxrwx 1 root root 5 Jul 16  2015 /usr/lib -> lib64
>
>
> --
> Neil Bothwick
Ah, I think we've gotten to a bad splitting of hairs.  /usr/lib ->  
lib64 and /usr/lib -> /usr/lib64 have the same effect, but are not  
quite the same.  The first is a relative symlink, the second is  
absolute, although both actually point to the same place.

Bill - you might try "rm /usr/lib" WITHOUT the trailing slash, to  
remove the symlink.  Then "ln -s lib64 /usr/lib" will recreate it in  
the form unsymlink-lib seems to require.

Jack
Reply | Threaded
Open this post in threaded view
|

Re: Profile 17.1 fails at the analyse stage

Neil Bothwick
On Wed, 19 Jun 2019 14:26:50 -0400, Jack wrote:

> On 2019.06.19 14:10, Neil Bothwick wrote:
> > On Wed, 19 Jun 2019 20:45:03 +0800, Bill Kenworthy wrote:
> >  
> > > wifi ~ # unsymlink-lib --analyze
> > > /usr/lib needs to be a symlink to lib64!
> > > wifi ~ # ls -al /usr/lib
> > > lrwxrwxrwx 1 root root 10 Jan  4 13:37 /usr/lib -> /usr/lib64
> > > wifi ~ #
> > >
> > > The symlink looks the same as another unconverted system - so
> > > whats    
> > the  
> > > problem?  
> >
> > On this system, /usr/lib is a symlink to lib64, as the message states,
> > not /usr/lib64
> >
> > % ls -ld /usr/lib
> > lrwxrwxrwx 1 root root 5 Jul 16  2015 /usr/lib -> lib64

> Ah, I think we've gotten to a bad splitting of hairs.  /usr/lib ->  
> lib64 and /usr/lib -> /usr/lib64 have the same effect, but are not  
> quite the same.  The first is a relative symlink, the second is  
> absolute, although both actually point to the same place.

That's what software does, it interprets things literally. It is looking
for a symlink to lib64 and finding something else. The fact that the
actual link is equivalent is also irrelevant.


--
Neil Bothwick

The severity of the itch is inversely proportional to the reach.

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Profile 17.1 fails at the analyse stage

Jack
On 2019.06.19 16:14, Neil Bothwick wrote:

> On Wed, 19 Jun 2019 14:26:50 -0400, Jack wrote:
>
> > On 2019.06.19 14:10, Neil Bothwick wrote:
> > > On Wed, 19 Jun 2019 20:45:03 +0800, Bill Kenworthy wrote:
> > >
> > > > wifi ~ # unsymlink-lib --analyze
> > > > /usr/lib needs to be a symlink to lib64!
> > > > wifi ~ # ls -al /usr/lib
> > > > lrwxrwxrwx 1 root root 10 Jan  4 13:37 /usr/lib -> /usr/lib64
> > > > wifi ~ #
> > > >
> > > > The symlink looks the same as another unconverted system - so
> > > > whats
> > > the
> > > > problem?
> > >
> > > On this system, /usr/lib is a symlink to lib64, as the message  
> states,
> > > not /usr/lib64
> > >
> > > % ls -ld /usr/lib
> > > lrwxrwxrwx 1 root root 5 Jul 16  2015 /usr/lib -> lib64
>
> > Ah, I think we've gotten to a bad splitting of hairs.  /usr/lib ->
> > lib64 and /usr/lib -> /usr/lib64 have the same effect, but are not
> > quite the same.  The first is a relative symlink, the second is
> > absolute, although both actually point to the same place.
>
> That's what software does, it interprets things literally. It is  
> looking
> for a symlink to lib64 and finding something else. The fact that the
> actual link is equivalent is also irrelevant.
Agreed, but in this case,  it is the end outcome which really matters,  
so I would consider that an inadequacy (not sure whether it quite  
counts as a bug) in the script.  It won't help the OP much, but filing  
a bug against unsymlink-lib might get acted on.  It is also possible to  
file an issue against it in its github repository.
Reply | Threaded
Open this post in threaded view
|

Re: Profile 17.1 fails at the analyse stage

William Kenworthy
In reply to this post by Jack
On 20/6/19 2:26 am, Jack wrote:

> On 2019.06.19 14:10, Neil Bothwick wrote:
>> On Wed, 19 Jun 2019 20:45:03 +0800, Bill Kenworthy wrote:
>>
>> > wifi ~ # unsymlink-lib --analyze
>> > /usr/lib needs to be a symlink to lib64!
>> > wifi ~ # ls -al /usr/lib
>> > lrwxrwxrwx 1 root root 10 Jan  4 13:37 /usr/lib -> /usr/lib64
>> > wifi ~ #
>> >
>> > The symlink looks the same as another unconverted system - so whats
>> the
>> > problem?
>>
>> On this system, /usr/lib is a symlink to lib64, as the message states,
>> not /usr/lib64
>>
>> % ls -ld /usr/lib
>> lrwxrwxrwx 1 root root 5 Jul 16  2015 /usr/lib -> lib64
>>
>>
>> --
>> Neil Bothwick
> Ah, I think we've gotten to a bad splitting of hairs.  /usr/lib ->
> lib64 and /usr/lib -> /usr/lib64 have the same effect, but are not
> quite the same.  The first is a relative symlink, the second is
> absolute, although both actually point to the same place.
>
> Bill - you might try "rm /usr/lib" WITHOUT the trailing slash, to
> remove the symlink.  Then "ln -s lib64 /usr/lib" will recreate it in
> the form unsymlink-lib seems to require.
>
> Jack

Thanks, nicely picked!

Hair split and now all works as intended.  Just found another system
with the same problem too.


BillK



Reply | Threaded
Open this post in threaded view
|

Re: Profile 17.1 fails at the analyse stage

Peter Humphrey-3
On Thursday, 20 June 2019 00:02:35 BST Bill Kenworthy wrote:
> On 20/6/19 2:26 am, Jack wrote:

> > Bill - you might try "rm /usr/lib" WITHOUT the trailing slash, to
> > remove the symlink.  Then "ln -s lib64 /usr/lib" will recreate it in
> > the form unsymlink-lib seems to require.
>
> Thanks, nicely picked!
>
> Hair split and now all works as intended.  Just found another system
> with the same problem too.

Why is it a problem? The instructions clearly stated that the symlink might
not be revmoved, and that you should remove it yourself in that case.

--
Regards,
Peter.




Reply | Threaded
Open this post in threaded view
|

Re: Profile 17.1 fails at the analyse stage

William Kenworthy
On 20/6/19 3:47 pm, Peter Humphrey wrote:

> On Thursday, 20 June 2019 00:02:35 BST Bill Kenworthy wrote:
>> On 20/6/19 2:26 am, Jack wrote:
>>> Bill - you might try "rm /usr/lib" WITHOUT the trailing slash, to
>>> remove the symlink.  Then "ln -s lib64 /usr/lib" will recreate it in
>>> the form unsymlink-lib seems to require.
>> Thanks, nicely picked!
>>
>> Hair split and now all works as intended.  Just found another system
>> with the same problem too.
> Why is it a problem? The instructions clearly stated that the symlink might
> not be revmoved, and that you should remove it yourself in that case.
>
Thats towards the end - I couldn't get past step 4 ...

BillK



Reply | Threaded
Open this post in threaded view
|

Re: Profile 17.1 fails at the analyse stage

Jack
In reply to this post by Peter Humphrey-3
On 6/20/19 3:47 AM, Peter Humphrey wrote:

> On Thursday, 20 June 2019 00:02:35 BST Bill Kenworthy wrote:
>> On 20/6/19 2:26 am, Jack wrote:
>>
>>> Bill - you might try "rm /usr/lib" WITHOUT the trailing slash, to
>>> remove the symlink.  Then "ln -s lib64 /usr/lib" will recreate it in
>>> the form unsymlink-lib seems to require.
>> Thanks, nicely picked!
>>
>> Hair split and now all works as intended.  Just found another system
>> with the same problem too.
> Why is it a problem? The instructions clearly stated that the symlink might
> not be revmoved, and that you should remove it yourself in that case.
The --analyze phase bailed out before even starting.  I filed an issue
upstream (mgorny's github repository) and he made a change (I didn't
look at the actual commit) so this situation should now be handled
correctly.  I think he did want to accept anything that ended up
pointing to the right place, but was afraid of ending up with an
unpredictable result, so now it will accept either the relative or
absolute form.  I don't know when he will release a new version.

Reply | Threaded
Open this post in threaded view
|

Re: Profile 17.1 fails at the analyse stage

Rich Freeman
On Thu, Jun 20, 2019 at 9:21 AM Jack <[hidden email]> wrote:
>
> The --analyze phase bailed out before even starting.  I filed an issue
> upstream (mgorny's github repository) and he made a change (I didn't
> look at the actual commit) so this situation should now be handled
> correctly.  I think he did want to accept anything that ended up
> pointing to the right place, but was afraid of ending up with an
> unpredictable result, so now it will accept either the relative or
> absolute form.  I don't know when he will release a new version.
>

IMO that was the right design choice.  You just don't want to mess
around with these symlinks without care, so it is better to test that
everything is as expected.  Otherwise you'll break some system that
somebody had tweaked 5 years ago and forgotten about.  This way the
edge cases get reported, and can be taken into account before opening
things up more...

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: Profile 17.1 fails at the analyse stage

William Kenworthy
On 20/6/19 9:40 pm, Rich Freeman wrote:

> On Thu, Jun 20, 2019 at 9:21 AM Jack <[hidden email]> wrote:
>> The --analyze phase bailed out before even starting.  I filed an issue
>> upstream (mgorny's github repository) and he made a change (I didn't
>> look at the actual commit) so this situation should now be handled
>> correctly.  I think he did want to accept anything that ended up
>> pointing to the right place, but was afraid of ending up with an
>> unpredictable result, so now it will accept either the relative or
>> absolute form.  I don't know when he will release a new version.
>>
> IMO that was the right design choice.  You just don't want to mess
> around with these symlinks without care, so it is better to test that
> everything is as expected.  Otherwise you'll break some system that
> somebody had tweaked 5 years ago and forgotten about.  This way the
> edge cases get reported, and can be taken into account before opening
> things up more...
>
2 out of 7 systems have this style symlink - one is quite old (many
years), the other only one year or so. How system level links would
happen in this way is strange.  Both systems have been through (in some
cases multiple) restores from backup which may have been the cause.


BillK