Re: Bug#928924: user-mode-linux: xterm functionality broken due to wrong path to port-helper

Re: Bug#928924: user-mode-linux: xterm functionality broken due to wrong path to port-helper

[Ritesh Raj Sarraf]

[-- Attachment #1.1: Type: text/plain, Size: 2265 bytes --]

Control: tag -1 +help

On Mon, 2020-01-06 at 10:38 +0100, Sjoerd Simons wrote:
> On my sid system:
> ```
> $ strings /usr/bin/linux.uml | grep port-helper
> /usr/lib//uml/port-helper
> ```
> 
> So the path is still incorrect even with newer upstream kernels.

I spent some time today looking at the new build but I haven't been
able to ascertain why this isn't setting the correct path.

```
$ strings `which  linux.uml` | grep port-helper
/usr/lib/uml/port-helper
```

First, for context to the readers here, the port-helper binary is
shipped with uml-utilities package. This package, depending on the
architecture, installs the binary to a architecture specific location.

https://sources.debian.org/src/uml-utilities/20070815.2-1/Makefile/#L10

Which on an amd64 machine is: /usr/lib64/uml/port-helper

```
$ dpkg  -S /usr/lib64/uml/port-helper
uml-utilities: /usr/lib64/uml/port-helper
```

The UML setup on my box always worked because long back, when I first
encountered this problem, I had created a symlink of the path to
/usr/lib/ too. And had completely forgotten about it. My apologies.


But that said, the current problem is with the UML binary built by the
kernel sources.
Problem is that, as mentioned above and other reports too on this bug
report thread, the path resolved at build time is always
"/usr/lib/uml/".

The build configuration and the code are all correct.

```
$ grep 64BIT .config
CONFIG_64BIT=y
CONFIG_64BIT_TIME=y
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
```


Snipped from: arch/um/include/shared/os.h

```
#ifdef CONFIG_64BIT
#define OS_LIB_PATH     "/usr/lib64/"
#else
#define OS_LIB_PATH     "/usr/lib/"
#endif
```

I also checked the generated include headers and they are correct for
the amd64 .config file.

```
linux-source-5.4/include/generated$ grep 64BIT autoconf.h 
#define CONFIG_64BIT_TIME 1
#define CONFIG_PHYS_ADDR_T_64BIT 1
#define CONFIG_64BIT 1
#define CONFIG_ARCH_DMA_ADDR_T_64BIT 1
```

I'll keep looking as time permits but if anyone else has ideas on what
I may be doing wrong, please do mention.

Thanks,
Ritesh

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 152 bytes --]

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: Bug#928924: user-mode-linux: xterm functionality broken due to wrong path to port-helper

[Anton Ivanov]

On 06/01/2020 16:21, Ritesh Raj Sarraf wrote:
> Control: tag -1 +help
> 
> On Mon, 2020-01-06 at 10:38 +0100, Sjoerd Simons wrote:
>> On my sid system:
>> ```
>> $ strings /usr/bin/linux.uml | grep port-helper
>> /usr/lib//uml/port-helper
>> ```
>>
>> So the path is still incorrect even with newer upstream kernels.
> 
> I spent some time today looking at the new build but I haven't been
> able to ascertain why this isn't setting the correct path.

It is used in a "user" side file - xterm.c

None of these sees "CONFIG_" so it considers it undef-ed which defaults 
to 32 bit.

You need to use some other way to figure out what is the build or to set 
OS_LIB_PATH for this case.

