Bug#919842: Jetson-tx1: successful, but required customized boot media

[Vagrant Cascadian]

Package: installation-reports
Severity: normal

Overall install went ok, but requires manually constructing an image
to boot as USB requires binary firmware blob.

Using UEFI images are limited as they do not support loading a .dtb
matching the kernel, and the device-tree passed by u-boot's EFI
implementation lacks some features (SMP, SATA).

Once booted with the USB firmware blob loaded and correct .dtb loaded,
the install worked fine.

live well,
  vagrant

-- Package-specific info:

Boot method: microSD
Image version: 
https://d-i.debian.org/daily-images/arm64/20190119-02:06/netboot/debian-installer/arm64/
Date: 2019-01-19 ~18:00 -0800

Machine: Jetson-tx1 (tegra210-p2371-2180)
Partitions:
Filesystem Type 1K-blocksUsed Available Use% Mounted on
udev   devtmpfs   1713500   0   1713500   0% /dev
tmpfs  tmpfs   3521604696347464   2% /run
/dev/mmcblk0p1 ext4  14384136 1330676  12303076  10% /
tmpfs  tmpfs  1760780   0   1760780   0% /dev/shm
tmpfs  tmpfs 5120   0  5120   0% /run/lock
tmpfs  tmpfs  1760780   0   1760780   0% /sys/fs/cgroup
tmpfs  tmpfs   352156   0352156   0% /run/user/1000

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

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

Comments/Problems:

I had to append the tegra210/xusb.bin firmware to the initrd, because
it's only shipped in firmware-misc-nonfree, and so assembled an image
by hand using the linux, initrd.gz and .dtb (tegra210-p2371-2180), as
described here:

  https://wiki.debian.org/InstallingDebianOn/NVIDIA/Jetson-TX1

