-------- Forwarded Message --------
From: Lou Poppler <LouPoppler@cableone.net>
To: Pete Batard <pete@akeo.ie>
Subject: Re: isorecorder
Date: Sun, 10 Jan 2021 18:20:55 -0700

On Sun, 2021-01-10 at 23:57 +0000, Pete Batard wrote:

On 2021.01.10 22:23, Lou Poppler wrote:

Let me emphasize that the unmodified debian installer images, when copied to a
USB stick via (unix) dd or cp, boot just fine in both UEFI mode and BIOS mode.
They also work just fine when copied unmodified to a CD or DVD.

I'm afraid I have to disagree with this, from direct empirical evidence.

This is a test I conducted a few moments ago, using the latest AMD64
netinst testing image (dated 2021.01.09). I didn't use Rufus to create
the bootable media but instead did it on Linux (up to date Armbian on an RK3399 platform) with the exact set of commands below:

You download a testing .iso
then you make a fresh MS vfat partition on sda1
then you rsync [some of] the .iso onto this partition.
Then you have problems booting from this USB.

-----

This is radically different from what I suggested above.

Here is my experiment:
lwp@william:~/Downloads$   wget https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso
lwp@william:~/Downloads$   umount /dev/sdb1 lwp@william:~/Downloads$   sudo bash root@william:/home/lwp/Downloads#   cp debian-testing-amd64-netinst.iso /dev/sdb
root@william:/home/lwp/Downloads#    sync

At this point I moved the USB stick to a Toshiba amd64 laptop,
and booted with no problems into the installer.

Notice especially that I did *not* copy the installer .iso onto a partition of the USB stick, 
I copied the image to the bare USB i.e. /dev/sdb _NOT_ /dev/sdb1

Here is what that USB stick looks like now:
root@william:/home/lwp/Downloads# fdisk /dev/sdb

Welcome to fdisk (util-linux 2.29.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): p
Disk /dev/sdb: 14.3 GiB, 15376318464 bytes, 30031872 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x5c546723

Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 0 745471 745472 364M 0 Empty
/dev/sdb2 3944 9863 5920 2.9M ef EFI (FAT-12/16/32)

Command (m for help): q

root@william:/home/lwp/Downloads#

[below is the remainder of your procedure]:

---------------------------------------------------------------------

root@nano:/mnt/ssd# wget https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso
root@nano:/mnt/ssd# mount -o loop debian-testing-amd64-netinst.iso /mnt/iso mount: /mnt/iso: WARNING: device write-protected, mounted read-only. root@nano:/mnt/ssd# dd if=/dev/zero of=/dev/sda bs=512 count=34
34+0 records in
34+0 records out
17408 bytes (17 kB, 17 KiB) copied, 0.0113974 s, 1.5 MB/s
root@nano:/mnt/ssd# dd if=/dev/zero of=/dev/sda bs=512 count=34 seek=$((`blockdev --getsz /dev/sda` - 34))
34+0 records in
34+0 records out
17408 bytes (17 kB, 17 KiB) copied, 0.0144371 s, 1.2 MB/s
root@nano:/mnt/ssd# gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.3

Partition table scan:
MBR: not present
BSD: not present
APM: not present
GPT: not present

Creating new GPT entries.

Command (? for help): n
Partition number (1-128, default 1): 1
First sector (34-234441614, default = 2048) or {+-}size{KMGTP}:
Last sector (2048-234441614, default = 234441614) or {+-}size{KMGTP}:
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300): 0700
Changed type of partition to 'Microsoft basic data'

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE
EXISTING PARTITIONS!!

