Processed: Re: Transition to usrmerge has started

[Debian Bug Tracking System]

Processing control commands:

> severity -1 grave
Bug #926699 [debootstrap,usrmerge] libc6 foreign/biarch: installing, removing, 
reinstalling in a --merged-usr system results in unmerged /lib{32,x32}
Severity set to 'grave' from 'normal'

-- 
926699: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926699
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#926699: Transition to usrmerge has started

[Andreas Beckmann]

Control: severity -1 grave
# for producing a partially merged-/usr system

Hi Luca,

#926699 is still reproducible in a merged-/usr environment:

(in an amd64 pbuilder chroot)

# ls -lad /lib{,32,64,x32}
lrwxrwxrwx 1 root root  7 Sep 19 00:35 /lib -> usr/lib
lrwxrwxrwx 1 root root  9 Sep 19 00:35 /lib32 -> usr/lib32
lrwxrwxrwx 1 root root  9 Sep 19 00:35 /lib64 -> usr/lib64
lrwxrwxrwx 1 root root 10 Sep 19 00:35 /libx32 -> usr/libx32
# apt-get install libc6-i386
...
# ls -lad /lib{,32,64,x32}
lrwxrwxrwx 1 root root  7 Sep 19 00:35 /lib -> usr/lib
lrwxrwxrwx 1 root root  9 Sep 19 00:35 /lib32 -> usr/lib32
lrwxrwxrwx 1 root root  9 Sep 19 00:35 /lib64 -> usr/lib64
lrwxrwxrwx 1 root root 10 Sep 19 00:35 /libx32 -> usr/libx32
# apt-get remove libc6-i386
...
# ls -lad /lib{,32,64,x32}
ls: cannot access '/lib32': No such file or directory
lrwxrwxrwx 1 root root  7 Sep 19 00:35 /lib -> usr/lib
lrwxrwxrwx 1 root root  9 Sep 19 00:35 /lib64 -> usr/lib64
lrwxrwxrwx 1 root root 10 Sep 19 00:35 /libx32 -> usr/libx32
# apt-get install libc6-i386
...
# ls -lad /lib{,32,64,x32}
lrwxrwxrwx 1 root root   7 Sep 19 00:35 /lib -> usr/lib
drwxr-xr-x 2 root root 440 Sep 19 09:07 /lib32
lrwxrwxrwx 1 root root   9 Sep 19 00:35 /lib64 -> usr/lib64
lrwxrwxrwx 1 root root  10 Sep 19 00:35 /libx32 -> usr/libx32

OOPS!

you can probably do the same with libc6-x32 and libc6:amd64 on i386
(didn't mips* have /lib[no]{32,64}?)

Andreas

Bug#926699: Transition to usrmerge has started

[Andreas Beckmann]

Shouldn't that fail in such a broken environment?

# apt-get install --reinstall usr-is-merged
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 1 not upgraded.
Need to get 0 B/4732 B of archives.
After this operation, 0 B of additional disk space will be used.
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based frontend 
cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 78, <> line 
1.)
debconf: falling back to frontend: Readline
(Reading database ... 15056 files and directories currently installed.)
Preparing to unpack .../usr-is-merged_30+nmu1_all.deb ...
Unpacking usr-is-merged (30+nmu1) over (30+nmu1) ...
Setting up usr-is-merged (30+nmu1) ...
# ls -lad /lib{,32,64,x32}
lrwxrwxrwx 1 root root   7 Sep 19 00:35 /lib -> usr/lib
drwxr-xr-x 2 root root 440 Sep 19 08:59 /lib32
lrwxrwxrwx 1 root root   9 Sep 19 00:35 /lib64 -> usr/lib64
lrwxrwxrwx 1 root root  10 Sep 19 00:35 /libx32 -> usr/libx32

Andreas

Bug#926699: Transition to usrmerge has started