Instead of generating a boot script, I used an extlinux menu, and
generated an ext4 partition on an SD card, dropping linux, initrd.gz
(with the xusb.bin appended), and "dtb" symlinked to the device-tree
(as u-boot doesn't set $fdtfile).

default di
menu title Debian-Installer Menu
prompt 0

label di
menu label Debian Installer
linux /linux
initrd /initrd.gz
fdt /dtb

Once booted, it detected the network interface (which is on the USB
bus), and the install proceeded smoothly.

-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="10 (buster) - installer build 20190119-02:03"
X_INSTALLATION_MEDIUM=netboot

==
Installer hardware-summary:
==
uname -a: Linux jtx1cx 4.19.0-1-arm64 #1 SMP Debian 4.19.13-1 (2018-12-30) 
aarch64 GNU/Linux
usb-list: 
usb-list: Bus 01 Device 01: xHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 01
usb-list:Manufacturer: Linux 4.19.0-1-arm64 xhci-hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 02 Device 01: xHCI Host Controller [1d6b:0003]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 03
usb-list:Manufacturer: Linux 4.19.0-1-arm64 xhci-hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 02 Device 02: USB 10/100/1000 LAN [0955:09ff]
usb-list:Level 01 Parent 01 Port 00  Class 00(>ifc ) Subclass 00 Protocol 00
usb-list:Manufacturer: Nvidia
usb-list:Interface 00: Class ff(vend.) Subclass ff Protocol 00 Driver r8152
lsmod: Module  Size  Used by
lsmod: dm_mod143360  7
lsmod: md_mod155648  0
lsmod: xfs  1273856  0
lsmod: jfs   196608  0
lsmod: btrfs1265664  0
lsmod: xor20480  1 btrfs
lsmod: zstd_decompress65536  1 btrfs
lsmod: zstd_compress 163840  1 btrfs
lsmod: xxhash 16384  2 zstd_compress,zstd_decompress
lsmod: raid6_pq  106496  1 btrfs
lsmod: libcrc32c  16384  2 btrfs,xfs
lsmod: vfat   24576  0
lsmod: fat81920  1 vfat
lsmod: ext4  659456  1
lsmod: crc16  16384  1 ext4
lsmod: mbcache16384  1 ext4
lsmod: jbd2 

Re: Multiple console support in d-i

[Ben Hutchings]

On Sun, 2019-01-20 at 01:21 +, Wookey wrote:
> On 2019-01-19 20:11 +, Ben Hutchings wrote:
> > On Sat, 2019-01-19 at 11:08 +, Steve McIntyre wrote:
> > [...]
> > >  * add lots more console= options to the grub.cfg for arm64 (to cover
> > >all the possibilities), then let d-i startup work out which devices
> > >exist from /proc/cmdlinge and spawn d-i on each.
> > [...]
> > 
> > I think you should look in /proc/consoles, not /proc/cmdline.  The
> > format is documented in
> > https://www.kernel.org/doc/Documentation/filesystems/proc.txt
> 
> Interesting.
> 
> Currently reopen-consoles does:
> if d-i console not already recorded
>  set console using kernel 'handover' message (in dmesg) if running pre 2.6.38 
> kernel
>  unless it's set to serial on a non-serial tty, in which case unset it
>  make list of 'enabled consoles' from 1st 260k of dmesg
>  if one matching device, then set as console
>  if still not found (only) one, set to last one in kernel command line args 
>  if still not found one, default to /dev/console
>  record chosen console
> fi
> start d-i on recorded console.
> 
> I'm not entirely convinced that all this logic is actually needed/optimum,
> but I don't know the history of it. 

You can certainly remove anything that relates to old kernel versions.

> How exactly does /proc/consoles fit into that? The docs say it is
> "registered system consoles". Does that correspond to the same list of
> 'enabled consoles' the above is currently fishing out of dmesg?

/proc/consoles shows everything on the global console_drivers list. 
Every time a console is added to the list the kernel logs a message
with the format "%sconsole [%s%d] enabled\n".  So these should match,
except that (1) it is also possible to unregister consoles, and reopen-
consoles doesn't account for that (2) the kernel log might have rolled
over so that reopen-console-linux doesn't see the messages.

> Does it include any/all listed explicitly on the kernel command line?

It's a bit more complicated than that.  The kernel has a table of up to
8 "preferred" console devices, which can be specified on the kernel
command, or through Device Tree or platform code, or by a hypervisor. 
The device specified last (which usually means the last console=
argument on the command line) is the most preferred.

If some preferred devices are specified, then console_drivers will
include all the console devices that are preferred *and* have been
found to exist, and the most preferred (if it exists) will be first.

Otherwise, the kernel seems to enable the first console device found to
exist.

> My current code leaves all this alone and just records/uses all
> enabled consoles on the command line, not just the last one, but
> ideally we'd autodetect and/or hardcode all the sensible available
> consoles and run on them.
> 
> If 'read /proc/consoles (and check the devices exist)' does this, then
> that sounds very sensible.

Reading /proc/consoles is exactly what you should do.

Ben.

-- 
Ben Hutchings
You can't have everything.  Where would you put it?



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

Re: Multiple console support in d-i

[Wookey]

On 2019-01-19 20:11 +, Ben Hutchings wrote:
> On Sat, 2019-01-19 at 11:08 +, Steve McIntyre wrote:
> [...]
> >  * add lots more console= options to the grub.cfg for arm64 (to cover
> >all the possibilities), then let d-i startup work out which devices
> >exist from /proc/cmdlinge and spawn d-i on each.
> [...]
> 
> I think you should look in /proc/consoles, not /proc/cmdline.  The
> format is documented in
> https://www.kernel.org/doc/Documentation/filesystems/proc.txt

Interesting.

Currently reopen-consoles does:
if d-i console not already recorded
 set console using kernel 'handover' message (in dmesg) if running pre 2.6.38 
kernel
 unless it's set to serial on a non-serial tty, in which case unset it
 make list of 'enabled consoles' from 1st 260k of dmesg
 if one matching device, then set as console
 if still not found (only) one, set to last one in kernel command line args 
 if still not found one, default to /dev/console
 record chosen console
fi
start d-i on recorded console.

I'm not entirely convinced that all this logic is actually needed/optimum,
but I don't know the history of it. 

How exactly does /proc/consoles fit into that? The docs say it is
"registered system consoles". Does that correspond to the same list of
'enabled consoles' the above is currently fishing out of dmesg? Does
it include any/all listed explicitly on the kernel command line?

My current code leaves all this alone and just records/uses all
enabled consoles on the command line, not just the last one, but
ideally we'd autodetect and/or hardcode all the sensible available
consoles and run on them.

If 'read /proc/consoles (and check the devices exist)' does this, then
that sounds very sensible.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: UEFI Secure Boot changes in d-i and live images

[Ben Hutchings]

On Sun, 2019-01-20 at 00:16 +0100, Philipp Kern wrote:
> Hi,
> 
> On 2019-01-13 20:23, Steve McIntyre wrote:
[...]
> > I'll test all these again in the next couple of days to verify that
> > things have pulled through as I expect, then it's time to post to
> > d-d-a and write a blog too. We've made great progress already. These
> > last changes just tie it all together for end users.
> 
> I just tried to test this. As far as I can see grub is still signed by 
> "secure-boot-test-key-lfaraone" as of netinst from yesterday (Saturday). 
[...]

Yes, this is expected.  Does anyone want to implement the proposal I
made at 
or are we just going to have a flag day and hope no-one screws up after
that?

Ben.

-- 
Ben Hutchings
You can't have everything.  Where would you put it?



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

Processed: Bug #900918 in debian-installer marked as pending

[Debian Bug Tracking System]

Processing control commands:

> tag -1 pending
Bug #900918 [debian-installer] debian-installer: Please make the generated 
images reproducible
Ignoring request to alter tags of bug #900918 to the same tags previously set

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

Re: UEFI Secure Boot changes in d-i and live images

[Philipp Kern]

Hi,

On 2019-01-13 20:23, Steve McIntyre wrote:

I've just pushed changes to a few bits of d-i this weekend to make SB
work for amd64:

 * build/util/efi-image:

   We can use pre-existing (and already signed) EFI binaries instead
   of building a new monolithic image ourselves (which won't be
   signed). We'll also need to install the shim-signed binary so that
   it will be called first then can chain-load the grub binary.

   Tested and working for boot both via netinst image and network
   boot for amd64 (signed) and i386 (non-signed). The netboot mini.iso
   is also updated and will now work with SB on amd64.

   * This will want documentation updates. Most people won't
 notice the change, *BUT* people using netboot on amd64 will
 need to tftp-serve both shim (as bootnetx64.efi) and grub (as
 grubx64.efi) where previously they just needed grub (as
 bootnetx64.efi)

 * build/config/arm.cfg, build/config/x86.cfg :

   Trivial tweaks to match output changes in efi-image

 * debian/control:

   update build-deps to match those changes

 * grub-installer/grub-installer:

   Small changes to make sure we install shim-signed on amd64
   alongside grub-efi-arm64 and grub-efi-arm64-signed. This will make
   a new amd64 installation now work work with SB out of the box.

   (If SB is disabled, shim etc. will harmlessly fall through to normal
   existing behaviour.)

   I've uploaded grub-installer too.

The effect of these changes is that the next daily and weekly debian
installer images (tomorrow) should Just Work (TM) end-to-end with UEFI
Secure Boot. The changes to efi-image also mean that our next live
image builds will do SB (for live and installation).

I'll test all these again in the next couple of days to verify that
things have pulled through as I expect, then it's time to post to
d-d-a and write a blog too. We've made great progress already. These
last changes just tie it all together for end users.


I just tried to test this. As far as I can see grub is still signed by 
"secure-boot-test-key-lfaraone" as of netinst from yesterday (Saturday). 
The signature is dated Mon, 14 Jan 2019 01:13:20 (supposedly my time I 
guess). When trying to boot netinst under SB (admittedly on a 5 year old 
Gigabyte mainboard) I get an "Access denied" error back from image 
verification. Unfortunately it does not tell me what exactly failed 
verification. But shim looks ok from Windows.


Kind regards and thanks for all your work on making this finally happen
Philipp Kern

Processed: Re: Bug#900918: debian-installer: Please make the generated images reproducible

[Debian Bug Tracking System]

Processing control commands:

> tag -1 pending
Bug #900918 [debian-installer] debian-installer: Please make the generated 
images reproducible
Added tag(s) pending.

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

Bug#900918: debian-installer: Please make the generated images reproducible

[Cyril Brulebois]

Control: tag -1 pending

Cyril Brulebois  (2019-01-19):
> The mini.iso has apparently other changes… I'm attaching the diffoscope
> output. Could this be because of missing tweaks to the xorriso calls in
> build/config/x86.cfg? (In which case build/config/arm.cfg might need an
> update as well.) Checking all MINIISO occurrences might also make sense
> I suppose?

FWIW, dropping all fontconfig-related bits (see attached patch) makes it
possible to confirm only mini.iso (regular and gtk ones) are showing
differences now:

installer-amd64/20190119/images/MD5SUMS
installer-amd64/20190119/images/netboot/gtk/mini.iso
installer-amd64/20190119/images/netboot/mini.iso
installer-amd64/20190119/images/SHA256SUMS


I had purged the pigz package during my experiments, just to be sure it
wouldn't interfere:

build/Makefile:gzip = $(shell which pigz >/dev/null 2>&1 && echo "pigz -n 
-T" || echo "gzip -n")

(Including lintian runtime, using pigz on a 8-way machine cuts real time
from 8m8s to 4m23s.)

Checking what happens, and forgetting about the aforementioned mini.iso
images temporarily, it seems successive builds with pigz lead to the
same results. But those aren't the same as the results generated with
gzip. I don't suppose this is going to be a particularly huge problem
though?


Anyway, summarizing: likely more work to be done on the xorriso front,
(on the debian-installer side) for the mini.iso images produced for
netbooting; and fontconfig needs to get fixed in some way at some point
(but I know it's been a long run as well…); but all the rest looks good.

Pushing once I have updated the changelog; marking as pending, thanks!


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
From b1de326f8e97105e97beaf8b14c4af88894a62f0 Mon Sep 17 00:00:00 2001
From: Cyril Brulebois 
Date: Sat, 19 Jan 2019 22:09:23 +
Subject: [PATCH] Remove unreproducible bits due to fontconfig.

---
 build/Makefile | 5 +
 1 file changed, 5 insertions(+)

diff --git a/build/Makefile b/build/Makefile
index 22abaac1d..2e6a0c76c 100644
--- a/build/Makefile
+++ b/build/Makefile
@@ -634,6 +634,11 @@ endif
 		fc-cache -s -y "$(TREE)"; \
 	fi
 
+	# Clean everything to check reproducibility:
+	@echo "HACK ALERT: fontconfig clean-up"
+	rm -v -rf "$(TREE)/var/cache/fontconfig"
+	find "$(TREE)" -name .uuid -print -delete
+
 	# Remove some unnecessary dpkg files.
 	set -e; \
 	for file in `find $(TREE)/var/lib/dpkg/info -name '*.md5sums' -o \
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#900918: debian-installer: Please make the generated images reproducible

[Cyril Brulebois]

Cyril Brulebois  (2019-01-19):
> Back to d-i results: I'm seeing small differences in the generated
> -images tarball, that I'll try to investigate. I'll probably push the
> series anyway, as these patches are helping anyway. :)

Here are the differences I'm seeing by building multiple times in the
same sid devel chroot:

installer-amd64/20190119/images/cdrom/gtk/initrd.gz
installer-amd64/20190119/images/hd-media/boot.img.gz
installer-amd64/20190119/images/hd-media/gtk/initrd.gz
installer-amd64/20190119/images/MD5SUMS
installer-amd64/20190119/images/netboot/gtk/debian-installer/amd64/initrd.gz
installer-amd64/20190119/images/netboot/gtk/mini.iso
installer-amd64/20190119/images/netboot/gtk/netboot.tar.gz
installer-amd64/20190119/images/netboot/mini.iso
installer-amd64/20190119/images/SHA256SUMS

*SUMS are no-brainers due to changes in other files.

All gtk files have fontconfig-related cache/uuid changes…

Excluding those, remaining files are:

installer-amd64/20190119/images/hd-media/boot.img.gz
installer-amd64/20190119/images/netboot/mini.iso

The boot.img includes two initrds: initrd.gz and initrdg.gz; the latter
is the one with graphical support, which explains why it's also hit by
the fontconfig cache/uuid problem.

The mini.iso has apparently other changes… I'm attaching the diffoscope
output. Could this be because of missing tweaks to the xorriso calls in
build/config/x86.cfg? (In which case build/config/arm.cfg might need an
update as well.) Checking all MINIISO occurrences might also make sense
I suppose?


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
--- d-i-8/extract/installer-amd64/20190119/images/netboot/mini.iso
+++ d-i-9/extract/installer-amd64/20190119/images/netboot/mini.iso
│┄ Format-specific differences are supported for this file format but none were detected (DOS/MBR boot sector; partition 2 : ID=0xef, start-CHS (0x3ff,254,63), end-CHS (0x3ff,254,63), startsector 240, 5376 sectors; partition 3 : ID=0x1, start-CHS (0x28,0,1), end-CHS (0x2d,63,32), startsector 81920, 12288 sectors)
@@ -21,25 +21,25 @@
 0140: 04b3 07cd 103c 0a75 f1cd 18f4 ebfd   .<.u
 0150:          
 0160:          
 0170:          
 0180:          
 0190:          
 01a0:          
-01b0: f015    bd2c ea2e  8000  .,..
+01b0: f015    f3a8 811b  8000  
 01c0: 0100 003f 2027   0040 0100 00fe  ...? '.@
 01d0:  effe  f000  0015    
 01e0: 0128 013f 202d 0040 0100 0030    .(.? -.@...0
 01f0:        55aa  ..U.
 0200: 4546 4920 5041 5254  0100 5c00   EFI PART\...
-0210: 6d39 8060   0100     m9.`
+0210: eaae c021   0100     ...!
 0220: ff3f 0100   2200     .?.."...
-0230: de3f 0100   e54d 5a45 8789 8e48  .?...MZE...H
-0240: 94f8 d8a5 4fef 9546 0200     O..F
-0250: 8000  8000  2e4a 6260    .Jb`
+0230: de3f 0100   c3d2 f8ef b4ab 7940  .?y@
+0240: bcb6 4ce6 6ef7 1afc 0200     ..L.n...
+0250: 8000  8000  a705 e2f2    
 0260:          
 0270:          
 0280:          
 0290:          
 02a0:          
 02b0:          
 02c0:          
@@ -59,23 +59,23 @@
 03a0:          
 03b0:          
 03c0:          
 03d0:          
 03e0:          
 03f0:          
 0400: a2a0 d0eb e5b9 3344 87c0 68b6 b726 99c7  ..3D..h..&..
-0410: 39a0 b199 1b8e 6243 b6c7 10a4 2fa5 da3f  9.bC/..?
+0410: 169b 0fd6 bf07 7441 9901 f113 33d4 9991  ..tA3...
 0420:     473f 0100    .

Bug#900918: debian-installer: Please make the generated images reproducible

[Cyril Brulebois]

Hi Chris,

Chris Lamb  (2019-01-19):
> >  * 0c19a29645a6a3136f3a51da5d5cf1cfcec5fdfb mentions file system
> >ordering only, but that's just the sort part
> 
> I've split this commit and it is much clearer now.

Perfect, thanks.

> >  * 71391967763708055a65ed68999db8f4ea6fc6e6 sets “deb1” as the
> >FAT volume ID; have you checked with people like debian-cd@
> >whether another constant might make more sense?
> 
> Clarified where this comes from in the commmit and in the code
> itself.

Thanks.

> >  * ea1a896181daa3b82c5a62ae31839b457a0dbe0b modifies BUILD_DATE,
> >adding a few characters (“:SS”); that ends up in various help
> >screens
> 
> In my tests, this did not break any visual text wrapping, etc.

Perfect.

> >  * f181b4fe90b9030f515c7e6129239b96131b3926 oh more en_GB, yay.
> 
> Fixed (use 'results' instead).

(I was genuinely happy to learn about the en_GB version; always
struggling to remember how to spell it in French vs. (American) English,
was happy to discover the British English version. :))

> §
> 
> Thank you again for your review. Let me know if you would require any
> further modifications before merging. :-)

That's looking good but I'm seeing new warnings because of gzip's being
unhappy about the GZIP environment variable. This seems to have been
deprecated in gzip 1.8:

gzip: warning: GZIP environment variable is deprecated; use an alias or 
script

I'm attaching the patch I've deployed locally, and it seems to me that
[1] might want an update.

 1. https://wiki.debian.org/ReproducibleBuilds/TimestampsInGzipHeaders

An other solution would be to use tar | gzip instead of passing -I to
tar, but I thought I'd learn about that option in the process. :)

Back to d-i results: I'm seeing small differences in the generated
-images tarball, that I'll try to investigate. I'll probably push the
series anyway, as these patches are helping anyway. :)


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


signature.asc
Description: PGP signature

Bug#919813: os-prober fails to find any os's at all.

[Hendrik Boom]

Package: os-prober
Version: 1.77

os-prober fails to find any os's at all after a new Debian buster install,
not even the installed and running DEbian buster.

The install was done using the net-install CD on a USB stick on 2019 01 18,
downloaded immediately before the installation.

root@buster:/home/guest# os-prober
root@buster:/home/guest# 

This was run the day after installation.

The machine actually has two Linux systems installed:

* the newly installed Debian buster.
  * /boot on /dev/sda2, and / on /dev/sda6.
  * Installed yesterday.
* An older Devuan ascii.
  * /boot on /dev/sda1, and other partitions in an LVM on /dev/sda3
  * Installed a few months ago.

Both are now bootable from the grub2 boot menu installed by using the 
debian installer to install buster yesterday.  Presumably the installer 
used os-prober succesfully, but the os-prober I installed 
today using aptitude does not work.

Could they be different versions?

I'm not aware of anything unusual about the enviromnent.  It'a a Purism 
laptop.

-- hendrik

Re: Multiple console support in d-i

[Ben Hutchings]

On Sat, 2019-01-19 at 11:08 +, Steve McIntyre wrote:
[...]
>  * add lots more console= options to the grub.cfg for arm64 (to cover
>all the possibilities), then let d-i startup work out which devices
>exist from /proc/cmdlinge and spawn d-i on each.
[...]

I think you should look in /proc/consoles, not /proc/cmdline.  The
format is documented in
https://www.kernel.org/doc/Documentation/filesystems/proc.txt

Ben.

-- 
Ben Hutchings
Hoare's Law of Large Problems:
   Inside every large problem is a small problem struggling to get out.



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

Re: Please dak copy-installer 20190118

[Cyril Brulebois]

Hi,

Joerg Jaspert  (2019-01-19):
> On 15287 March 1977, Cyril Brulebois wrote:
> > FTPmasters, please sync the installer from sid to testing:
> > 
> >   dak copy-installer 20190118
> 
> [ ] dak@fasolo:~$ dak copy-installer 20190118
> 
> Will copy installer version 20190118 from suite unstable to
> testing.
> Architectures to copy: i386, amd64, mipsel, ppc64el, mips, armel, armhf,
> arm64, mips64el, hurd-i386
> Architectures to skip:
> Installer has been copied successfully.

Thanks!

I'm afraid I failed to misread the buildd status page before requesting
this “dak copy-installer” round, as s390x buildds were lagging behind
(zandonai had no daemon running); that's fixed now and debian-installer
is currently marked as Uploaded on the buildd side, and I don't remember
exactly when you can do the dak copy-installer dance. As soon as it's
marked Installed on the buildd.d.o status page?

Sorry for the extra step.


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


signature.asc
Description: PGP signature

Re: Scheduling 9.7

[Cyril Brulebois]

Hi,

Jonathan Wiltshire  (2019-01-18):
> Please indicate your availablility out of:
> 
>  - (Feb 2 unlikely, FOSDEM)
>  - Feb 9
>  - Feb 16

I should be able to make anything work regarding d-i preparations/checks
before the point release, thanks.


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


signature.asc
Description: PGP signature

Re: Multiple console support

[peter green]

On 19/01/19 04:27, Wookey wrote:

Arm64 (arm in general in fact) has a rather fundamental problem with
D-I, which is that both serial and display are sensible default
devices for the installer to run on. Which is 'correct' depends very
much on the hardware and the circumstances. You may be installing a
server in rack, or a dev board with no display, in which case serial
is ideal, or you may have a chromebook or an ARM desktop machine with
a screen plugged in and no easy access to the serial console.

This problem doesn't arise on x86 where there is 'always' a screen (or
some BIOs magic to reflect what would be on the screen to serial).

Steve (McIntyre) and I have been thinking about what to do about this,
so did some investigation and came up with a plan. Essentially it was
to run d-i on both if they are configured/available. This way anyone
looking at just one or the other will see D-I as they expect. The
patch is not intrusive and essentially nothing changes if there is
only one console so this should be a low-risk change.

One concern I would have is preseeding or other more-automated install modes. Presumablly 
this works out ok on a "normal" install because the instance of the installer 
that the user is *NOT* interacting with just sits there doing nothing but I would 
question if that is a reasonable assumption in general.

Re: Multiple console support in d-i

[Ian Campbell]

On Sat, 2019-01-19 at 11:08 +, Steve McIntyre wrote:
> >So far I have done a proof-of-concept hack and demonstrated that
> >running two instances does in fact work nicely without anything
> >obvious breaking. The console selection still needs some work/checking
> >(I've run out of time for that tonight, but it can easily be fished
> >out of the kernel command line args. (or we could get fancier).
> 
> Nod. Potentially we might end up of running on multiple
> consoles.

IIRC (and it hasn't changed in the years since I knew this stuff) we
already have this on some of the netconsole install images for
arm{el,hf}, you end up with an installer on serial and one on the ssh
connection. Not an identical situation since I think the second one is
only spawned when you login via ssh, but some sort of precedence I
guess!

Ian.

Bug#900918: debian-installer: Please make the generated images reproducible

[Chris Lamb]

[Keeping Kibi in CC as requested off-list, dropping mtools@p.d.o]

Dear Kibi,

First, thank you so much for your review. I believe I have resolve
all of your issues on the corresponding merge request, as well as
rebasing it against the current master:

  https://salsa.debian.org/installer-team/debian-installer/merge_requests/3
  
§

>  * 0c19a29645a6a3136f3a51da5d5cf1cfcec5fdfb mentions file system
>ordering only, but that's just the sort part

I've split this commit and it is much clearer now.

>  * 71391967763708055a65ed68999db8f4ea6fc6e6 sets “deb1” as the FAT
>volume ID; have you checked with people like debian-cd@ whether
>another constant might make more sense?

Clarified where this comes from in the commmit and in the code
itself.

>  * 7c533fa721c3ae89ca81d1336b5928a80ed0d531 thanks for the clarity
>[ also: “becuase” in commit message. ]

Fixed.

>  * c35b8688696b1b4563a45d0feeabc3a0c0f2eccb “determinstic”

Fixed.

>  * ea1a896181daa3b82c5a62ae31839b457a0dbe0b modifies BUILD_DATE, adding
>a few characters (“:SS”); that ends up in various help screens

In my tests, this did not break any visual text wrapping, etc.

>  * f181b4fe90b9030f515c7e6129239b96131b3926 oh more en_GB, yay.

Fixed (use 'results' instead).

§

Thank you again for your review. Let me know if you would require
any further modifications before merging. :-)


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Re: Multiple console support

[Richard Hector]

On 19/01/19 5:27 PM, Wookey wrote:
> This problem doesn't arise on x86 where there is 'always' a screen (or
> some BIOs magic to reflect what would be on the screen to serial).

Is that true? I'm sure the Soekris box I've got (in storage)
(admittedly, probably not a supported cpu any more) only has serial. And
only server-class machines generally do the redirection, don't they?
There are plenty of use cases for a headless machine that doesn't need
to be expensive, where serial would be useful and a screen inconvenient.

Is there a disadvantage to doing the same thing on all arches?

Richard



signature.asc
Description: OpenPGP digital signature

Re: Scheduling 9.7

[Donald Norwood]

On 1/19/19 5:28 AM, Steve McIntyre wrote:
> On Fri, Jan 18, 2019 at 06:44:56PM +, Jonathan Wiltshire wrote:
>> Hi,
>>
>> 9.7 is a bit overdue already (current events being a bit of a time-sink).
>>
>> Please indicate your availablility out of:
>>
>> - (Feb 2 unlikely, FOSDEM)
> 
> Quite.
> 
>> - Feb 9
>> - Feb 16
> 
> Both of those currently look free for me.
> 

Press can do either the 9th or the 16th, however, we do prefer the 16th. :)


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



signature.asc
Description: OpenPGP digital signature

Re: Please dak copy-installer 20190118

[Joerg Jaspert]

On 15287 March 1977, Cyril Brulebois wrote:

FTPmasters, please sync the installer from sid to testing:

  dak copy-installer 20190118


[ ] dak@fasolo:~$ dak copy-installer 20190118

Will copy installer version 20190118 from suite unstable to
testing.
Architectures to copy: i386, amd64, mipsel, ppc64el, mips, armel, armhf, 
arm64, mips64el, hurd-i386

Architectures to skip:
Installer has been copied successfully.

--
bye, Joerg

Re: Scheduling 9.7

[Joerg Jaspert]

On 15286 March 1977, Jonathan Wiltshire wrote:


 - Feb 9
 - Feb 16


Can deal with both.

--
bye, Joerg

Bug#911133: Graphical installer

[Steve McIntyre]

Forgot to add the bug in on the mails I just sent. Wookey has been
working through how to do some of this. See:

 * https://lists.debian.org/debian-boot/2019/01/msg00183.html
 * https://lists.debian.org/debian-boot/2019/01/msg00184.html

and my responses there.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I can't ever sleep on planes ... call it irrational if you like, but I'm
 afraid I'll miss my stop" -- Vivek Das Mohapatra

Re: arm64 graphical installer

[Steve McIntyre]

[ Adding CC to debian-arm for interest ]

On Sat, Jan 19, 2019 at 03:39:44AM +, Wookey wrote:
>I've done some work on getting the graphical installer going on arm64.

\o/

>It's not quite finished, but Steve suggested I publish where I'm at so
>I can get some help with the right set of module packages, and we can
>start fixing up missing bits.
>
>The first patch (enable-arm64-netboot-gtk.patch) enables the
>support. This allows X to start on the display (if the correct console
>is found/specified - see next mail). This looks lovely, but there is
>no input working, because there are no no x input drivers installed,
>nor modules for USB devices (keyboard and mouse are USB).
>
>The second patch (add-missing-arm64-netboot-modules.patch) endeavours
>to fix that, by putting arm64 on the same basis as amd64 in terms of
>modules loaded.  However not all module packages are built for arm64
>so I had to remove some to get a working build.
>
>Missing modules (not built on arm64) are:
>mouse-modules
>speakup-modules
>acpi-modules
>sound-modules
>
>we should fix that too.
>
>I was not able to demonstrate that the resulting build works fully,
>because when it tries to boot the kernel I get "Error: Invalid Magic
>number..., you need to load the kernel first". No idea why that's
>changed due to adding more module packages? Clues welcome.
>
>This all sounds more broken than it is: the difficult bit of the
>graphics works fine, we just need to make sure the right modules for X
>input are available too.

Nod. I'm thinking that arm64 is likely to look very similar to amd64
in terms of the desired module sets, module obviously-missing things
like pcmcia. :-)

Also: you've added these to a netboot gtk image. We'll want to add the
equivalent graphically-minded changes for the cdrom target too so we
can make working physical media.

>From b8d5ea7d37670c6c5f9cc251e1cfc5f007388eb6 Mon Sep 17 00:00:00 2001
>From: Wookey 
>Date: Tue, 8 Jan 2019 18:14:22 +
>Subject: Add support for graphical installer to arm64
>
>
>diff --git a/build/config/arm64.cfg b/build/config/arm64.cfg
>index d9e782d..f320324 100644
>--- a/build/config/arm64.cfg
>+++ b/build/config/arm64.cfg
>@@ -1,4 +1,4 @@
>-MEDIUM_SUPPORTED = cdrom netboot device-tree u-boot
>+MEDIUM_SUPPORTED = cdrom netboot netboot-gtk device-tree u-boot
> 
> KERNELMAJOR = 2.6
> # The version of the kernel to use.
>diff --git a/build/config/arm64/netboot-gtk.cfg 
>b/build/config/arm64/netboot-gtk.cfg
>new file mode 100644
>index 000..0f1d246
>--- /dev/null
>+++ b/build/config/arm64/netboot-gtk.cfg
>@@ -0,0 +1,24 @@
>+MEDIA_TYPE = netboot image
>+
>+NETBOOT_DIR_TARGETS = $(TEMP_INITRD) $(TEMP_KERNEL)
>+
>+TYPE = netboot/gtk
>+
>+TARGET = $(NETBOOT_DIR) $(NETBOOT_TAR) $(MINIISO)
>+EXTRANAME = netboot/gtk/
>+
>+BOOT_SCREEN_DIR = $(NETBOOT_PATH)/boot-screens/
>+
>+MANIFEST-NETBOOT_DIR = "PXE boot directory for tftp server (graphical 
>installer)"
>+MANIFEST-NETBOOT_TAR = "tarball of PXE boot directory (graphical installer)"
>+MANIFEST-MINIISO = "not so tiny CD image that boots the graphical netboot 
>installer"
>+
>+IS_PURE_GTK = 1
>+
>+KEEP_GI_LANGS = 1
>+
>+VIDEO_MODE=$(VIDEO_MODE_GTK)
>+
>+# All images that include cdebconf should include symbols needed by these
>+# plugins.
>+EXTRAUDEBS += cdebconf-gtk-entropy

>From b0bc63a3baeb1e46c469d75ff7d68929be267949 Mon Sep 17 00:00:00 2001
>From: Wookey 
>Date: Sat, 19 Jan 2019 03:13:40 +
>Subject: Add missing modules (usb, fat, virtio) to arm64 netboot build and
> xorg modules to netbook-gtk
>
>
>diff --git a/build/pkg-lists/netboot/arm64.cfg 
>b/build/pkg-lists/netboot/arm64.cfg
>index e07dff0..18ca630 100644
>--- a/build/pkg-lists/netboot/arm64.cfg
>+++ b/build/pkg-lists/netboot/arm64.cfg
>@@ -11,9 +11,22 @@ nic-modules-${kernel:Version}
> nic-usb-modules-${kernel:Version}
> nic-wireless-modules-${kernel:Version}
> virtio-modules-${kernel:Version}
>+usb-modules-${kernel:Version}
> 
> fb-modules-${kernel:Version} ?
> input-modules-${kernel:Version} ?
> 
>-#for all targets
>+# In case they need to load a driver image.
>+mountmedia
>+media-retriever
>+fat-modules-${kernel:Version}
>+usb-storage-modules-${kernel:Version}
>+mmc-modules-${kernel:Version} ?
>+
>+# brltty
>+brltty-udeb
>+serial-modules-${kernel:Version} ?
>+usb-serial-modules-${kernel:Version} ?
>+uinput-modules-${kernel:Version} ?
> 
>+#for all targets
>diff --git a/build/pkg-lists/netboot/gtk/arm64.cfg 
>b/build/pkg-lists/netboot/gtk/arm64.cfg
>new file mode 100644
>index 000..2d8530a
>--- /dev/null
>+++ b/build/pkg-lists/netboot/gtk/arm64.cfg
>@@ -0,0 +1,10 @@
>+#include "gtk-linux"
>+
>+#mouse-modules-${kernel:Version}
>+xserver-xorg-input-evdev-udeb
>+xserver-xorg-video-fbdev-udeb
>+
>+#speakup-modules-${kernel:Version}
>+#sound-modules-${kernel:Version}
>+#console-setup-linux-fonts-udeb
>+#espeakup-udeb



-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< Aardvark> I dislike C++ to start with. C++11 just seems to be
  

Re: Scheduling 9.7

[Steve McIntyre]

On Fri, Jan 18, 2019 at 06:44:56PM +, Jonathan Wiltshire wrote:
>Hi,
>
>9.7 is a bit overdue already (current events being a bit of a time-sink).
>
>Please indicate your availablility out of:
>
> - (Feb 2 unlikely, FOSDEM)

Quite.

> - Feb 9
> - Feb 16

Both of those currently look free for me.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
 whether they're being malicious or incompetent. Capital letters are forecast."
 Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html