Do you want to proceed? (Y/N): Y
OK; writing new GUID partition table (GPT) to /dev/sda.
The operation has completed successfully.
root@nano:/mnt/ssd# mkfs.vfat /dev/sda1
mkfs.fat 4.1 (2017-01-24)
root@nano:/mnt/ssd# mount /dev/sda1 /mnt/hd
root@nano:/mnt/ssd# rsync -av /mnt/iso/ /mnt/hd
sending incremental file list
rsync: symlink "/mnt/hd/debian" -> "." failed: Operation not permitted (1)
./
README.html
README.mirrors.html
README.mirrors.txt
README.source
README.txt
autorun.inf
g2ldr
g2ldr.mbr
md5sum.txt
setup.exe
win32-loader.ini
rsync: symlink "/mnt/hd/dists/testing" -> "bullseye" failed: Operation
not permitted (1)
rsync: symlink "/mnt/hd/doc/FAQ/html/basic-defs.html" ->
"basic-defs.en.html" failed: Operation not permitted (1)
rsync: symlink "/mnt/hd/doc/FAQ/html/choosing.html" ->
"choosing.en.html" failed: Operation not permitted (1)
rsync: symlink "/mnt/hd/doc/FAQ/html/compatibility.html" -> "compatibility.en.html" failed: Operation not permitted (1)
rsync: symlink "/mnt/hd/doc/FAQ/html/contributing.html" -> "contributing.en.html" failed: Operation not permitted (1)
rsync: symlink "/mnt/hd/doc/FAQ/html/customizing.html" -> "customizing.en.html" failed: Operation not permitted (1)
rsync: symlink "/mnt/hd/doc/FAQ/html/faqinfo.html" -> "faqinfo.en.html" failed: Operation not permitted (1)
rsync: symlink "/mnt/hd/doc/FAQ/html/ftparchives.html" -> "ftparchives.en.html" failed: Operation not permitted (1)
rsync: symlink "/mnt/hd/doc/FAQ/html/getting-debian.html" -> "getting-debian.en.html" failed: Operation not permitted (1)
rsync: symlink "/mnt/hd/doc/FAQ/html/index.html" -> "index.en.html"
failed: Operation not permitted (1)
rsync: symlink "/mnt/hd/doc/FAQ/html/kernel.html" -> "kernel.en.html"
failed: Operation not permitted (1)
rsync: symlink "/mnt/hd/doc/FAQ/html/nextrelease.html" -> "nextrelease.en.html" failed: Operation not permitted (1)
rsync: symlink "/mnt/hd/doc/FAQ/html/pkg-basics.html" ->
"pkg-basics.en.html" failed: Operation not permitted (1)
rsync: symlink "/mnt/hd/doc/FAQ/html/pkgtools.html" ->
"pkgtools.en.html" failed: Operation not permitted (1)
rsync: symlink "/mnt/hd/doc/FAQ/html/redistributing.html" -> "redistributing.en.html" failed: Operation not permitted (1)
rsync: symlink "/mnt/hd/doc/FAQ/html/software.html" ->
"software.en.html" failed: Operation not permitted (1)
rsync: symlink "/mnt/hd/doc/FAQ/html/support.html" -> "support.en.html" failed: Operation not permitted (1)
rsync: symlink "/mnt/hd/doc/FAQ/html/uptodate.html" ->
"uptodate.en.html" failed: Operation not permitted (1)
rsync: symlink "/mnt/hd/firmware/firmware-linux-free_20200122-1_all.deb"

"../pool/main/f/firmware-free/firmware-linux-free_20200122-1_all.deb"

failed: Operation not permitted (1)
.disk/
.disk/base_components
.disk/base_installable
.disk/cd_type
.disk/info
.disk/mkisofs
.disk/udeb_include
EFI/
EFI/boot/
EFI/boot/bootx64.efi

(...)

