Bug#1024070: linux-image-6.0.0-3-amd64: IPv6 ProxyNDP stops responding to ND solicitation some time after startup
Hi Kevin, On Mon, Nov 21, 2022 at 04:49:16PM -0500, Kevin P. Fleming wrote: > On Sun, Nov 20, 2022, at 12:56, Kevin P. Fleming wrote: > > On Sun, Nov 20, 2022, at 08:38, Salvatore Bonaccorso wrote: > > > >> If that would be helpful, we have some instructions on "simple > >> patching and building" the kernel with a additional patches on top > >> here: > >> > >> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2 > > > > I found those via another path, and used them :-) Had a few little > > issues along the way: failing to set DEBFULLNAME produces a broken > > changelog entry so then the build won't run (and leaves the tree in a > > broken state as well). Once I solved that problem I was able to make > > packages, but the linux-headers-common package didn't get produced, so > > I had to use --force-depends-version when installing the packages > > (which I knew was safe since the headers had not changed). > > > > I now have the patched kernel in operation and should know whether the > > problem is solved in 24-48 hours. > > It's been more than 24 hours and connectivity is still in place, and > it never lasted this long without the patch. I'm comfortable saying > that this patch resolved the problem. Thanks for testing. I will try to make it included in the next unstable upload (waiting for 6.0.10 which should come around friday). Regards, Salvatore
Processed: Re: klibc-utils: klibc sh segfault on invalid substitutions
Processing commands for cont...@bugs.debian.org: > forwarded 1024735 > https://lists.zytor.com/archives/klibc/2022-November/004694.html Bug #1024735 [klibc-utils] klibc-utils: klibc sh segfault on invalid substitutions Set Bug forwarded-to-address to 'https://lists.zytor.com/archives/klibc/2022-November/004694.html'. > End of message, stopping processing here. Please contact me if you need assistance. -- 1024735: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024735 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1024735: klibc-utils: klibc sh segfault on invalid substitutions
Package: klibc-utils Version: 2.0.11-1 Severity: normal Tags: upstream Hey there. There’s a bug in ash-bashed shells, including the one shipped with klibc. The original variant is described here (for dash): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024635 respectively https://lore.kernel.org/dash/b2e298215b3d51d8284296484caa138faddaa0e4.ca...@scientia.org/ Apparently BusyBox’ sh (also ash based) doesn't segfault on the example I've found above. But Harald van Dijk was able to create an example where BusyBox’ sh segfaults, too, reported: http://lists.busybox.net/pipermail/busybox/2022-November/090036.html klibc’s sh segfaults in BOTH cases. I'll also post this to the upstream mailing list and set it as forwarded here afterwards. Thanks, Chris.
Upcoming stable point release (11.6)
Hi, The next point release for "bullseye" (11.6) is scheduled for Saturday, December 17th. Processing of new uploads into bullseye-proposed-updates will be frozen during the preceding weekend. Regards, Adam
Bug#1024718: linux: Samsung PM9B1 NVMe fails changes NID when resuming from sleep
Hi Stuart, Thanks for the report! On Wed, Nov 23, 2022 at 06:31:48PM +, Stuart Hayhurst wrote: > Source: linux > Version: 5.19.6-1 > Severity: important > Tags: patch upstream > X-Debbugs-Cc: stuart.a.hayhu...@gmail.com > > Dear Maintainer, > > The Samsung PM9B1 misreports its NID when resuming from sleep, > causing the root filesystem to be unmounted, and the system left in > an unstable state. Mostly this results in the device crashing, but > if the device somehow continues running, it's incredibly unstable, > where basically nothing works. It's an OEM drive found in some newer > laptops (like my Lenovo Yoga 7 Gen 7) > There's a bug report and patch upstream for this, but personally I > think it might be a good idea to include it in Debian until it's > accepted, as machines with this drive are near-unusable. > Upstream issue: > https://lore.kernel.org/all/20221116171727.4083-1-...@augustwikerfors.se/ > I've tested the patch against the current Debian 6.1-rc5 kernel on > my laptop, and this fixes the problem without any other issues. On the other hand, we only should include it once we are fairly confident that upstream accepts the fix and will include. Can you ping this bug once upstream maintainers have acked the change and queued it? If you have tested the patch, then you can as well reply to the thread mentioning you sucessfully tested the patch adding a Tested-by tag. Regards, Salvatore
Processed: tagging 1024718
Processing commands for cont...@bugs.debian.org: > tags 1024718 + moreinfo Bug #1024718 [src:linux] linux: Samsung PM9B1 NVMe fails changes NID when resuming from sleep Added tag(s) moreinfo. > thanks Stopping processing here. Please contact me if you need assistance. -- 1024718: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024718 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: bug 1024718 is forwarded to https://lore.kernel.org/all/20221116171727.4083-1-...@augustwikerfors.se/
Processing commands for cont...@bugs.debian.org: > forwarded 1024718 > https://lore.kernel.org/all/20221116171727.4083-1-...@augustwikerfors.se/ Bug #1024718 [src:linux] linux: Samsung PM9B1 NVMe fails changes NID when resuming from sleep Set Bug forwarded-to-address to 'https://lore.kernel.org/all/20221116171727.4083-1-...@augustwikerfors.se/'. > thanks Stopping processing here. Please contact me if you need assistance. -- 1024718: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024718 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: unarchiving 989040, forcibly merging 989040 1024697
Processing commands for cont...@bugs.debian.org:
> unarchive 989040
Bug #989040 {Done: Bastian Blank } [src:linux]
linux-image-5.10.0-6-amd64: Missing CONFIG_AMD_MEM_ENCRYPT in kernel config
makes SEV booting impossible
Bug #959069 {Done: Bastian Blank } [src:linux]
linux-image-5.5.0-2-amd64 won't boot in a AMD SEV Virtual Machine
Bug #983586 {Done: Bastian Blank } [src:linux]
linux-image-5.10.0-3-amd64: Please configure kernel with
CONFIG_AMD_MEM_ENCRYPT=y
Bug #987607 {Done: Bastian Blank } [src:linux]
linux-image-5.10.0-5-cloud-amd64: Configure SEV-enabled Debian 11 release
Unarchived Bug 989040
Unarchived Bug 959069
Unarchived Bug 983586
Unarchived Bug 987607
> forcemerge 989040 1024697
Bug #989040 {Done: Bastian Blank } [src:linux]
linux-image-5.10.0-6-amd64: Missing CONFIG_AMD_MEM_ENCRYPT in kernel config
makes SEV booting impossible
Bug #959069 {Done: Bastian Blank } [src:linux]
linux-image-5.5.0-2-amd64 won't boot in a AMD SEV Virtual Machine
Bug #983586 {Done: Bastian Blank } [src:linux]
linux-image-5.10.0-3-amd64: Please configure kernel with
CONFIG_AMD_MEM_ENCRYPT=y
Bug #987607 {Done: Bastian Blank } [src:linux]
linux-image-5.10.0-5-cloud-amd64: Configure SEV-enabled Debian 11 release
Bug #959069 {Done: Bastian Blank } [src:linux]
linux-image-5.5.0-2-amd64 won't boot in a AMD SEV Virtual Machine
Marked as found in versions linux/5.10.149-2.
Marked as found in versions linux/5.10.149-2.
Marked as found in versions linux/5.10.149-2.
Marked as found in versions linux/5.10.149-2.
Bug #1024697 [src:linux] linux-image-5.10.0-19-cloud-amd64: Please backport fix
for Bug #989040 : Missing CONFIG_AMD_MEM_ENCRYPT in kernel
Severity set to 'normal' from 'important'
Marked Bug as done
Marked as fixed in versions linux/5.13.9-1~exp1.
Marked as found in versions linux/5.10.13-1, linux/5.10.28-1, and
linux/5.5.17-1.
Bug #983586 {Done: Bastian Blank } [src:linux]
linux-image-5.10.0-3-amd64: Please configure kernel with
CONFIG_AMD_MEM_ENCRYPT=y
Bug #987607 {Done: Bastian Blank } [src:linux]
linux-image-5.10.0-5-cloud-amd64: Configure SEV-enabled Debian 11 release
Merged 959069 983586 987607 989040 1024697
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
1024697: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024697
959069: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959069
983586: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983586
987607: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987607
989040: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989040
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#1024718: linux: Samsung PM9B1 NVMe fails changes NID when resuming from sleep
Source: linux Version: 5.19.6-1 Severity: important Tags: patch upstream X-Debbugs-Cc: stuart.a.hayhu...@gmail.com Dear Maintainer, The Samsung PM9B1 misreports its NID when resuming from sleep, causing the root filesystem to be unmounted, and the system left in an unstable state. Mostly this results in the device crashing, but if the device somehow continues running, it's incredibly unstable, where basically nothing works. It's an OEM drive found in some newer laptops (like my Lenovo Yoga 7 Gen 7) There's a bug report and patch upstream for this, but personally I think it might be a good idea to include it in Debian until it's accepted, as machines with this drive are near-unusable. Upstream issue: https://lore.kernel.org/all/20221116171727.4083-1-...@augustwikerfors.se/ I've tested the patch against the current Debian 6.1-rc5 kernel on my laptop, and this fixes the problem without any other issues. Thanks :) -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-4-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1008972: (no subject)
Now I tried out the version from bullseye-backports, this did not improve anything significant. I can't try the unstable version here.
Bug#1008972: firmware-iwlwifi: iwlwifi reports errors while shutdown computer
Now I tried out the version from bullseye-backports, this did not improve anything significant. I can't try the unstable version here. On Sat, 29 Oct 2022 01:20:55 +0200 Diederik de Haas wrote: > Control: tag -1 moreinfo > > On Tuesday, 5 April 2022 13:11:14 CEST dasebastian wrote: > > Package: firmware-iwlwifi > > Version: 20210315-3 > > > > after updating my system to bullseye, I mostly always get a lot of > > errors when shuting down the computer (if I was logged in into a > > wireless network). Things like: > > > > [ 536.451518] iwlwifi :03:00.0: Error sending > > REPLY_SCAN_ABORT_CMD: time out after 2000ms. [ 536.451668] iwlwifi > > :03:00.0: Current CMD queue read_ptr 28 write_ptr 29 [ > > 536.699549] iwlwifi :03:00.0: Loaded firmware version: > > 18.168.6.1 6000g2a-6.ucode > > > > -- System Information: > > Debian Release: 11.3 > > APT prefers stable-updates > > APT policy: (500, 'stable-updates'), (500, 'stable-security'), > > (500, 'stable') Architecture: amd64 (x86_64) > > Stable backports has version 20210818-1~bpo11+1, could you try and > report back whether that improves/fixes your issue? > > Unstable recently got version 20220913-1 and if the above version > didn't fix it, it would be useful to know whether the latest version > does.
Bug#1024697: linux-image-5.10.0-19-cloud-amd64: Please backport fix for Bug #989040 : Missing CONFIG_AMD_MEM_ENCRYPT in kernel
Package: src:linux Version: 5.10.149-2 Severity: important X-Debbugs-Cc: lbouch...@scaleway.com Dear Kernel team, A fix for bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989040 is included in kernel 5.13 but still not available for the stable kernel. Could you please backport the fix for that bug into the stable 5.10 kernel so it becomes available in a standard Debian Bullseye installation. Without this fix, Debian Bullseye is unbootable in a virtual machine which uses Secure Enhanced Virtualization (SEV). The fix is the enablement of the CONFIG_AMD_MEM_ENCRYPT configuration option. Kind regards, ... Louis Bouchard -- Package-specific info: ** Version: Linux version 5.10.0-19-cloud-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.149-2 (2022-10-21) ** Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-19-cloud-amd64 root=UUID=25db7b8b-fbf8-47bd-b3c6-21fcf4de5f22 ro console=tty0 console=ttyS0,115200 earlyprintk=ttyS0,115200 consoleblank=0 ** Not tainted ** Kernel log: [1.808563] systemd[1]: Created slice system-systemd\x2dgrowfs.slice. [1.810794] systemd[1]: Created slice User and Session Slice. [1.812361] systemd[1]: Started Dispatch Password Requests to Console Directory Watch. [1.814189] systemd[1]: Started Forward Password Requests to Wall Directory Watch. [1.816108] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point. [1.818610] systemd[1]: Reached target Local Encrypted Volumes. [1.820342] systemd[1]: Reached target Paths. [1.821643] systemd[1]: Reached target Remote File Systems. [1.823172] systemd[1]: Reached target Slices. [1.824216] systemd[1]: Reached target Swap. [1.825333] systemd[1]: Reached target System Time Set. [1.826843] systemd[1]: Listening on Syslog Socket. [1.827821] systemd[1]: Listening on fsck to fsckd communication Socket. [1.829095] systemd[1]: Listening on initctl Compatibility Named Pipe. [1.830420] systemd[1]: Listening on Journal Audit Socket. [1.831536] systemd[1]: Listening on Journal Socket (/dev/log). [1.832700] systemd[1]: Listening on Journal Socket. [1.833727] systemd[1]: Listening on udev Control Socket. [1.834743] systemd[1]: Listening on udev Kernel Socket. [1.836088] systemd[1]: Mounting Huge Pages File System... [1.837358] systemd[1]: Mounting POSIX Message Queue File System... [1.838852] systemd[1]: Mounting Kernel Debug File System... [1.840422] systemd[1]: Mounting Kernel Trace File System... [1.841929] systemd[1]: Starting Create list of static device nodes for the current kernel... [1.843833] systemd[1]: Starting Load Kernel Module configfs... [1.845439] systemd[1]: Starting Load Kernel Module drm... [1.846871] systemd[1]: Starting Load Kernel Module fuse... [1.848423] systemd[1]: Started Nameserver information manager. [1.851234] systemd[1]: Condition check resulted in Set Up Additional Binary Formats being skipped. [1.852026] systemd[1]: Condition check resulted in File System Check on Root Device being skipped. [1.853998] systemd[1]: Starting Journal Service... [1.856523] systemd[1]: Starting Load Kernel Modules... [1.858154] systemd[1]: Starting Remount Root and Kernel File Systems... [1.859700] fuse: init (API version 7.32) [1.859981] systemd[1]: Starting Coldplug All udev Devices... [1.862214] systemd[1]: Mounted Huge Pages File System. [1.863194] systemd[1]: Mounted POSIX Message Queue File System. [1.864151] systemd[1]: Mounted Kernel Debug File System. [1.865057] systemd[1]: Mounted Kernel Trace File System. [1.866053] systemd[1]: Finished Create list of static device nodes for the current kernel. [1.867461] systemd[1]: modprobe@configfs.service: Succeeded. [1.868030] systemd[1]: Finished Load Kernel Module configfs. [1.869046] systemd[1]: modprobe@drm.service: Succeeded. [1.869620] systemd[1]: Finished Load Kernel Module drm. [1.870609] systemd[1]: modprobe@fuse.service: Succeeded. [1.871568] systemd[1]: Finished Load Kernel Module fuse. [1.873149] systemd[1]: Finished Load Kernel Modules. [1.875661] systemd[1]: Mounting FUSE Control File System... [1.877313] systemd[1]: Mounting Kernel Configuration File System... [1.879176] systemd[1]: Starting Apply Kernel Variables... [1.880825] systemd[1]: Mounted FUSE Control File System. [1.882063] systemd[1]: Mounted Kernel Configuration File System. [1.895464] systemd[1]: Finished Apply Kernel Variables. [1.897833] systemd[1]: Started Journal Service. [1.904694] EXT4-fs (sda1): re-mounted. Opts: discard,errors=remount-ro [1.917029] EXT4-fs (sda1): resizing filesystem from 491515 to 2408634 blocks [1.920492] systemd-journald[286]: Received client request to flush runtime journal. [1.989419] EXT4-fs (sda1):
Re: RFC: bootloader/initramfs protocol v2
Hi Bastian!
On Wed, Nov 23, 2022 at 08:53:10AM +0100, Bastian Blank wrote:
> On Mon, Nov 07, 2022 at 11:40:46AM +0100, Jörg Behrmann wrote:
> > On Tue, Nov 01, 2022 at 09:29:07PM +0100, Bastian Blank wrote:
> > > ## Prior works
> > >
> > > [..]
> > > - systemd install-kernel: only BLS as target, which nothing used by
> > > default in Debian can read
> > > [..]
> >
> > To maybe clarify this a bit: While kernel-install does target BLS
> > primarily, it
> > has support for differing layouts via the KERNEL_INSTALL_LAYOUT environment
> > variable (set via layout= in {/usr/lib,/etc}/kernel/install.conf).
>
> Okay. However no multi-selection.
>
I'm not sure I fully understand what you mean, but I think what you mean is,
that you would like to be be able to generate stuff in /boot for multiple
different values of KERNEL_INSTALL_LAYOUT, e.g. boot loader spec and something
else.
While the variable itself is single-valued, kernel-install can of course be run
multiple times for different values of KERNEL_INSTALL_LAYOUT or with different
configs wholesale (kernel-install reads environment variables from
/etc/kernel/install.conf, but this can be configured via the environment
variable KERNEL_INSTALL_CONF_ROOT).
I'd be grateful if you could flesh out the scenario for multi-selection a bit,
because the systems I think of will usually have a single way they are booted
and while being able to switch between different setups is important for
development work, I'm not sure whether this case common in production
deployments.
> > kernel-install scripts are also just that, executables with two CLI entry
> > points
> > (add and remove) and a set of fixed environment variables that they
> > receive. Currently all of this is written in POSIX shell (compatible with
> > dash) - they can be made to do everything.
>
> Add and remove are not enough for what I would like to have.
>
Fair enough. I'd be grateful, though, for a bit more information on what your
plan is, because, looking at the goals section of your initial mail, I think
that these could be achieved within this framework.
> And I'm
> really not in the mood to try that in POSIX shell.
>
Fair enough, I'm not a lover of POSIX shell myself. :) While kernel-install
itself is written in POSIX shell (for compatibility with dash, I think, because
it initially was bash and used bashisms and was ported later), the install
scripts can be whatever you want - even compiled binaries.
The API is described in the kernel-install manpage, although maybe a bit
haphazardly, and consists of arguments the scripts/binaries in
{/usr/lib,/etc}/install.d will be called with, environment variables they can
expect and exit codes that re understood.
> Is it even able to
> make sure stuff is actually written on the disk?
This question has multiple answers. I'm not sure whether anybody does this yet,
but you can add a script to run sync at the end and report an error if that was
unsuccessful. Also, kernel-install does provide a temporary staging directory,
so you can output everything there and have it copied to /boot at the end and
keep the interactions with dumb filesystems to a minimum.
> > kernel-install and BLS support a bit more than the machine ID here, The
> > relevant
> > keyword to look for in the kernel-install manpage and BLS is "entry-token".
> > This was added for golden master setups, because the machine ID will
> > probably
> > only generated on first boot, but the initrd would be generated beforehand.
>
> And I assume it got no way to migrate from an pre-defined entry-token to
> the machine ID later on, which would be kind of useful to convert a
> golden image into a real system where you can add unrelated systems
> later.
>
The entry-token is just the content of the /etc/kernel/entry-token file, so it
can be reset later and if no entry token exists it falls back to machine id,
IMAGE_ID and ID in the os-release file in that order.
best regards,
Jörg
Re: RFC: bootloader/initramfs protocol v2
Hi Luca On Sun, Nov 06, 2022 at 02:14:54PM +, Luca Boccassi wrote: > On Tue, 2022-11-01 at 21:29 +0100, Bastian Blank wrote: > > ## Goals > > > > - Setup complete boot entries from packaged and generated files > > - Support dumb file systems for /boot by default, so boot loaders can > > drop complex file system support. > > - Re-create stuff in /boot from scratch > > - Remove symlink handling from kernel package > > - Single entry point for packages and admins, aka no tool specific > > "update-initramfs" anymore > > Could you clarify what you mean by "single entry point" here? It's the > only point I can't quite decode. A trigger? You have one tool to call, not right now multiple (the kernel maintainer scripts do some, "update-initramfs" scribles to it as well). > I would like to suggestion this as an additional, explicit goal, rather > than implicit: > End result should be fully compatible with the BLS (for the readers: > https://uapi-group.org/specifications/specs/boot_loader_specification/ > ) Yes. We will need extensions, some may be incompatible as well. > > ## Open questions > > > > - How to select default entry if supported, just sort by version and > > use > > newest? This also works somewhat in BLS. > > Yes, we should follow BLS on this, so that end result is predictable, > well-defined and doesn't vary wildly from other distros. Okay. > In fact, if Grub can do UKIs, do we even need Type 1 entries (separate > textual config files) for anything at that point? grub needs to be able to read and disect UKI for non-EFI without loader code (aka for ppc, sparc, bios and xen). And we need a way to create them without the really heavy binutils. And for all the old bootloaders, we have no way to use UKI at all. So if we want to ship UKI in packages, we also need to be able to disect them in userspace. Can you currently create UKI with multiple multi-boot capable initrd attachments? For Xen. > > ### Distribution file system (/usr) > > > > * /usr/lib/boot/$package(_$modifier)/ > > * ./data: raw data for item > > * ./metadata: info about item in undetermined format > > What would 'metadata' be in this context? A description what it is. We might have raw kernel blobs for some architectures. We might have Xen kernels, which require a nested Linux. And all the information that need to go into the type 1 file and comes from the package, like version, name, architecture. Regards, Bastian -- She won' go Warp 7, Cap'n! The batteries are dead!
Re: RFC: bootloader/initramfs protocol v2
Hi Jörg
On Mon, Nov 07, 2022 at 11:40:46AM +0100, Jörg Behrmann wrote:
> On Tue, Nov 01, 2022 at 09:29:07PM +0100, Bastian Blank wrote:
> > ## Prior works
> >
> > [..]
> > - systemd install-kernel: only BLS as target, which nothing used by
> > default in Debian can read
> > [..]
>
> To maybe clarify this a bit: While kernel-install does target BLS primarily,
> it
> has support for differing layouts via the KERNEL_INSTALL_LAYOUT environment
> variable (set via layout= in {/usr/lib,/etc}/kernel/install.conf).
Okay. However no multi-selection.
> kernel-install scripts are also just that, executables with two CLI entry
> points
> (add and remove) and a set of fixed environment variables that they
> receive. Currently all of this is written in POSIX shell (compatible with
> dash) - they can be made to do everything.
Add and remove are not enough for what I would like to have. And I'm
really not in the mood to try that in POSIX shell. Is it even able to
make sure stuff is actually written on the disk?
> kernel-install and BLS support a bit more than the machine ID here, The
> relevant
> keyword to look for in the kernel-install manpage and BLS is "entry-token".
> This was added for golden master setups, because the machine ID will probably
> only generated on first boot, but the initrd would be generated beforehand.
And I assume it got no way to migrate from an pre-defined entry-token to
the machine ID later on, which would be kind of useful to convert a
golden image into a real system where you can add unrelated systems
later.
Bastian
--
Those who hate and fight must stop themselves -- otherwise it is not stopped.
-- Spock, "Day of the Dove", stardate unknown