> 
> ```
> $ strings `which  linux.uml` | grep port-helper
> /usr/lib/uml/port-helper
> ```
> 
> First, for context to the readers here, the port-helper binary is
> shipped with uml-utilities package. This package, depending on the
> architecture, installs the binary to a architecture specific location.
> 
> https://sources.debian.org/src/uml-utilities/20070815.2-1/Makefile/#L10
> 
> Which on an amd64 machine is: /usr/lib64/uml/port-helper
> 
> ```
> $ dpkg  -S /usr/lib64/uml/port-helper
> uml-utilities: /usr/lib64/uml/port-helper
> ```
> 
> The UML setup on my box always worked because long back, when I first
> encountered this problem, I had created a symlink of the path to
> /usr/lib/ too. And had completely forgotten about it. My apologies.
> 
> 
> But that said, the current problem is with the UML binary built by the
> kernel sources.
> Problem is that, as mentioned above and other reports too on this bug
> report thread, the path resolved at build time is always
> "/usr/lib/uml/".
> 
> The build configuration and the code are all correct.
> 
> ```
> $ grep 64BIT .config
> CONFIG_64BIT=y
> CONFIG_64BIT_TIME=y
> CONFIG_PHYS_ADDR_T_64BIT=y
> CONFIG_ARCH_DMA_ADDR_T_64BIT=y
> ```
> 
> 
> Snipped from: arch/um/include/shared/os.h
> 
> ```
> #ifdef CONFIG_64BIT
> #define OS_LIB_PATH     "/usr/lib64/"
> #else
> #define OS_LIB_PATH     "/usr/lib/"
> #endif
> ```
> 
> I also checked the generated include headers and they are correct for
> the amd64 .config file.
> 
> ```
> linux-source-5.4/include/generated$ grep 64BIT autoconf.h
> #define CONFIG_64BIT_TIME 1
> #define CONFIG_PHYS_ADDR_T_64BIT 1
> #define CONFIG_64BIT 1
> #define CONFIG_ARCH_DMA_ADDR_T_64BIT 1
> ```
> 
> I'll keep looking as time permits but if anyone else has ideas on what
> I may be doing wrong, please do mention.
> 
> Thanks,
> Ritesh
> 
> 
> _______________________________________________
> linux-um mailing list
> linux-um@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-um
> 

-- 
Anton R. Ivanov
https://www.kot-begemot.co.uk/

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: Bug#928924: user-mode-linux: xterm functionality broken due to wrong path to port-helper

[Ritesh Raj Sarraf]

[-- Attachment #1.1: Type: text/plain, Size: 1342 bytes --]

On Mon, 2020-01-06 at 21:51 +0530, Ritesh Raj Sarraf wrote:
> First, for context to the readers here, the port-helper binary is
> shipped with uml-utilities package. This package, depending on the
> architecture, installs the binary to a architecture specific
> location.
> 
> https://sources.debian.org/src/uml-utilities/20070815.2-1/Makefile/#L10
> 
> Which on an amd64 machine is: /usr/lib64/uml/port-helper

So 2 things I noticed on my machine.

1. There's nothing else under /usr/lib64/ on my Debian box. Even UML's
modules are built and installed under /usr/lib/

```
rrs@priyasi:/usr/lib$ ls uml/modules/5.4.6/
kernel/        modules.alias.bin  modules.builtin.bin      modules.dep 
     modules.devname  modules.softdep  modules.symbols.bin
modules.alias  modules.builtin    modules.builtin.modinfo  modules.dep.
bin  modules.order    modules.symbols
22:18 ♒ ॐ  ☺ 😄    
rrs@priyasi:/usr/lib$ ls ../lib64/
uml/
22:18 ♒ ॐ  ☺ 😄    
rrs@priyasi:/usr/lib$ ls ../lib64/uml/
port-helper*
22:18 ♒ ॐ  ☺ 😄    
```


2. Given that /usr/lib64/ is empty, quick immediate workaround could be to patch uml-utilities
and ship the binary under /usr/lib/. That would solve all these issues.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 152 bytes --]

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: Bug#928924: user-mode-linux: xterm functionality broken due to wrong path to port-helper

[Ritesh Raj Sarraf]

[-- Attachment #1.1: Type: text/plain, Size: 959 bytes --]

On Mon, 2020-01-06 at 16:58 +0000, Anton Ivanov wrote:
> On 06/01/2020 16:21, Ritesh Raj Sarraf wrote:
> > Control: tag -1 +help
> > 
> > On Mon, 2020-01-06 at 10:38 +0100, Sjoerd Simons wrote:
> > > On my sid system:
> > > ```
> > > $ strings /usr/bin/linux.uml | grep port-helper
> > > /usr/lib//uml/port-helper
> > > ```
> > > 
> > > So the path is still incorrect even with newer upstream kernels.
> > 
> > I spent some time today looking at the new build but I haven't been
> > able to ascertain why this isn't setting the correct path.
> 
> It is used in a "user" side file - xterm.c
> 
> None of these sees "CONFIG_" so it considers it undef-ed which
> defaults 
> to 32 bit.
> 
> You need to use some other way to figure out what is the build or to
> set 
> OS_LIB_PATH for this case.

Thank you for the quick reply Anton.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 152 bytes --]

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: Bug#928924: user-mode-linux: xterm functionality broken due to wrong path to port-helper