pool/main/x/xauth/xauth_1.0.10-1_amd64.deb
pool/main/x/xfsprogs/ pool/main/x/xfsprogs/xfsprogs-udeb_5.6.0-1+b2_amd64.udeb pool/main/x/xfsprogs/xfsprogs_5.6.0-1+b2_amd64.deb pool/main/x/xkeyboard-config/ pool/main/x/xkeyboard-config/xkb-data_2.29-2_all.deb pool/main/x/xserver-xorg-input-libinput/ pool/main/x/xserver-xorg-input-libinput/xserver-xorg-input-libinput-udeb_0.30.0-1_amd64.udeb
pool/main/x/xxhash/
pool/main/x/xxhash/libxxhash0_0.8.0-1_amd64.deb
pool/main/x/xz-utils/
pool/main/x/xz-utils/liblzma5_5.2.5-1.0_amd64.deb pool/main/x/xz-utils/xz-utils_5.2.5-1.0_amd64.deb
pool/main/z/
pool/main/z/zlib/
pool/main/z/zlib/zlib1g-udeb_1.2.11.dfsg-2_amd64.udeb pool/main/z/zlib/zlib1g_1.2.11.dfsg-2_amd64.deb
tools/
tools/loadlin.exe
tools/loadlin.txt

sent 434,994,400 bytes received 26,184 bytes 17,755,942.20 bytes/sec
total size is 434,798,648 speedup is 1.00
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1207) [sender=3.1.3]
root@nano:/mnt/ssd# umount /mnt/hd
root@nano:/mnt/ssd#

---------------------------------------------------------------------

Then when booting the media on an intel NUC x86_64 PC (in UEFI mode) and after selecting the language, you *will* run into the following error:

---------------------------------------------------------------------

[!!] Detect and mount installation media

No device for installation media was detected.

You may need to load additional drivers from removable media, such as
a driver floppy or a USB stick. If you have these available now,
insert the media, and continue. Otherwise, you will be given the
option to manually select some modules.

Load drivers from removable media?

<Yes> <No>

---------------------------------------------------------------------

Again, this is something I have been able to replicate using the latest, using all the steps highlighted above just a few minutes ago.

Now, your report that you are not seeing this kind of issue (which we
have additional confirmation of, at least for Raspberry Pi 4 Debian installation) made me dig a little further as to whether this issue is
as universal as I initially was led to believe, or if there might be an environmental component to it. And after further testing, I have found
that this seems to only affect UAS devices. For instance, I can validate
that the following UAS device (Mushkin Ventura Ultra USB 3.0 120 GB)
always produce the installation media detection issue:

---------------------------------------------------------------------

root@nano:/mnt/ssd# dmesg
(...)
[549114.637578] usb 8-1: new SuperSpeed Gen 1 USB device number 19 using xhci-hcd
[549114.658815] usb 8-1: New USB device found, idVendor=174c,
idProduct=55aa, bcdDevice= 1.00
[549114.658837] usb 8-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[549114.658852] usb 8-1: Product: Ventura Ultra
[549114.658867] usb 8-1: Manufacturer: Mushkin
[549114.658881] usb 8-1: SerialNumber: 000000000025
[549114.666050] scsi host0: uas
[549114.668168] scsi 0:0:0:0: Direct-Access Mushkin Ventura Ultra
0 PQ: 0 ANSI: 6
[549114.670930] sd 0:0:0:0: Attached scsi generic sg0 type 0
[549145.389481] sd 0:0:0:0: tag#14 uas_eh_abort_handler 0 uas-tag 1
inflight: CMD IN
[549145.389487] sd 0:0:0:0: tag#14 CDB: opcode=0x12 12 01 00 00 40 00 [549145.409499] scsi host0: uas_eh_device_reset_handler start
[549145.537655] usb 8-1: reset SuperSpeed Gen 1 USB device number 19
using xhci-hcd
[549145.559210] scsi host0: uas_eh_device_reset_handler success [549145.565782] sd 0:0:0:0: [sda] 234441648 512-byte logical blocks:
(120 GB/112 GiB)
[549145.565871] sd 0:0:0:0: [sda] Write Protect is off
[549145.565874] sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00
[549145.566029] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[549145.566228] sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes [549145.608066] sda: sda1 sda2 sda3
[549145.610265] sd 0:0:0:0: [sda] Attached SCSI disk

