Re: Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

2019-02-22 Thread Didier 'OdyX' Raboud
Le lundi, 18 février 2019, 08.58:53 h CET Didier 'OdyX' Raboud a écrit :
> Dear Technical Committee members,
> (CC'ed to submitter, and debootstrap maintainers for information and
> feedack)
> 
> Here's the current state of the draft resolution; which `master` is at
> https://salsa.debian.org/debian/tech-ctte/blob/master/914897_merged_usr/ball
> ot.md
> 
> I will submit it to vote on Friday 22.; the discussion period is open!

Thank you for the various comments. I have amended the ballot (which is more a
"explanation text + short ballot" incorporating the suggestions from the IRC
meeting as well as taking into accounts remarks on this bug.

I intend to answer some mails on that bug, and call for a vote on Sunday I
guess.

See: 
https://salsa.debian.org/debian/tech-ctte/blob/master/914897_merged_usr/ballot.md
for the markdown-rendered version; and below:

# #914897: tech-ctte: Should debootstrap disable merged `/usr` by default?

## What is "merged `/usr`"

"Merged `/usr`" describes a possible future standard directories scheme in
which the `/{bin,sbin,lib*}/` directories have been made superfluous through
replacing them by symlinks to their `/usr` equivalents
(`/usr/{bin,sbin,lib*}`).
The motivation to get Debian systems to converge towards such a scheme is
vastly documented elsewhere ([FDO's TheCaseForTheUsrMerge][0],
[wiki.d.o UsrMerge][1]) but can be summarized as the following points:

* having separate `/` and `/usr` filesystems has been useful in the past for
booting without initramfs onto a minimal root filesystem that carried just
enough to mount the `/usr` filesystem later in the boot process. Given the
evolution of physical hosts' capabilities, initramfs'es have been default in
Debian (and elsewhere) for a long time, and most systems no longer have an
intermediate state during boot in which they have only `/`, but not `/usr`,
mounted. Booting hosts through that intermediate state is not systematically
tested in Debian anymore.
* another use-case is to share system files from `/usr` between hosts (over a
network link) or containers (locally) which use different data or
configuration. Having all software under `/usr` (instead of spread between `/`
and `/usr`) makes the centralized update and the sharing easier.
* the packaging infrastructure to install files outside of `/usr` (e.g.
installing libs under `/lib` instead of `/usr/lib`) is not standard and
represents technical debt.
* given its status as remnant "folklore", the distinction between what _needs_
to be shipped in `/` and what can stay in `/usr` is often interpreted
arbitrarily;
* allowing shipment of identically-named libraries or binaries in different
paths can confuse common understanding of paths precedence.

[0]: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
[1]: https://wiki.debian.org/UsrMerge

The arguments against moving the base directories' scheme towards
"merged `/usr`" are as follows:

* there's no gain in disrupting something that is not inherently broken;
* `/{bin,sbin,lib*}/` → `/usr/{bin,sbin,lib*}/` symlinks create confusing
views of the system (`/bin/cat` and `/usr/bin/cat` are the same file), and
dpkg doesn't support this situation cleanly:
[#134758](https://bugs.debian.org/134758).
* it is possible for distributions to converge towards having all system files
in `/usr` in finite time instead of shortcutting this migration with
`/{bin,sbin,lib*}/` → `/usr/{bin,sbin,lib*}/` symlinks.

The compatibility symbolic links `/lib` → `/usr/lib` and `/lib64` →
`/usr/lib64` are required by the various CPUs' platform ABIs (for example i386
requires `/lib/ld-linux.so.2` to resolve to glibc's `ld.so`, and amd64
requires `/lib64/ld-linux-x86-64.so.2`) so there are no plans to remove them
altogether. Similarly, removing `/bin` is not under consideration because it
would break the assumption that `/bin/sh` exists, and removing `/sbin` would
break the assumption that `/sbin/fsck.*` and `/sbin/mount.*` exist.

## "merged `/usr`" in Debian

In Debian buster, the current testing suite, "merged `/usr`" is only
considered for implementation with symlinks (there are no proposals for simply
dropping `/{bin,sbin,lib*}`) and is implemented in two main ways:

* existing hosts can be made to have a "merged `/usr`" by installing the
[usrmerge][2] package;
* new hosts get the `/{bin,sbin,lib*}/`→ `/usr/{bin,sbin,lib*}/` symlinks by
default when using debootstrap >= 1.0.102.

The usrmerge package contains a `/usr/lib/convert-usrmerge` perl executable
that runs in `postinst`, that will move the contents of `/{bin,sbin,lib*}/`
and replace these directories with symlinks when empty.

It is also possible to merge `/usr` in other ways, for example with
`debootstrap --merged-usr` or by bootstrapping into a chroot that already
contains the necessary symlinks.

[2]: https://tracker.debian.org/pkg/usrmerge

## Issues from "merged `/usr`"

Since the default change in debootstrap 1.0.102, some issues have arisen.
Due to the fact that s

Re: Scheduling 9.9

2019-02-22 Thread Donald Norwood
On 2/20/19 8:05 PM, Cyril Brulebois wrote:
> Steve McIntyre  (2019-02-20):
>> On Wed, Feb 20, 2019 at 06:28:05PM +, Jonathan Wiltshire wrote:
>>> Hi,
>>>
>>> Please indicate your availablility out of:
>>>
>>> - April 13
>>> - April 20 (Easter weekend)
>>
>> I'm away on holiday for both of these, I'm afraid, and so is chief CD
>> tester Andy.
>>
>>> - April 27
>>
>> But this works.
> 
> All dates should be OK for d-i preparations on my side.

Publicity can do the 27th.

-- 
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Donald Norwood
⢿⡄⠘⠷⠚⠋⠀ B7A1 5F45 5B28 7F38 4174
⠈⠳⣄ D5E9 E5EC 4AC9 BD62 7B05



signature.asc
Description: OpenPGP digital signature


Bug#922991: Debian 10 Alpha 5 successfully installed at AMD-A10 Desktop

2019-02-22 Thread Bernhard
Package: installation-reports

Boot method: USB-Drive
Image version: Self-made installation image with Debian 10 Alpha 5
Date: 2019-02-22

Machine: Self-made desktop PC with AMD-A10
Processor: AMD A10-5700 APU with Radeon(tm) HD Graphics
Memory: 4GB
Partitions: 

> DateisystemTyp  1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
> udev   devtmpfs   1589220   0   15892200% /dev
> tmpfs  tmpfs   32106448723161922% /run
> /dev/sda1  ext4 111556948 6251784  995953406% /
> tmpfs  tmpfs  1605300   27912   15773882% /dev/shm
> tmpfs  tmpfs 5120   4  51161% /run/lock
> tmpfs  tmpfs  1605300   0   16053000% /sys/fs/cgroup
> tmpfs  tmpfs   321060  643209961% /run/user/1000

Output of lspci -knn:

> 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h 
> (Models 10h-1fh) Processor Root Complex [1022:1410]
>   Subsystem: ASUSTeK Computer Inc. Family 15h (Models 10h-1fh) Processor 
> Root Complex [1043:8526]
> 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
> [AMD/ATI] Trinity [Radeon HD 7660D] [1002:9901]
>   Subsystem: ASUSTeK Computer Inc. Trinity [Radeon HD 7660D] [1043:8526]
>   Kernel driver in use: radeon
>   Kernel modules: radeon
> 00:01.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Trinity 
> HDMI Audio Controller [1002:9902]
>   Subsystem: ASUSTeK Computer Inc. Trinity HDMI Audio Controller 
> [1043:8526]
>   Kernel driver in use: snd_hda_intel
>   Kernel modules: snd_hda_intel
> 00:10.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB 
> XHCI Controller [1022:7812] (rev 03)
>   Subsystem: ASUSTeK Computer Inc. FCH USB XHCI Controller [1043:8527]
>   Kernel driver in use: xhci_hcd
>   Kernel modules: xhci_pci
> 00:10.1 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB 
> XHCI Controller [1022:7812] (rev 03)
>   Subsystem: ASUSTeK Computer Inc. FCH USB XHCI Controller [1043:8527]
>   Kernel driver in use: xhci_hcd
>   Kernel modules: xhci_pci
> 00:11.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] FCH SATA 
> Controller [AHCI mode] [1022:7801] (rev 40)
>   Subsystem: ASUSTeK Computer Inc. FCH SATA Controller [AHCI mode] 
> [1043:8527]
>   Kernel driver in use: ahci
>   Kernel modules: ahci
> 00:12.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB 
> OHCI Controller [1022:7807] (rev 11)
>   Subsystem: ASUSTeK Computer Inc. FCH USB OHCI Controller [1043:8527]
>   Kernel driver in use: ohci-pci
>   Kernel modules: ohci_pci
> 00:12.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB 
> EHCI Controller [1022:7808] (rev 11)
>   Subsystem: ASUSTeK Computer Inc. FCH USB EHCI Controller [1043:8527]
>   Kernel driver in use: ehci-pci
>   Kernel modules: ehci_pci
> 00:13.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB 
> OHCI Controller [1022:7807] (rev 11)
>   Subsystem: ASUSTeK Computer Inc. FCH USB OHCI Controller [1043:8527]
>   Kernel driver in use: ohci-pci
>   Kernel modules: ohci_pci
> 00:13.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB 
> EHCI Controller [1022:7808] (rev 11)
>   Subsystem: ASUSTeK Computer Inc. FCH USB EHCI Controller [1043:8527]
>   Kernel driver in use: ehci-pci
>   Kernel modules: ehci_pci
> 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller 
> [1022:780b] (rev 14)
>   Subsystem: ASUSTeK Computer Inc. FCH SMBus Controller [1043:8527]
>   Kernel driver in use: piix4_smbus
>   Kernel modules: i2c_piix4, sp5100_tco
> 00:14.2 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] FCH Azalia 
> Controller [1022:780d] (rev 01)
>   Subsystem: ASUSTeK Computer Inc. F2A85-M Series [1043:8444]
>   Kernel driver in use: snd_hda_intel
>   Kernel modules: snd_hda_intel
> 00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge 
> [1022:780e] (rev 11)
>   Subsystem: ASUSTeK Computer Inc. FCH LPC Bridge [1043:8527]
> 00:14.4 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] FCH PCI Bridge 
> [1022:780f] (rev 40)
> 00:15.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Hudson PCI to 
> PCI bridge (PCIE port 0) [1022:43a0]
>   Kernel driver in use: pcieport
> 00:15.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Hudson PCI to 
> PCI bridge (PCIE port 1) [1022:43a1]
>   Kernel driver in use: pcieport
> 00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h 
> (Models 10h-1fh) Processor Function 0 [1022:1400]
> 00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h 
> (Models 10h-1fh) Processor Function 1 [1022:1401]
> 00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h 
> (Models 10h-1fh) Processor Function 2 [1022

Re: [rb-general] debian-installer: Ensure build is reproducible regardless of the user's umask(2)

2019-02-22 Thread Cyril Brulebois
Hi,

Vagrant Cascadian  (2019-02-21):
> On 2019-02-21, Chris Lamb wrote:
> > Chris Lamb wrote:
> >> > #920631 debian-installer: Ensure build is reproducible regardless
> >> > of the user's umask(2)
> >> [..]
> >> > #920676: debian-installer: Ensure build is reproducible
> >> > regardless of the underlying filesystem ordering
> >> 
> >> Thank you for developing and maintainer the Debian Installer. I
> >> was wondering what might be needed on my end to ensure that these
> >> patches end up in the next alpha/beta release?
> >
> > Sorry to bug you again folks but I haven't done any d-i development
> > for almost 10 years now so I may not be aware of the most
> > productive, helpful and — above everything else! — friendly way of
> > getting things merged, particularly in time for buster. Can you
> > help? :-)
> 
> I went ahead and merged them into git.