[Sjoerd Simons]

On Mon, 2020-01-06 at 16:58 +0000, Anton Ivanov wrote:
> 
> On 06/01/2020 16:21, Ritesh Raj Sarraf wrote:
> > Control: tag -1 +help
> > 
> > On Mon, 2020-01-06 at 10:38 +0100, Sjoerd Simons wrote:
> > > On my sid system:
> > > ```
> > > $ strings /usr/bin/linux.uml | grep port-helper
> > > /usr/lib//uml/port-helper
> > > ```
> > > 
> > > So the path is still incorrect even with newer upstream kernels.
> > 
> > I spent some time today looking at the new build but I haven't been
> > able to ascertain why this isn't setting the correct path.
> 
> It is used in a "user" side file - xterm.c
> 
> None of these sees "CONFIG_" so it considers it undef-ed which
> defaults 
> to 32 bit.

Is there any reason why the port helper is in the weird `/usr/lib64`
that seems more like a redhat-ism; On Debian if it's proper multi arch
under `/usr/lib/x86_64-linux-gnu/`..

However uml-utilities can't be installed for multiple architectures on
one system anyway (as it ships binaries). So there is little point in
try to being multi-arch-like (or just awkward :p)...

So to me the most practical and straight-forward solution would
probably be to revert the broken kernel patch and change the uml-
utilities package instead to always install in a single spot.

> You need to use some other way to figure out what is the build or to
> set 
> OS_LIB_PATH for this case.
> 
> > ```
> > $ strings `which  linux.uml` | grep port-helper
> > /usr/lib/uml/port-helper
> > ```
> > 
> > First, for context to the readers here, the port-helper binary is
> > shipped with uml-utilities package. This package, depending on the
> > architecture, installs the binary to a architecture specific
> > location.
> > 
> > https://sources.debian.org/src/uml-utilities/20070815.2-1/Makefile/#L10
> > 
> > Which on an amd64 machine is: /usr/lib64/uml/port-helper
> > 
> > ```
> > $ dpkg  -S /usr/lib64/uml/port-helper
> > uml-utilities: /usr/lib64/uml/port-helper
> > ```
> > 
> > The UML setup on my box always worked because long back, when I
> > first
> > encountered this problem, I had created a symlink of the path to
> > /usr/lib/ too. And had completely forgotten about it. My apologies.
> > 
> > 
> > But that said, the current problem is with the UML binary built by
> > the
> > kernel sources.
> > Problem is that, as mentioned above and other reports too on this
> > bug
> > report thread, the path resolved at build time is always
> > "/usr/lib/uml/".
> > 
> > The build configuration and the code are all correct.
> > 
> > ```
> > $ grep 64BIT .config
> > CONFIG_64BIT=y
> > CONFIG_64BIT_TIME=y
> > CONFIG_PHYS_ADDR_T_64BIT=y
> > CONFIG_ARCH_DMA_ADDR_T_64BIT=y
> > ```
> > 
> > 
> > Snipped from: arch/um/include/shared/os.h
> > 
> > ```
> > #ifdef CONFIG_64BIT
> > #define OS_LIB_PATH     "/usr/lib64/"
> > #else
> > #define OS_LIB_PATH     "/usr/lib/"
> > #endif
> > ```
> > 
> > I also checked the generated include headers and they are correct
> > for
> > the amd64 .config file.
> > 
> > ```
> > linux-source-5.4/include/generated$ grep 64BIT autoconf.h
> > #define CONFIG_64BIT_TIME 1
> > #define CONFIG_PHYS_ADDR_T_64BIT 1
> > #define CONFIG_64BIT 1
> > #define CONFIG_ARCH_DMA_ADDR_T_64BIT 1
> > ```
> > 
> > I'll keep looking as time permits but if anyone else has ideas on
> > what
> > I may be doing wrong, please do mention.
> > 
> > Thanks,
> > Ritesh
> > 
> > 
> > _______________________________________________
> > linux-um mailing list
> > linux-um@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-um
> > 

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um