Bug#971019: accidental chaining of debconf commands

[Wilco Baan Hofman]

On 13/02/2021 00:46, Cyril Brulebois wrote:
> Control: severity -1 important
> 
> (cc-ing Paul for information, due to interest in RC bugs)
> 
> Hello Wilco,
> 
> Wilco Baan Hofman  (2020-09-26):
>> Package: cdebconf
>> Version: 0.249
>> Severity: critical
>>
>> I have a problem with the debian installer, at the finish-install
>> stage in the udeb clock-setup.
> 
> I can't replicate it with a current-ish installation image
> (debian-10.7.0-amd64-netinst.iso)
> 
>> The interaction in the syslog during install (manually copied from screen):
>> finish-install: info: Running /usr/lib/finish-install.d/10clock-setup
>> debconf: --> FGET clock-setup/utc seen
>> debconf: <-- 0 true
>> debconf: --> SET clock-setup/utc true INPUT low clock-setup/utc
>> debconf: <-- 0 value set
>> debconf: --> GO
>> debconf: <-- 0 ok
>> debconf: --> GET clock/setup/utc
>> debconf: <-- 0 true INPUT low clock-setup/utc
>> debconf: --> GET clock-setup/system-time-changed
>> debconf: <-- 0 false
>> finish-install: /usr/lib/finish-install.d/10clock-setup: return: line
>> 46: illegal number: INPUT
>> finish-install: warning: /usr/lib/finish-install.d/10clock-setup
>> returned error code 2
> 
>> For reproducing the error if that's required:
>> This is a preseeded Debian Buster install on VMWare ESXi, relevant
>> preseed config:
> 
> I don't have VMWare ESXi, but I couldn't replicate this on bullseye's
> QEMU.
> 
>> ### Clock and timezone setup
>> # Controls whether or not the hardware clock is set to UTC.
>> d-i clock-setup/utc boolean true
>>
>> # You may set this to any valid setting for $TZ; see the contents of
>> # /usr/share/zoneinfo/ for valid values.
>> d-i time/zone string Europe/Amsterdam
>>
>> # Controls whether to use NTP to set the clock during the install
>> d-i clock-setup/ntp boolean true
>> # NTP server to use. The default is almost always fine here.
>> #d-i clock-setup/ntp-server string ntp.example.org
> 
> I've added a few variables on my own, just to make sure I wouldn't have
> to answer too many questions. The full file is attached for reference.
> 
> d-i started from the “Automated Graphical Install” menu with the
> following additions on the kernel command line:
> 
> url=https://mraw.org/~kibi/preseed.cfg DEBCONF_DEBUG=developer
> 
> with a 5G qemu-img-created as hda disk, and the iso as a cdrom.
> 
>> I can't really see why this path would be hit, "db_fget
>> clock-setup/utc seen" should return true and this whole thing should
>> be skipped, but somehow that is not how it works out.. and the debconf
>> confmodule just chains 2 commands together without any separation or
>> wait time, causing an error during finish-install, effectively halting
>> all installs.
>>
>> seems like either a clear separator is missing (newline?) or a buffer
>> must be flushed after every SET..
> 
> That's quite surprising, given that's not exactly a new feature, or a
> fast-paced changing codebase…
> 
> I'm lowering severity for the time being, I think we'd need a way to
> reproduce this before proceeding any further (that wouldn't involve a
> proprietary hypervisor as far as I'm concerned).
> 
> 

I managed to work around it. It seems as when you use 'in-target' in the
late script, that the problem starts to occur. chroot /target  does
not trigger it.

Still, it's a bit strange to have it start to chain to individual
commands together as if it is one.

-- Wilco

Bug#971019: accidental chaining of debconf commands

[Cyril Brulebois]

Wilco Baan Hofman  (2021-02-13):
> I managed to work around it. It seems as when you use 'in-target' in the
> late script, that the problem starts to occur. chroot /target  does
> not trigger it.
> 
> Still, it's a bit strange to have it start to chain to individual
> commands together as if it is one.

That's interesting. in-target mostly sets up a passthrough mode for
debconf, which could explain the differences between `in-target` and
`chroot /target` calls. I'm not sure why this would interfere with
debconf though.

Any chance you could be more specific about what you were doing via
in-target? Having some way to reproduce the issue would be a start.


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


signature.asc
Description: PGP signature

Re: Problem installing Debian on Dell XPS 13 9360 laptop

[Bernard McNeill]

On 10/02/2021 10:11, Bernard McNeill wrote:



On 08/02/2021 23:06, Lou Poppler wrote:

On Mon, 2021-02-08 at 22:59 +, Bernard McNeill wrote:


On 08/02/2021 22:44, Lou Poppler wrote:

On Mon, 2021-02-08 at 22:26 +, Bernard McNeill wrote:
[...]

I have one SSD (which has Win-10 on it), there is no other disk
(spinning or otherwise) on the machine.
The BIOS System Information says 'M.2. SATA =(none)'
and 'M.2. PCIe SSD-0=87NB51ASK5HS'.
However: Under BIOS System Configuration, 'SATA Operation' is set to
'RAID On', [other options are 'Disabled' and 'AHCI' ].



Interesting that Dell is making a distinction here between SATA and 
PCIe mass

storage, but calling its RAID foolishness "SATA Operation - RAID On".
Does this imply maybe that the SSD connected via PCIe and not via 
the SATA

wiring/controller, is exempt from the RAID interference?  I don't know.

It sure would be nice if that is what they mean though.
Maybe you can carefully test how this really works.
(Make the backup first though)




Is it even possible to RAID an SDD?


With software RAID, you can combine all manner of storage devices into a
"managed device" even different physical types of storage.  What this 
built-in
factory RAID might be is unclear to me.  From the misbehavior of the 
system
regarding your sometimes attached external USB disk (with the 
attempted debian

install on it) it seems likely that the factory/BIOS RAID thing might be
interposing itself between disks as seen by running programs (like the 
debian

installer) and the actual hardware storage itself.

[...]



FWIW, I found this link relating to Dell SSD, SATA and AHCI/RAID On.

https://www.dell.com/community/Laptops-General-Read-Only/Dell-M-2-FAQ-regarding-AHCI-vs-RAID-ON-Storage-Drivers-M-2-Lanes/td-p/507257 

But still unclear to me if changing 'RAID On' to 'AHCI' is going to 
cause a problem.


Best regards


FYI
Being persistent, I arranged for backup Windows knowledge in case 
everything fell apart, entered Windows safe mode, rebooted and changed 
the BIOS to: SATA Operation=AHCI (from RAID On), rebooted and got out of 
Windows safe mode.


Windows seemed undamaged, so I went on to reinstall Debian on the 
external HDD.


And there was a difference: This time, when the partitioner came up, it 
could see the internal SSD (previously it didn't, just showed the 
external HDD and the installer flash drive).


I have no idea why this should be, but carried on installing Debian over 
the entire external HDD.


And I still get the same result...it's as though the installer is not 
setting the Debian boot option to point to the HDD.


Any ideas gratefully received.

Bug#971019: accidental chaining of debconf commands

[Wilco Baan Hofman]

On 13/02/2021 18:05, Cyril Brulebois wrote:
> Wilco Baan Hofman  (2021-02-13):
>> I managed to work around it. It seems as when you use 'in-target' in the
>> late script, that the problem starts to occur. chroot /target  does
>> not trigger it.
>>
>> Still, it's a bit strange to have it start to chain to individual
>> commands together as if it is one.
> 
> That's interesting. in-target mostly sets up a passthrough mode for
> debconf, which could explain the differences between `in-target` and
> `chroot /target` calls. I'm not sure why this would interfere with
> debconf though.
> 
> Any chance you could be more specific about what you were doing via
> in-target? Having some way to reproduce the issue would be a start.

Well, mostly overwriting configuration files to only allow root group su
access and putting in SSH keys + cron job for maintaining those, postfix
config file, adding central syslog to rsyslog.conf, etc... But I'm
guessing those are all irrelevant.

What could be relevant (cobbler syntax):

#if $getVar("$init", "sysvinit") != "systemd"
# Remove systemd and dbus
dpkg -P systemd dbus libpam-systemd libnss-systemd

# Add systemd removal hints to APT
printf "Package: systemd-sysv\nPin: release o=Debian\nPin-Priority:
-1\n" > /etc/apt/preferences.d/use-sysvinit
#end if

#
# Stop quiet boot, we want debuggable boot and serial.
#
sed -i 's#^\(GRUB_CMDLINE_LINUX_DEFAULT\)="quiet"$#\1="console=tty0
console=ttyS0,115200n8"#' /etc/default/grub
update-grub


I'm guessing either update-grub or dpkg at that point may have some effect.


Kind regards,

-- Wilco

Re: Color choices for the installer

[Ben Hutchings]

On Tue, 2021-02-09 at 09:32 -0500, Jeffrey Walton wrote:
> On Tue, Feb 9, 2021 at 9:22 AM Peter Ehlert 
> wrote:
> > 
> > On 2/9/21 5:00 AM, Jeffrey Walton wrote:
> > > Hi Everyone,
> > > 
> > > I think the installer's choice of red for the background color can be
> > > improved. Red is a color associated with anger and aggression. Red as
> > > an accent would probably be OK, but the installer uses a wall of
> > > red.
> > I am just a common user, lurking. I do lots of installs and never have I
> > seen a Red background.
> > Please tell us which ISO you are using.
> 
> I am using debian-10.0.0-powerpc-NETINST-1.iso at
> https://cdimage.debian.org/cdimage/ports/snapshots/2021-02-02/.

I remember there being cases in the past where red and blue components
were swapped on some hardware.  I think you've just found another one
of those cases.

Ben.

-- 
Ben Hutchings
Quantity is no substitute for quality, but it's the only one we've got.


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

Re: Color choices for the installer

[Cyril Brulebois]

Ben Hutchings  (2021-02-13):
> I remember there being cases in the past where red and blue components
> were swapped on some hardware.  I think you've just found another one
> of those cases.

That rings a bell, I think I've had that many years ago with some
graphical applications on powerpc (iBook G4).

Oh, look, 15+ years ago!
  https://bugs.debian.org/327497


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


signature.asc
Description: PGP signature

Re: Problem installing Debian on Dell XPS 13 9360 laptop

[Holger Wansing]

Hi,

Bernard McNeill  wrote (Sat, 13 Feb 2021 18:24:35 +):
> And there was a difference: This time, when the partitioner came up, it 
> could see the internal SSD (previously it didn't, just showed the 
> external HDD and the installer flash drive).
> 
> I have no idea why this should be, but carried on installing Debian over 
> the entire external HDD.
> 
> And I still get the same result...it's as though the installer is not 
> setting the Debian boot option to point to the HDD.

What's the error/problem/message in detail?
Installation wents through fine, but machine cannot boot newly installed
Debian system?
Or installation fails at some step?


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Color choices for the installer

[John Paul Adrian Glaubitz]

On 2/13/21 8:02 PM, Cyril Brulebois wrote:
> Ben Hutchings  (2021-02-13):
>> I remember there being cases in the past where red and blue components
>> were swapped on some hardware.  I think you've just found another one
>> of those cases.
> 
> That rings a bell, I think I've had that many years ago with some
> graphical applications on powerpc (iBook G4).
> 
> Oh, look, 15+ years ago!
>   https://bugs.debian.org/327497

FWIW, I'm testing the installer regularly on my iBook G4 and I have not run
into this issue. Installer behaves correctly and colors aren't swapped either.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Color choices for the installer

[Geert Stappers]

On Sat, Feb 13, 2021 at 08:09:16PM +0100, John Paul Adrian Glaubitz wrote:
> On 2/13/21 8:02 PM, Cyril Brulebois wrote:
> > Ben Hutchings  (2021-02-13):
> >> I remember there being cases in the past where red and blue components
> >> were swapped on some hardware.  I think you've just found another one
> >> of those cases.
> > 
> > That rings a bell, I think I've had that many years ago with some
> > graphical applications on powerpc (iBook G4).
> > 
> > Oh, look, 15+ years ago!
> >   https://bugs.debian.org/327497
> 
> FWIW, I'm testing the installer regularly on my iBook G4 and I have not run
> into this issue. Installer behaves correctly and colors aren't swapped either.

Acknowlegde

And acknowlegde on the original post.



Groeten
Geert Stappers
-- 
Silence is hard to parse

Re: Problem installing Debian on Dell XPS 13 9360 laptop

[Bernard McNeill]

On 13/02/2021 19:08, Holger Wansing wrote:

Hi,

Bernard McNeill  wrote (Sat, 13 Feb 2021 18:24:35 +):

And there was a difference: This time, when the partitioner came up, it
could see the internal SSD (previously it didn't, just showed the
external HDD and the installer flash drive).

I have no idea why this should be, but carried on installing Debian over
the entire external HDD.

And I still get the same result...it's as though the installer is not
setting the Debian boot option to point to the HDD.


What's the error/problem/message in detail?
Installation wents through fine, but machine cannot boot newly installed
Debian system?
Or installation fails at some step?


Holger



The installation appears to go fine.
The installer creates a new entry 'Debian' in the boot list.
Machine rebooted, pressing F12 to get into one-time boot option.
Choice is 'Debian', or 'Windows Boot Manager'.
Take option 'Debian' and system then hangs with:
'Press F1 key to retry boot.'
'Press F2 key to reboot into setup.'
'Press F5 key to run onboard diagnostics.'

None of which lead to Debian.

Best regards

Re: Problem installing Debian on Dell XPS 13 9360 laptop

[Holger Wansing]

Hi,

Bernard McNeill  wrote (Sat, 13 Feb 2021 19:45:27 +):
> The installation appears to go fine.
> The installer creates a new entry 'Debian' in the boot list.
> Machine rebooted, pressing F12 to get into one-time boot option.
> Choice is 'Debian', or 'Windows Boot Manager'.
> Take option 'Debian' and system then hangs with:
> 'Press F1 key to retry boot.'
> 'Press F2 key to reboot into setup.'
> 'Press F5 key to run onboard diagnostics.'

During Debian installation, rather at the end, you have been prompted
where to install the GRUB bootloader, right?
What did you choose there?

Is the Windows system still bootable as usual?


Providing the installer logfiles would also be good, by the way...
See 
https://d-i.debian.org/doc/installation-guide/en.amd64/ch06s03.html#save-logs


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Problem installing Debian on Dell XPS 13 9360 laptop

[Bernard McNeill]

On 13/02/2021 21:43, Holger Wansing wrote:

Hi,

Bernard McNeill  wrote (Sat, 13 Feb 2021 19:45:27 +):

The installation appears to go fine.
The installer creates a new entry 'Debian' in the boot list.
Machine rebooted, pressing F12 to get into one-time boot option.
Choice is 'Debian', or 'Windows Boot Manager'.
Take option 'Debian' and system then hangs with:
'Press F1 key to retry boot.'
'Press F2 key to reboot into setup.'
'Press F5 key to run onboard diagnostics.'


During Debian installation, rather at the end, you have been prompted
where to install the GRUB bootloader, right?
What did you choose there?

Is the Windows system still bootable as usual?


Providing the installer logfiles would also be good, by the way...
See 
https://d-i.debian.org/doc/installation-guide/en.amd64/ch06s03.html#save-logs


Holger



+ During Debian installation, rather at the end, you have been prompted
+ where to install the GRUB bootloader, right?
I do not think I was given any choice - everything ran through to the 
point where I was warned to remove the installation media before rebooting.


+ Is the Windows system still bootable as usual?
Yes.

+ Providing the installer logfiles would also be good, by the way...
+ See 
https://d-i.debian.org/doc/installation-guide/en.amd64/ch06s03.html#save-logs

On a quick look, I don't see how to get at these if I can't get into Debian.

Best regards






I don't think I was prompted

Bug#982753: installation-reports: Bullseye installation fails creating XFS fs

[Andreas Schlager]

Package: installation-reports
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- Package-specific info:

Boot method: USB-Stick
Image version: 
https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso
 Build-Date:   2021-02-01 04:05
Date: 

Machine: Zotac Mini-PC
Partitions: 


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

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

Comments/Problems:
I tried to create XFS filesystems on LVM logical volumes. When completing the 
partition process, the installer successfully creates LVM vg and lv's, but 
failed to create the XFS filesystems.
A look into /var/log/syslog states something like: "partman: mkfs.xfs error 
while loading shared libraries libinih.so.1".
I switched to a tty console and tried to create the fs manually. The command 
"mkfs.xfs /dev/mapper/rootvg-rootlv" again failed with the above error.




-- 

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.

Bug#982753: installation-reports: Bullseye installation fails creating XFS fs

[Cyril Brulebois]

Hallo Andreas,

Andreas Schlager  (2021-02-13):
> I tried to create XFS filesystems on LVM logical volumes. When
> completing the partition process, the installer successfully creates
> LVM vg and lv's, but failed to create the XFS filesystems.
> 
> A look into /var/log/syslog states something like: "partman: mkfs.xfs
> error while loading shared libraries libinih.so.1". I switched to a
> tty console and tried to create the fs manually. The command "mkfs.xfs
> /dev/mapper/rootvg-rootlv" again failed with the above error.

Thanks for your report. That's unfortunately a known bug at the moment:
  https://bugs.debian.org/981662

This should get better once that one gets some attention:
  https://bugs.debian.org/981864

Hopefully we'll fix that before releasing the next Alpha, or a first
Release Candidate of the installer for Bullseye.


Mit freundlichen Grüßen,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Problem installing Debian on Dell XPS 13 9360 laptop

[Steve McIntyre]

On Sat, Feb 13, 2021 at 10:38:03PM +, Bernard McNeill wrote:
>> Bernard McNeill  wrote (Sat, 13 Feb 2021 19:45:27 
>> +):
>> > The installation appears to go fine.
>> > The installer creates a new entry 'Debian' in the boot list.
>> > Machine rebooted, pressing F12 to get into one-time boot option.
>> > Choice is 'Debian', or 'Windows Boot Manager'.
>> > Take option 'Debian' and system then hangs with:
>> > 'Press F1 key to retry boot.'
>> > 'Press F2 key to reboot into setup.'
>> > 'Press F5 key to run onboard diagnostics.'
>> 
>> During Debian installation, rather at the end, you have been prompted
>> where to install the GRUB bootloader, right?
>> What did you choose there?
>> 
>> Is the Windows system still bootable as usual?
>> 
>> Providing the installer logfiles would also be good, by the way...
>> See 
>> https://d-i.debian.org/doc/installation-guide/en.amd64/ch06s03.html#save-logs
>> 
>> 
>> Holger
>> 
>> 
>+ During Debian installation, rather at the end, you have been prompted
>+ where to install the GRUB bootloader, right?
>I do not think I was given any choice - everything ran through to the point
>where I was warned to remove the installation media before rebooting.

It's a UEFI system, so that's normal. I think what you're hitting here
looks like a similar bug to https://bugs.debian.org/905319. If you
follow the same workaround as suggested in

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905319#10

If you use the installation media to boot into rescue mode, it also
has an option to do the EFI removable media path thing.

***Be aware***: this will stop your system booting Windows directly,
you'll have to go via Grub to get there. I think there is a firmware
bug that's the root cause of your problem.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews

Bug#982422: marked as done (debootstrap: segmentation fault around ldconfig during debootstrapping bullseye/arm64 on a buster/amd64 host)

[Debian Bug Tracking System]

Your message dated Sun, 14 Feb 2021 02:24:56 +0100
with message-id 
and subject line Re: Bug#982422: debootstrap: segmentation fault around 
ldconfig during debootstrapping bullseye/arm64 on a buster/amd64 host
has caused the Debian Bug report #982422,
regarding debootstrap: segmentation fault around ldconfig during 
debootstrapping bullseye/arm64 on a buster/amd64 host
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.)