This seems to have broken all daily builds.

Example on amdahl for arm64, even if that doesn't appear to be
arch-specific at all.

[ last lines of /home/d-i/di/logs/di-autobuild_daily-arm64-20190222-0200 ]

# Ensure build results have reproducible mtimes
chmod: changing permissions of './tmp/netboot/tree/sbin/modprobe': 
Operation not permitted
chmod: cannot operate on dangling symlink './tmp/netboot/tree/sbin/vconfig'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/sbin/syslogd'
chmod: changing permissions of './tmp/netboot/tree/sbin/modinfo': Operation 
not permitted
chmod: cannot operate on dangling symlink './tmp/netboot/tree/sbin/mkswap'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/sbin/swapon'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/sbin/blockdev'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/sbin/fstrim'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/sbin/swapoff'
chmod: changing permissions of './tmp/netboot/tree/sbin/insmod': Operation 
not permitted
chmod: cannot operate on dangling symlink './tmp/netboot/tree/sbin/udhcpc'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/sbin/poweroff'
chmod: changing permissions of './tmp/netboot/tree/sbin/rmmod': Operation 
not permitted
chmod: cannot operate on dangling symlink 
'./tmp/netboot/tree/sbin/freeramdisk'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/sbin/klogd'
chmod: cannot operate on dangling symlink 
'./tmp/netboot/tree/sbin/switch_root'
chmod: changing permissions of './tmp/netboot/tree/sbin/depmod': Operation 
not permitted
chmod: cannot operate on dangling symlink './tmp/netboot/tree/sbin/reboot'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/sbin/ip'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/sbin/route'
chmod: changing permissions of './tmp/netboot/tree/sbin/lsmod': Operation 
not permitted
chmod: cannot operate on dangling symlink './tmp/netboot/tree/sbin/halt'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/sbin/hwclock'
chmod: cannot operate on dangling symlink 
'./tmp/netboot/tree/sbin/pivot_root'
chmod: changing permissions of './tmp/netboot/tree/usr/lib/ssl/certs': 
Operation not permitted
chmod: cannot operate on dangling symlink 
'./tmp/netboot/tree/usr/sbin/chroot'
chmod: cannot operate on dangling symlink 
'./tmp/netboot/tree/usr/sbin/arping'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/usr/bin/['
chmod: cannot operate on dangling symlink './tmp/netboot/tree/usr/bin/test'
chmod: cannot operate on dangling symlink 
'./tmp/netboot/tree/usr/bin/printf'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/usr/bin/wc'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/usr/bin/bzcat'
chmod: cannot operate on dangling symlink 
'./tmp/netboot/tree/usr/bin/dirname'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/usr/bin/sort'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/usr/bin/[['
chmod: cannot operate on dangling symlink './tmp/netboot/tree/usr/bin/nc'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/usr/bin/env'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/usr/bin/tftp'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/usr/bin/tail'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/usr/bin/xzcat'
c

Re: [rb-general] debian-installer: Ensure build is reproducible regardless of the user's umask(2)

2019-02-22 Thread Samuel Thibault
Hello,

Cyril Brulebois, le ven. 22 févr. 2019 20:31:52 +0100, a ecrit:
> This seems to have broken all daily builds.

Yes, noticed that this morning, pushed a fix.

Samuel



Re: [rb-general] debian-installer: Ensure build is reproducible regardless of the user's umask(2)

2019-02-22 Thread Cyril Brulebois
Cyril Brulebois  (2019-02-22):
> Vagrant Cascadian  (2019-02-21):
> > I went ahead and merged them into git.
> 
> This seems to have broken all daily builds.

FWIW daily builds are run from a buildscript that basically does:
  cd build && ./daily-build

but the failures were also obtained by running dpkg-buildpackage.

Please make sure you can build d-i with the patches you're merging?


Anyway, this seems to have been fixed this morning by Samuel (please let
us know when such things happen, so that we know and can also trigger
daily builds again):
  
https://salsa.debian.org/installer-team/debian-installer/commit/d0868ed0bfd3d31a7fc5c3eaf6509d58e74cc2b1


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Re: [rb-general] debian-installer: Ensure build is reproducible regardless of the user's umask(2)

2019-02-22 Thread Vagrant Cascadian
On 2019-02-22, Cyril Brulebois wrote:
> Cyril Brulebois  (2019-02-22):
>> Vagrant Cascadian  (2019-02-21):
>> > I went ahead and merged them into git.
>> 
>> This seems to have broken all daily builds.

Ouch, very sorry...


> FWIW daily builds are run from a buildscript that basically does:
>   cd build && ./daily-build
>
> but the failures were also obtained by running dpkg-buildpackage.
>
> Please make sure you can build d-i with the patches you're merging?

They seemed innocuous, but obvisouly this is another important lesson to
always test.


> Anyway, this seems to have been fixed this morning by Samuel (please let
> us know when such things happen, so that we know and can also trigger
> daily builds again):
>   
> https://salsa.debian.org/installer-team/debian-installer/commit/d0868ed0bfd3d31a7fc5c3eaf6509d58e74cc2b1

Thanks for cleaning up the mess, Samuel!


live well,
  vagrant


signature.asc
Description: PGP signature


Re: Multiple console support in d-i

2019-02-22 Thread Wookey
OK. Steve stayed up very late last night checking that this worked OK
on x86 and adding some useful logging (allowing for the fact that it
needs to work before syslog is actually started).

We've checked some more stuff today, including testing the matching
finish-install functionality on full installs, and reverting my fancy
inittab seddery to go back to simply appending which is more reliable
and easier to understand. We are now confident that the 'use init'
version is the superior (cleaner and more reliable) approach. 

That's all merged in the attached patches which we reckon are now
ready for general use.

I will do some more testing (to check I've not broken hurd - bsd
doesn't seem to be built at the moment so there is nothing to break),
and of course we are ready to prod it some more if we find this does
actually cause unhelpful behaviour for anyone. I also need to check
the docs which no doubt need a few updates.

I've found a couple of other things whilst poking about in the D-I
entrails. There is plenty of cruft from older ways of doing things,
which of course tends to get ignored if it's not actually breaking
things, largely due to chronic undermanning in D-I land. I'll file
some bugs and patches. None of it is urgent, but worth noting before I
forget.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/
diff --git b/debian/changelog a/debian/changelog
index a7c80c3..e23b91e 100644
--- b/debian/changelog
+++ a/debian/changelog
@@ -7,7 +7,11 @@ rootskel (1.127) UNRELEASED; urgency=medium
   [ Holger Wansing ]
   * Remove trailing whitespaces from changelog file, to fix lintian tag.
 
- -- Samuel Thibault   Fri, 08 Feb 2019 01:50:37 +0200
+  [ Wookey ]
+  * Support multiple consoles - Run D-I on all enabled consoles
+  * Rename reopen-console to choose-consoles
+
+ -- Wookey   Fri, 22 Feb 2019 15:57:39 +
 
 rootskel (1.126) unstable; urgency=medium
 
diff --git b/src/etc/inittab-hurd a/src/etc/inittab-hurd
index a7b8a23..eeff7e2 100644
--- b/src/etc/inittab-hurd
+++ a/src/etc/inittab-hurd
@@ -2,10 +2,9 @@
 # busybox init configuration for debian-installer
 
 # main rc script
-::sysinit:/sbin/reopen-console /sbin/debian-installer-startup
+::sysinit:/sbin/choose-consoles /sbin/debian-installer-startup
 
 # main setup program
-::respawn:/sbin/reopen-console /sbin/debian-installer
 
 # convenience shells
 tty2::askfirst:-/bin/sh
diff --git b/src/etc/inittab-kfreebsd a/src/etc/inittab-kfreebsd
index 748f19b..c328548 100644
--- b/src/etc/inittab-kfreebsd
+++ a/src/etc/inittab-kfreebsd
@@ -2,10 +2,9 @@
 # busybox init configuration for debian-installer
 
 # main rc script
-::sysinit:/sbin/reopen-console /sbin/debian-installer-startup
+::sysinit:/sbin/choose-consoles /sbin/debian-installer-startup
 
 # main setup program
-::respawn:/sbin/reopen-console /sbin/debian-installer
 
 # convenience shells
 ttyv1::askfirst:-/bin/sh
diff --git b/src/etc/inittab-linux a/src/etc/inittab-linux
index a7b8a23..d7136e2 100644
--- b/src/etc/inittab-linux
+++ a/src/etc/inittab-linux
@@ -2,10 +2,7 @@
 # busybox init configuration for debian-installer
 
 # main rc script
-::sysinit:/sbin/reopen-console /sbin/debian-installer-startup
-
-# main setup program
-::respawn:/sbin/reopen-console /sbin/debian-installer
+::sysinit:/sbin/choose-consoles /sbin/debian-installer-startup
 
 # convenience shells
 tty2::askfirst:-/bin/sh
@@ -19,3 +16,6 @@ tty4::respawn:/usr/bin/tail -f /var/log/syslog
 
 # re-exec init on receipt of SIGHUP/SIGUSR1
 ::restart:/sbin/init
+
+# main setup program
+# Entries will be added here as the system starts up
diff --git b/src/sbin/Makefile a/src/sbin/Makefile
index dec554e..f1a4f5f 100644
--- b/src/sbin/Makefile
+++ a/src/sbin/Makefile
@@ -8,7 +8,7 @@ files_exec = \
 	debian-installer-startup \
 	shutdown \
 	init:init-$(DEB_HOST_ARCH_OS) \
-	reopen-console:reopen-console-$(DEB_HOST_ARCH_OS) \
+	choose-consoles:choose-consoles-$(DEB_HOST_ARCH_OS) \
 	steal-ctty
 
 ifeq ($(DEB_HOST_ARCH_OS),linux)
diff --git b/src/sbin/reopen-console-hurd a/src/sbin/choose-consoles-hurd
similarity index 61%
rename from src/sbin/reopen-console-hurd
rename to src/sbin/choose-consoles-hurd
index 7f9b54e..bef2b73 100755
--- b/src/sbin/reopen-console-hurd
+++ a/src/sbin/choose-consoles-hurd
@@ -4,9 +4,9 @@
 # corresponding to the console we are actually using.
 
 console=
-if ! [ -f /var/run/console-device ]; then
-	tty > /var/run/console-device
+if ! [ -f /var/run/console-devices ]; then
+	tty > /var/run/console-devices
 fi
 
 # Some other session may have it as ctty. Steal it from them
-exec /sbin/steal-ctty $(cat /var/run/console-device) "$@"
+exec /sbin/steal-ctty $(cat /var/run/console-devices) "$@"
diff --git b/src/sbin/reopen-console-kfreebsd a/src/sbin/choose-consoles-kfreebsd
similarity index 87%
rename from src/sbin/reopen-console-kfreebsd
rename to src/sbin/choose-consoles-kfreebsd
index 6dec149..2dd292a 100755
--- b/src/sbin/reopen-console-kfreebsd
+++ a/src/sbin/choose-consoles-kfree

Bug#923021: Kernel oops using Buster Alpha 5 armhf installer onto ClearFog Base

2019-02-22 Thread Joel Johnson

Package: installation-reports

Boot method: microSD card
Image version: 
http://ftp.debian.org/debian/dists/testing/main/installer-armhf/current/images/hd-media/hd-media.tar.gz

Date: 2019-02-22T20:57:53-07:00

Machine: ClearFog Base
Processor: Marvell ARMADA A388 ARM A9
Memory: 1GB
Partitions: single ext4 partition, primary part 1

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[E]
Configure network:  [ ]
Detect CD:  [O]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives:  [ ]
Install base system:[ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:

I encounter a consistent kernel oops when trying to install Debian onto 
a SolidRun ClearFog Base device. I previously attempted installation 
using the Buster Alpha 4 version of the installer, and have just 
retested using Alpha 5 version and get the same result. This particular 
device is using a self-compiled U-Boot version based on upstream sources 
at v2018.11.


To prepare the installation media, I downloaded the armhf hd-media 
archive [1], and then unpacked the contents into a single ext4 partition 
on a micro SD card. I then copied the armhf netinst ISO image to the 
root of the filesystem.


The installer boots successfully, goes through the language selection 
and location prompts, then proceeds to mount the mmcblk0 device, find 
the ISO image, and cycles through "Loading additional components". When 
it completes component loading, it proceed to detecting network devices, 
at which point I get a kernel oops dump like the one below. The 
installation happens via serial (USB FTDI) connection, so I apologize 
for the corruption in the capture of the message.


[   68.717677] Unable to handle kernel paging request at virtual address 
2680

[   68.725981] pgd = (ptrval)
[   68.730086] [2680] *pgd=
[   68.735082] Internal error: Oops: 5 [#1] SMP ARM
[   68.741086] Modules linked in: marvell mvmdio(+) mvneta(+) mvneta_bm 
phylink sfp mdio_i2c nls_utf8 dm_mod loop isofs vfat fat ext4 crc16 
mbcache jbd2 crc32c_generic fscrypto usb_storage sd_mod gpio_pca953x 
ehci_orion ahci_mve bu ehci_hcd libahci_platform libahci sdhci_pxav3 
xhci_plat_hcd xhci_hcd sdhci_pltfm libata sdhci scsi_mod usbcore 
i2c_mv64xxx
[   68.772053] CPU: 0 PID: 13 Comm: kworker/0:1 Not tainted 
4.19.0-1-armmp #1 Debian 4.19.12-1

[   68.780422] Hardware name: Marvell Armada 380/385 (Device Tree)
[   68.786370] Workqueue: events_power_efficient phylink_resolve 
[phylink]

[   68.793033] PC is at mvneta_port_down+0x20/0x1a0 [mvneta]
[   68.798454] LR is at mvneta_mac_link_down+0x24/0x90 [mvneta]
[   68.804125] pc : []lr : []psr: 600b0013
[   68.810406] sp : ee96be60  ip : ee96be88  fp : ee96be84
[   68.815641] r10:   r9 : eef1c99c  r8 : eef1c900
[   68.820876] r7 : eef1c960  r6 : ede82000  r5 : 0002  r4 : 
ede82580
[   68.827417] r3 : 2680  r2 : 0004  r1 : 0002  r0 : 
ede82580
[   68.833959] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  
Segment none

[   68.841109] Control: 10c5387d  Table: 0fe9804a  DAC: 0051
[   68.846867] Process kworker/0:1 (pid: 13, stack limit = 0x(ptrval))
[   68.853147] Stack: (0xee96be60 to 0xee96c000)
[   68.857514] be60: ede82000 0002 ede82000 eef1c960 eef1c900 
eef1c99c ee96bea4 ee96be88
[   68.865711] be80: bf51b490 bf51b2d8 eef1c998 c1105dcc ede82000 
eef1c960 ee96befc ee96bea8
[   68.873908] bea0: bf507000 bf51b478 c0aeb1e8 c037bc10 0001 
 ee96bee4 ee96bec8
[   68.882104] bec0: c04f637c c050ebdc  2e6b8000 c1018c40 
4bd6f77b ee8d6180 eef1c998
[   68.890301] bee0: ee8d6180 ef6d0840 ef6d3f00  ee96bf34 
ee96bf00 c036c090 bf506eac
[   68.898497] bf00: 0008 ef6d0858 c1104d00 ee8d6180 ee8d6194 
ef6d0840 0008 ef6d0858
[   68.906695] bf20: c1104d00 ef6d0840 ee96bf74 ee96bf38 c036d0a4 
c036bed4 ee8f6e40 c0c7436c
[   68.914891] bf40: c11f1428 e000 c0372638 ee8f6600 ee8f6e40 
 ee96a000 ee8d6180
[   68.923088] bf60: c036d044 ee957e74 ee96bfac ee96bf78 c0372b58 
c036d050 ee8f661c ee8f661c
[   68.931285] bf80: ee96bfac ee8f6e40 c03729ec   
  
[   68.939482] bfa0:  ee96bfb0 c03010e8 c03729f8  
  
[   68.947678] bfc0:      
  
[   68.955875] bfe0:     0013 
  
[   68.964102] [] (mvneta_port_down [mvneta]) from 
[] (mvneta_mac_link_down+0x24/0x90 [mvneta]
) ┌─┤ Detecting network hardware 
├──┐
[ │  
   │ (phylink_resolve+0x160/0x2dc [phylin
k]│0%  

Bug#923022: console-setup ships minified shell scripts

2019-02-22 Thread Wookey
Package: console-setup
Version: 1.189
Severity: normal
Tags: patch

/bin/setupcon and /usr/bin/ckbcomp-mini are both shell scripts that
are minified (preprocessed to remove comments, whitespace and
indenting) before being shipped in the udeb.

/usr/lib/base-installer.d/20console-setup and 
usr/share/console-setup/keyboard-configuration.config

setupcon is a 38K script before minifying and 22K afterwards. It's
extremely difficult to read to work out what on earth it is doing when
in that state, and this is sometimes necessary (e.g. when debugging
debian-installer). ckbcomp-mini goes from 5.4K to 3.3K keyboardconfiguration 
from 47K to 44K

The debian config and postinst scripts get the same treatment (in the
conventional and udeb packages

Why are we minifying these scripts? Perhaps it made sense once to
squeeze the size of console-setup by a few K (maybe 24?), but it seems
very unlikely to be useful any more, given the cost of making
comprehension of the code almost impossible.

Attached is a patch to stop doing this. (It makes the udeb 6K bigger)
commit dac59c59d9a71612e8a1fbca744ba3b53f57663e
Author: Wookey 
Date:   Sat Feb 23 04:10:42 2019 +

Stop minifying shell scripts

diff --git a/debian/changelog b/debian/changelog
index ea8a91d..c43b1db 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+console-setup (1.190) unstable; urgency=medium
+
+  * Stop minifying shell scripts
+
+ -- Wookey   Sat, 23 Feb 2019 03:23:03 +
+
 console-setup (1.189) unstable; urgency=medium
   * Team upload
 
diff --git a/debian/preprocessor b/debian/preprocessor
index a9c3aa5..9571309 100755
--- a/debian/preprocessor
+++ b/debian/preprocessor
@@ -94,11 +94,6 @@ else
 }' "$file" >$tmp && cat $tmp >"$file"
 fi
 
-if [ "$mini" ]; then
-sed -e 's/^[ \t]*//' -e 's/^#[^!].*//' -e 's/^#$//' <"$file" >$tmp \
-   && grep . $tmp >"$file"
-fi
-
 rm $tmp
 
 exit 0


Bug#915546: marked as done (Installation of Debian 10 on Asus Zenbook U501J)

2019-02-22 Thread Debian Bug Tracking System
Your message dated Sat, 23 Feb 2019 06:15:56 +0100
with message-id 
and subject line Installation was successfully
has caused the Debian Bug report #915546,
regarding Installation of Debian 10 on Asus Zenbook U501J
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
915546: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915546
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: installation-reports

Boot method: PXE UEFI Boot
Image version:

> https://d-i.debian.org/daily-images/amd64/20181202-00:21/netboot/gtk/debian-installer/amd64/initrd.gz
> https://d-i.debian.org/daily-images/amd64/20181202-00:21/netboot/gtk/debian-installer/amd64/linux

Date: 2018-12-04

Machine: Asus Zenbook Pro UX501J
Processor: Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz
Memory: 16GB
Partitions: 

> DateisystemTyp  1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
> udev   devtmpfs   8142324   0   81423240% /dev
> tmpfs  tmpfs  16314729140   16223321% /run
> /dev/sda2  ext4 105628416 7027864  931918888% /
> tmpfs  tmpfs  81573483256   81540921% /dev/shm
> tmpfs  tmpfs 5120   4  51161% /run/lock
> tmpfs  tmpfs  8157348   0   81573480% /sys/fs/cgroup
> /dev/sda1  vfat523248 1325231161% /boot/efi
> tmpfs  tmpfs  1631468  40   16314281% /run/user/1000

Output of lspci -knn:

> 00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v3/4th Gen Core 
> Processor DRAM Controller [8086:0c04] (rev 06)
>   Subsystem: ASUSTeK Computer Inc. Xeon E3-1200 v3/4th Gen Core Processor 
> DRAM Controller [1043:18dd]
>   Kernel modules: ie31200_edac
> 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v3/4th Gen Core 
> Processor PCI Express x16 Controller [8086:0c01] (rev 06)
>   Kernel driver in use: pcieport
> 00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core 
> Processor Integrated Graphics Controller [8086:0416] (rev 06)
>   Subsystem: ASUSTeK Computer Inc. 4th Gen Core Processor Integrated 
> Graphics Controller [1043:18dd]
>   Kernel driver in use: i915
>   Kernel modules: i915
> 00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen Core 
> Processor HD Audio Controller [8086:0c0c] (rev 06)
>   Subsystem: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD 
> Audio Controller [8086:2010]
>   Kernel driver in use: snd_hda_intel
>   Kernel modules: snd_hda_intel
> 00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset 
> Family USB xHCI [8086:8c31] (rev 05)
>   Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset Family 
> USB xHCI [1043:18dd]
>   Kernel driver in use: xhci_hcd
>   Kernel modules: xhci_pci
> 00:16.0 Communication controller [0780]: Intel Corporation 8 Series/C220 
> Series Chipset Family MEI Controller #1 [8086:8c3a] (rev 04)
>   Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset Family 
> MEI Controller [1043:18dd]
>   Kernel driver in use: mei_me
>   Kernel modules: mei_me
> 00:1a.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset 
> Family USB EHCI #2 [8086:8c2d] (rev 05)
>   Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset Family 
> USB EHCI [1043:18dd]
>   Kernel driver in use: ehci-pci
>   Kernel modules: ehci_pci
> 00:1b.0 Audio device [0403]: Intel Corporation 8 Series/C220 Series Chipset 
> High Definition Audio Controller [8086:8c20] (rev 05)
>   Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset High 
> Definition Audio Controller [1043:18dd]
>   Kernel driver in use: snd_hda_intel
>   Kernel modules: snd_hda_intel
> 00:1c.0 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset 
> Family PCI Express Root Port #1 [8086:8c10] (rev d5)
>   Kernel driver in use: pcieport
> 00:1c.2 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset 
> Family PCI Express Root Port #3 [8086:8c14] (rev d5)
>   Kernel driver in use: pcieport
> 00:1c.3 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset 
> Family PCI Express Root Port #4 [8086:8c16] (rev d5)
>   Kernel driver in use: pcieport
> 00:1d.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset 
> Family USB EHCI #1 [8086:8c26] (rev 05)
>   Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset Family 
> USB EHCI [1043:18dd]
>   Kernel driver in use: ehci-pci
>   Kernel modules: ehci_p