---------------------------------------------------------------------

However, when testing with another UAS USB device I have (a SanDisk
Extreme 3.0 32 GB), the media detection script appears to behave as
expected.

So at least, this gives us a better idea of where the issue is likely to
lie (most likely the current media detection scripts treat UAS USB
devices differently from non UAS ones).

But if you do get your hands on a UAS device, you should find that the statement that "unmodified debian installer images, when copied to a USB stick via (unix) dd or cp, boot just fine in UEFI mode" is not entirely accurate...

Regards,

/Pete

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2021.01.11 01:38, Lou Poppler wrote:

This is radically different from what I suggested above.

You mentioned cp, which I interpreted as copying extracted ISO files
onto FAT, since this is the mode I explicitly mentioned in my initial reply.

Here is my experiment:
lwp@william:~/Downloads$   wget https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso
lwp@william:~/Downloads$   umount /dev/sdb1 lwp@william:~/Downloads$   sudo bash root@william:/home/lwp/Downloads#   cp debian-testing-amd64-netinst.iso /dev/sdb
root@william:/home/lwp/Downloads#    sync

At this point I moved the USB stick to a Toshiba amd64 laptop,
and booted with no problems into the installer.

Notice especially that I did *not* copy the installer .iso onto a partition of the USB stick,
I copied the image to the bare USB i.e. /dev/sdb _NOT_ /dev/sdb1

Which means that you are limiting ISOHybrid use to DD/byte-copy mode
only, which is precisely what I am trying to warn against relying solely on.

A *proper* ISOHybrid media should be able to be extracted to a FAT32
formatted partition and boot in UEFI mode.

If you don't see why supporting this mode is necessary (Again, DD
imaging doesn't work for everything, or isn't even desirable for
everything), then you are missing the points I made earlier. Especially,
some installations (e.g. Raspberry Pi) require the user to be able to
copy additional files as well as set the size and type of the partition,
or even the whole partition scheme, to something else than what the
creators of the media have hardcoded.

From talking with some of their maintainers, other distros (Arch,
Unbuntu) seem to understand that limiting the purpose of an ISOHybrid to
dd imaging only, as you appear to imply above, can be problematic, and
they are taking steps to ensure that they also support ISO file
extraction, and will continue to do so.

Moreover, the media detection scripts of Debian certainly have provision
for this mode of operation (For instance I have submitted bugfixes for
this, such as [1], that would be pointless for any other mode of operation).

So please be very mindful that, by assuming that DD imaging will be good
enough for everybody, you *are* breaking a mode of operations that some
Debian users actually rely on.

As I tried to explain previously, DD imaging of an ISOHybrid is not the one-size-fits-all that some people seem to believe it is. Considering
that ISOHybrid is mostly a hack to make two completely separate file
systems appear to coexist as one, it does come with constraints and limitations, and therefore, just like other distros appear to agree on,
I (and other users) do expect Debian to do what's necessary to ensure
that the mode of operation that consists of *extracting* the full
content of an ISO onto a FAT32 media, and booting it on an UEFI system,
does result in a media that can be used for Linux installation.

I would also invite folks here to be weary of having a Linux-centric
only view of how people "should" create their installation media,
because the whole point of an installer image is to make sure that the installation experience is comprehensive enough that it doesn't alienate
users, including ones not using Linux to create their installation
media. And I'm afraid that, currently, despite what a lot of Linux folks
appear to believe, forcing everyone into using byte copy to apply an
ISOHybrid image very much does so.

As such, if Debian decides that FAT32 file copy mode for UEFI is too
much of a hassle, even as it mostly works fine (or at least it used to)
and is needed to ensure that folks can install vanilla Debian on
Raspberry Pi's (again, byte copy of the ISO will not work), then I'll
have little choice but tell Pi users to switch to a distro that does
understand that putting all of one's eggs into the DD-imaging basket of ISOHybrid is not a good way to satisfy its userbase.