-- 
982422: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982422
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: debootstrap
Version: 1.0.114
Severity: normal

I'm struggling with a problem that I currently have with debootstrapping an
arm64 system on my amd64 machine. The attached script can reproduce the issue
here.

It crashes here on a debian buster amd64, in the 2nd debootstrap stage:

...
W: Failure trying to run:  /sbin/ldconfig
W: See //debootstrap/debootstrap.log for details

...
2021-02-10 01:05:52 URL:http://deb.debian.org/debian/pool/main/x/xz-
utils/liblzma5_5.2.5-1.0_arm64.deb [164436/164436] ->
"/...//var/cache/apt/archives/partial/liblzma5_5.2.5-1.0_arm64.deb" [1]
2021-02-10 01:05:52
URL:http://deb.debian.org/debian/pool/main/z/zlib/zlib1g_1.2.11.dfsg-2_arm64.deb
[87944/87944] ->
"/...//var/cache/apt/archives/partial/zlib1g_1%3a1.2.11.dfsg-2_arm64.deb" [1]
qemu: uncaught target signal 11 (Segmentation fault) - core dumped

It works if I debootstrap a buster system instead. Then trying to upgrade to
bullseye in the same chroot crashes with a segfault during the upgrade of libc-
bin. It also segfaults when I just open a chrooted shell after the 1st stage
and then run "ldconfig". That worked here around new year, but then broke.

This looks like a software bug somewhere. I'm not sure if I'm right here. But
maybe you can tell me.
#!/bin/bash

set -e

LOOPFILE=removemelater.loopfile
INNERROOT=removemelater.loopmnt
LOOPDEV=/dev/loop5

reproduce() {
dd if=/dev/zero of=$LOOPFILE bs=1M count=2048
losetup $LOOPDEV $LOOPFILE
mkfs.ext4 $LOOPDEV
mkdir $INNERROOT
mount $LOOPDEV $INNERROOT
debootstrap --arch=arm64 --foreign bullseye $INNERROOT
mount -o bind /sys $INNERROOT/sys
mount -o bind /dev $INNERROOT/dev
mount -o bind /dev/pts $INNERROOT/dev/pts
mount -o bind /proc $INNERROOT/proc
chroot $INNERROOT /bin/bash -c "/debootstrap/debootstrap --second-stage"
}

reproduce || cat $INNERROOT/debootstrap/debootstrap.log
--- End Message ---
--- Begin Message ---
Fixed by buster-backports.--- End Message ---