[Marco d'Itri]

On Sep 19, Andreas Beckmann  wrote:

> Shouldn't that fail in such a broken environment?
Definitely yes, I will have a look later today.

The main issue can only be fixed in the libc packages (which would be 
wonderful, because then we could stop creating the biarch links and 
directories on all systems).

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Processed: Re: Transition to usrmerge has started

[Debian Bug Tracking System]

Processing control commands:

> tags -1 moreinfo
Bug #926699 [debootstrap,usrmerge] libc6 foreign/biarch: installing, removing, 
reinstalling in a --merged-usr system results in unmerged /lib{32,x32}
Added tag(s) moreinfo.

-- 
926699: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926699
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#926699: Transition to usrmerge has started

[Luca Boccassi]

Control: tags -1 moreinfo

On Mon, 2022-09-19 at 11:29 +0200, Andreas Beckmann wrote:
> Shouldn't that fail in such a broken environment?
> 
> # apt-get install --reinstall usr-is-merged
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> 0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 1 not
> upgraded.
> Need to get 0 B/4732 B of archives.
> After this operation, 0 B of additional disk space will be used.
> debconf: unable to initialize frontend: Dialog
> debconf: (No usable dialog-like program is installed, so the dialog
> based frontend cannot be used. at
> /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 78, <> line 1.)
> debconf: falling back to frontend: Readline
> (Reading database ... 15056 files and directories currently
> installed.)
> Preparing to unpack .../usr-is-merged_30+nmu1_all.deb ...
> Unpacking usr-is-merged (30+nmu1) over (30+nmu1) ...
> Setting up usr-is-merged (30+nmu1) ...
> # ls -lad /lib{,32,64,x32}
> lrwxrwxrwx 1 root root   7 Sep 19 00:35 /lib -> usr/lib
> drwxr-xr-x 2 root root 440 Sep 19 08:59 /lib32
> lrwxrwxrwx 1 root root   9 Sep 19 00:35 /lib64 -> usr/lib64
> lrwxrwxrwx 1 root root  10 Sep 19 00:35 /libx32 -> usr/libx32

It should, but I cannot reproduce this? Can you share the exact steps
you used to create the chroot?

# ls -lad /lib{,32,64,x32}
lrwxrwxrwx 1 root root7 Sep 19 10:20 /lib -> usr/lib
drwxr-xr-x 2 root root 4096 Sep 19 10:20 /lib32
lrwxrwxrwx 1 root root9 Sep 19 10:20 /lib64 -> usr/lib64
lrwxrwxrwx 1 root root   10 Sep 19 10:20 /libx32 -> usr/libx32
# sh -x usrmerge/debian/usr-is-merged.preinst install
+ fail_if_unmerged
+ is_merged
+ directories=/bin /sbin /lib
+ [ -e /bin ]
+ readlink -f /bin
+ [ /usr/bin = /usr/bin ]
+ [ -e /sbin ]
+ readlink -f /sbin
+ [ /usr/sbin = /usr/sbin ]
+ [ -e /lib ]
+ readlink -f /lib
+ [ /usr/lib = /usr/lib ]
+ arch_directories=/lib64 /lib32 /libo32 /libx32
+ [ -e /lib64 ]
+ readlink -f /lib64
+ [ -e /lib32 ]
+ readlink -f /lib32
+ return 1
+ [ -e /etc/unsupported-skip-usrmerge-conversion ]
+ cat


**
*
* The usr-is-merged package cannot be installed because this system does
* not have a merged /usr.
*
* Please install the usrmerge package to convert this system to merged-/usr.
*
* For more information please read https://wiki.debian.org/UsrMerge.
*
**


+ exit 1

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Processed: Re: Transition to usrmerge has started

[Debian Bug Tracking System]

Processing control commands:

> tags -1 -moreinfo
Bug #926699 [debootstrap,usrmerge] libc6 foreign/biarch: installing, removing, 
reinstalling in a --merged-usr system results in unmerged /lib{32,x32}
Removed tag(s) moreinfo.

-- 
926699: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926699
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#926699: Transition to usrmerge has started

[Luca Boccassi]

Control: tags -1 -moreinfo

On Mon, 2022-09-19 at 11:23 +0100, Luca Boccassi wrote:
> Control: tags -1 moreinfo
> 
> On Mon, 2022-09-19 at 11:29 +0200, Andreas Beckmann wrote:
> > Shouldn't that fail in such a broken environment?
> > 
> > # apt-get install --reinstall usr-is-merged
> > Reading package lists... Done
> > Building dependency tree... Done
> > Reading state information... Done
> > 0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 1 not
> > upgraded.
> > Need to get 0 B/4732 B of archives.
> > After this operation, 0 B of additional disk space will be used.
> > debconf: unable to initialize frontend: Dialog
> > debconf: (No usable dialog-like program is installed, so the dialog
> > based frontend cannot be used. at
> > /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 78, <> line 1.)
> > debconf: falling back to frontend: Readline
> > (Reading database ... 15056 files and directories currently
> > installed.)
> > Preparing to unpack .../usr-is-merged_30+nmu1_all.deb ...
> > Unpacking usr-is-merged (30+nmu1) over (30+nmu1) ...
> > Setting up usr-is-merged (30+nmu1) ...
> > # ls -lad /lib{,32,64,x32}
> > lrwxrwxrwx 1 root root   7 Sep 19 00:35 /lib -> usr/lib
> > drwxr-xr-x 2 root root 440 Sep 19 08:59 /lib32
> > lrwxrwxrwx 1 root root   9 Sep 19 00:35 /lib64 -> usr/lib64
> > lrwxrwxrwx 1 root root  10 Sep 19 00:35 /libx32 -> usr/libx32
> 
> It should, but I cannot reproduce this? Can you share the exact steps
> you used to create the chroot?
> 
> # ls -lad /lib{,32,64,x32}
> lrwxrwxrwx 1 root root    7 Sep 19 10:20 /lib -> usr/lib
> drwxr-xr-x 2 root root 4096 Sep 19 10:20 /lib32
> lrwxrwxrwx 1 root root    9 Sep 19 10:20 /lib64 -> usr/lib64
> lrwxrwxrwx 1 root root   10 Sep 19 10:20 /libx32 -> usr/libx32
> # sh -x usrmerge/debian/usr-is-merged.preinst install
> + fail_if_unmerged
> + is_merged
> + directories=/bin /sbin /lib
> + [ -e /bin ]
> + readlink -f /bin
> + [ /usr/bin = /usr/bin ]
> + [ -e /sbin ]
> + readlink -f /sbin
> + [ /usr/sbin = /usr/sbin ]
> + [ -e /lib ]
> + readlink -f /lib
> + [ /usr/lib = /usr/lib ]
> + arch_directories=/lib64 /lib32 /libo32 /libx32
> + [ -e /lib64 ]
> + readlink -f /lib64
> + [ -e /lib32 ]
> + readlink -f /lib32
> + return 1
> + [ -e /etc/unsupported-skip-usrmerge-conversion ]
> + cat
> 
> 
> *
> *
> *
> * The usr-is-merged package cannot be installed because this system
> does
> * not have a merged /usr.
> *
> * Please install the usrmerge package to convert this system to
> merged-/usr.
> *
> * For more information please read https://wiki.debian.org/UsrMerge.
> *
> *
> *
> 
> 
> + exit 1

Never mind, the issue is that on 'apt install --reinstall' it's an
upgrade flow, not an install flow, and in the preinst we run the check
only for install. I think we should run it for upgrade too, so I'll
open an MR to do that.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#926699: Transition to usrmerge has started

[Andreas Beckmann]

On 19/09/2022 12.07, Marco d'Itri wrote:

The main issue can only be fixed in the libc packages (which would be
wonderful, because then we could stop creating the biarch links and
directories on all systems).


on amd64:

# apt-file search -x '^/lib32' | cut -d: -f1 | sort -u
lib32ncurses6
lib32ncursesw6
lib32readline8
lib32tinfo6
libc6-i386

# apt-file search -x '^/libx32' | cut -d: -f1 | sort -u
libc6-x32

# apt-file search -x '^/lib64' | cut -d: -f1 | sort -u
libc6

# apt-cache show lib32ncurses6 lib32ncursesw6 lib32readline8 lib32tinfo6 
| grep -E 'Package|Depends'

Package: lib32ncurses6
Depends: lib32tinfo6 (= 6.3+20220423-2), libc6-i386 (>= 2.7)
Package: lib32ncursesw6
Depends: lib32tinfo6 (= 6.3+20220423-2), libc6-i386 (>= 2.7)
Package: lib32readline8
Depends: readline-common, lib32tinfo6 (>= 6), libc6-i386 (>= 2.33)
Package: lib32tinfo6
Depends: libc6-i386 (>= 2.33)

Just brainstorming:
If we declare libc6-i386 as the "owner" of /lib32, lib32* as "users" of 
/lib32 and add libc6-i386.preinst that
* handles the creation of /lib32 if missing, either as directory or 
symlink, depending of the state of /lib

* errors out (or converts) if /lib32 is a directory but /lib is a symlink
and then have all "users" of /lib32 Pre-Depends: libc6-i386 (>= xxx)
(might need a debhelper patch to populate ${misc:Pre-Depends})
and lintian check for such a pre-depends ...
(I'm not sure if a plain Depends is sufficient to ensure 
libc6-i386.preinst gets run in all cases before some lib32* gets 
unpacked ...)

Same for /libx32, except that there are no users that might need updating.

How likely is it that a user of /lib32 gets unpacked during the early 
bootstrapping phase? If that is not going to happen, the symlink 
creation for /libxx could be deferred to the installation of 
libc6-{i386,x32} and no "unowned" /libxx symlinks would be lingering 
around after boostrapping.


On i386 we have

# apt-file search -x ^/lib64 | cut -d: -f1 | sort -u
lib64gcc-s1
lib64ncurses6
lib64ncursesw6
lib64readline8
lib64tinfo6
libc6-amd64

# apt-file search -x ^/libx32 | cut -d: -f1 | sort -u
libc6-x32

(and no /lib32)

Didn't check other architectures.

Interesting could also be the installation of libc6:amd64 on a i386 
system as that will create /lib64 ... yes, that will leave you with a 
/lib64 directory if no symlink pre-exists.



Andreas

Processed: Bug#1019881 marked as pending in flash-kernel

[Debian Bug Tracking System]

Processing control commands:

> tag -1 pending
Bug #1019881 [src:flash-kernel] flash-kernel: please add 
A20-OLinuXino_MICRO-eMMC configuration
Added tag(s) pending.

-- 
1019881: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019881
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Re: Bug#926699: Transition to usrmerge has started

[Debian Bug Tracking System]

Processing control commands:

> tags -1 patch
Bug #926699 [debootstrap,usrmerge] libc6 foreign/biarch: installing, removing, 
reinstalling in a --merged-usr system results in unmerged /lib{32,x32}
Added tag(s) patch.

-- 
926699: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926699
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#926699: Transition to usrmerge has started

[Luca Boccassi]

Control: tags -1 patch

On Mon, 2022-09-19 at 13:35 +0200, Andreas Beckmann wrote:
> On 19/09/2022 12.07, Marco d'Itri wrote:
> > The main issue can only be fixed in the libc packages (which would
> > be
> > wonderful, because then we could stop creating the biarch links and
> > directories on all systems).
> 
> on amd64:
> 
> # apt-file search -x '^/lib32' | cut -d: -f1 | sort -u
> lib32ncurses6
> lib32ncursesw6
> lib32readline8
> lib32tinfo6
> libc6-i386
> 
> # apt-file search -x '^/libx32' | cut -d: -f1 | sort -u
> libc6-x32
> 
> # apt-file search -x '^/lib64' | cut -d: -f1 | sort -u
> libc6
> 
> # apt-cache show lib32ncurses6 lib32ncursesw6 lib32readline8
> lib32tinfo6 
> > grep -E 'Package|Depends'
> Package: lib32ncurses6
> Depends: lib32tinfo6 (= 6.3+20220423-2), libc6-i386 (>= 2.7)
> Package: lib32ncursesw6
> Depends: lib32tinfo6 (= 6.3+20220423-2), libc6-i386 (>= 2.7)
> Package: lib32readline8
> Depends: readline-common, lib32tinfo6 (>= 6), libc6-i386 (>= 2.33)
> Package: lib32tinfo6
> Depends: libc6-i386 (>= 2.33)
> 
> Just brainstorming:
> If we declare libc6-i386 as the "owner" of /lib32, lib32* as "users"
> of 
> /lib32 and add libc6-i386.preinst that
> * handles the creation of /lib32 if missing, either as directory or 
> symlink, depending of the state of /lib
> * errors out (or converts) if /lib32 is a directory but /lib is a
> symlink
> and then have all "users" of /lib32 Pre-Depends: libc6-i386 (>= xxx)
> (might need a debhelper patch to populate ${misc:Pre-Depends})
> and lintian check for such a pre-depends ...
> (I'm not sure if a plain Depends is sufficient to ensure 
> libc6-i386.preinst gets run in all cases before some lib32* gets 
> unpacked ...)
> Same for /libx32, except that there are no users that might need
> updating.
> 
> How likely is it that a user of /lib32 gets unpacked during the early
> bootstrapping phase? If that is not going to happen, the symlink 
> creation for /libxx could be deferred to the installation of 
> libc6-{i386,x32} and no "unowned" /libxx symlinks would be lingering 
> around after boostrapping.
> 
> On i386 we have
> 
> # apt-file search -x ^/lib64 | cut -d: -f1 | sort -u
> lib64gcc-s1
> lib64ncurses6
> lib64ncursesw6
> lib64readline8
> lib64tinfo6
> libc6-amd64
> 
> # apt-file search -x ^/libx32 | cut -d: -f1 | sort -u
> libc6-x32
> 
> (and no /lib32)
> 
> Didn't check other architectures.
> 
> Interesting could also be the installation of libc6:amd64 on a i386 
> system as that will create /lib64 ... yes, that will leave you with a
> /lib64 directory if no symlink pre-exists.

This MR implements the suggestion from Marco from earlier in this
thread [0]:

https://salsa.debian.org/glibc-team/glibc/-/merge_requests/11

Tested with libc6-i386, seems to do the expected thing. We can remove
it then after everything has moved to install only to /usr, hopefully
in Trixie.

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926699#77

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Processed: Re: Bug#1019660: console-setup: grep: warning: stray \ before #

[Debian Bug Tracking System]

Processing control commands:

> tags -1 patch
Bug #1019660 [console-setup] console-setup: grep: warning: stray \ before #
Added tag(s) patch.

-- 
1019660: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019660
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1019660: console-setup: grep: warning: stray \ before #

[Vincent Lefevre]

Control: tags -1 patch

On 2022-09-13 12:42:11 +0200, Jakub Wilk wrote:
> With grep (>= 3.8), I'm getting this warning:
> 
>   # setupcon
>   grep: warning: stray \ before #

I've attached a patch to fix this issue and other grep usage issues.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Description: Fix setupcon grep usage (for grep 3.8+).
Bug-Debian: https://bugs.debian.org/1019660
Author: Vincent Lefevre 
Last-Update: 2022-09-20

--- setupcon~	2022-05-26 22:47:37.0 +0200
+++ setupcon	2022-09-20 02:48:26.914726411 +0200
@@ -489,7 +489,7 @@
 for tty in \
 $(cat /etc/inittab /etc/init/* /etc/ttys 2>/dev/null \
 	| grep getty \
-| egrep '([[:blank:]]|^)tty([1-9][0-9]*|v[0-9a-f])([[:blank:]]|$)' \
+| grep -E '([[:blank:]]|^)tty([1-9][0-9]*|v[0-9a-f])([[:blank:]]|$)' \
 | sed -e '/^ *#/d' \
   -e 's/.*[[:blank:]]\(tty[1-9][0-9]*\).*/\1/' \
   -e 's/.*[[:blank:]]\(ttyv[0-9a-f]\).*/\1/')
@@ -775,7 +775,7 @@
 esac
 case \
 "`(stty -a \
-  | egrep '(^| )erase *=' \
+  | grep -E '(^| )erase *=' \
   | sed -e 's/.* erase *= *//' -e 's/^erase *= *//' -e 's/[; ].*//') \
   2>/dev/null`"
 in
@@ -1094,8 +1094,8 @@
 # Copyright © 2001 Alcove http://www.alcove.fr/
 if [ "$do_kbd" = linux ]; then
 if [ -x /sbin/sysctl -a -r /etc/sysctl.conf ]; then
-	if grep -v '^\#' /etc/sysctl.conf | grep -q keycodes ; then
-	grep keycodes /etc/sysctl.conf | grep -v "^#" \
+	if grep -v '^#' /etc/sysctl.conf | grep -q keycodes ; then
+	grep keycodes /etc/sysctl.conf | grep -v '^#' \
 		| while read -r d ; do
 /sbin/sysctl -w $d 2> /dev/null || true
 done