Here is what that USB stick looks like now:

Then let me highlight the various problematic elements:

root@william:/home/lwp/Downloads# fdisk /dev/sdb

Welcome to fdisk (util-linux 2.29.2).

Some people may want to create an installation media that doubles as the
target media, because it can make the installation process A LOT easier
on some UEFI platforms. And they might want to use GPT instead of MBR
then => problematic

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): p
Disk /dev/sdb: 14.3 GiB, 15376318464 bytes, 30031872 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x5c546723

Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 0 745471 745472 364M 0 Empty

Unmodifiable and unmountable partition => problematic

/dev/sdb2 3944 9863 5920 2.9M ef EFI (FAT-12/16/32)

Some mode of operations require the Debian installation files to reside
on the ESP, again to ensure a smooth installation experience => problematic

Windows users will see their media reduced to 2.9 MB and consider that
it has been improperly created => problematic

Now, if anyone wants to dispute that dd imaging only of ISOHybrid is problematic, or maintain that it is the better option always, then I
will strongly invite you to read [2] and [3], which are the procedure
for *vanilla* Debian installation on Raspberry Pi 4 and Pi 3. Feel free
to then explain how ditching the extraction of ISO files to an ESP, and
trying to use DD imaging mode, will make for a user experience that even
even comes close to the one described in these guides.

Or maybe Debian has little interest in ensuring that users of what has
to be one of the most popular platforms out there, can actually install
Debian on through a standard Debian installation ISO.

Regards,

/Pete

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967918
[2] https://www.raspberrypi.org/forums/viewtopic.php?f=50&t=282839
[3]
https://pete.akeo.ie/2019/07/installing-debian-arm64-on-raspberry-pi.html

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 2021-01-11 at 02:21 +0000, Pete Batard wrote:

On 2021.01.11 01:38, Lou Poppler wrote:

This is radically different from what I suggested above.

You mentioned cp, which I interpreted as copying extracted ISO files
onto FAT, since this is the mode I explicitly mentioned in my initial reply.

Here is my experiment:
lwp@william:~/Downloads$   wget https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso
lwp@william:~/Downloads$   umount /dev/sdb1 lwp@william:~/Downloads$   sudo bash root@william:/home/lwp/Downloads#   cp debian-testing-amd64-netinst.iso /dev/sdb
root@william:/home/lwp/Downloads#    sync

At this point I moved the USB stick to a Toshiba amd64 laptop,
and booted with no problems into the installer.

Notice especially that I did *not* copy the installer .iso onto a partition of the USB stick,
I copied the image to the bare USB i.e. /dev/sdb _NOT_ /dev/sdb1

Which means that you are limiting ISOHybrid use to DD/byte-copy mode
only, which is precisely what I am trying to warn against relying solely on.

A *proper* ISOHybrid media should be able to be extracted to a FAT32 formatted partition and boot in UEFI mode.

The media we are discussing, debian-testing-amd64-netinst.iso, as copied
to my USB stick and booted in BIOS mode on the Toshiba laptop, also boots
just fine on this dell amd64 box in UEFI mode.

I will stipulate that there may be other architectures or devices which do not work the same as amd64 desktops/laptops. However, in all the varieties of testing I have done on amd64 desktops/laptops, the direct byte-for-byte copying of the installation image onto the base of a USB stick works properly in both BIOS booting and UEFI booting. Perhaps more complicated schemes are needed
for other situations, I agree that is possible. I am only trying to explain why I always suggest to amd64 users, on the general #debian IRC channel, that they should directly copy the downloaded image to their USB stick with dd or cp (as you saw in my example previous) or with rufus's DD mode. In this standard situation, any other method of writing the USB stick causes hard to debug problems.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2021.01.11 03:42, Lou Poppler wrote:

On Mon, 2021-01-11 at 02:21 +0000, Pete Batard wrote:

On 2021.01.11 01:38, Lou Poppler wrote:

This is radically different from what I suggested above.

You mentioned cp, which I interpreted as copying extracted ISO files
onto FAT, since this is the mode I explicitly mentioned in my initial reply. >>

Here is my experiment:
lwp@william:~/Downloads$   wget https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso
lwp@william:~/Downloads$   umount /dev/sdb1
lwp@william:~/Downloads$   sudo bash
root@william:/home/lwp/Downloads#   cp debian-testing-amd64-netinst.iso /dev/sdb
root@william:/home/lwp/Downloads#    sync

At this point I moved the USB stick to a Toshiba amd64 laptop,
and booted with no problems into the installer.

Notice especially that I did *not* copy the installer .iso onto a partition of the USB stick,
I copied the image to the bare USB i.e. /dev/sdb _NOT_ /dev/sdb1

Which means that you are limiting ISOHybrid use to DD/byte-copy mode
only, which is precisely what I am trying to warn against relying solely on. >>
A *proper* ISOHybrid media should be able to be extracted to a FAT32
formatted partition and boot in UEFI mode.

The media we are discussing, debian-testing-amd64-netinst.iso, as copied
to my USB stick and booted in BIOS mode on the Toshiba laptop, also boots just fine on this dell amd64 box in UEFI mode.

I will stipulate that there may be other architectures or devices which do not
work the same as amd64 desktops/laptops.

Please bear in mind that my testing was for amd64 too.

While I mentioned Raspberry Pi, the UAS breakage I am seeing is not Pi
specific and amd64 is broken too.

However, in all the varieties of
testing I have done on amd64 desktops/laptops, the direct byte-for-byte copying
of the installation image onto the base of a USB stick works properly in both BIOS booting and UEFI booting. Perhaps more complicated schemes are needed for other situations, I agree that is possible. I am only trying to explain why I always suggest to amd64 users, on the general #debian IRC channel, that they should directly copy the downloaded image to their USB stick with dd or cp
(as you saw in my example previous) or with rufus's DD mode. In this standard
situation, any other method of writing the USB stick causes hard to debug problems.

I'm not disputing that having to support both of sector by sector copy
and file copy for bootable media creation creates more issues that just supporting one of those. Almost every distro I know of has to take some
extra steps to support both.

However, I will also point out the reality that working at the file
level is usually more convenient for users than working at the sector
level, especially on non Linux platform.

The UEFI committee actually recognized this, and decided to move the bootloading handling process at the file system level rather than at the
sector level, which *is* a great move for users trying to create UEFI
boot media (because they should then just be able to use file copy to
end up with something that boots).

However, my impression is that, through what appears to be over reliance
on ISOHybrid, some Linux maintainers appear to want to move in a
complete opposite direction, and insist that boot/installation media
should *only* be created through sector copy on account that it makes
their life more convenient, even if it ends up inconveniencing a non insignificant section of their (potential) user base.

As an aside, that's not to say that other OSes are not also going in the opposite direction that was introduced with UEFI, as I could point out
to Microsoft who decided to remove the convenience of being able to
access UEFI bootloaders at the file level, by preventing Windows from
being able to access ESPs altogether...

Thus, as Thomas points out, I am just trying to make sure that there
exists some balance here between "Thou shalt only use sector copy when
creating USB media from an ISOHybrid" and "Let's have Linux maintainers
support whatever crazy scheme people come up with from being able to
work with UEFI at the file system level".

I hope this position makes sense, and that we can work together to find
a common ground that will actually benefit most users (including, but
not being limited only to Raspberry Pi ones), especially as my
understanding is that Debian maintainers have strived to support FAT32
file copy install for UEFI, and that the few corner cases we find here
and there where it appears to fail shouldn't be that difficult to fix
once properly looked into (and I am planning to help with that effort).

Regards,

/Pete

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)