WARNING - Zenworks PXE imaging in a netware environment may destroy your
linux boot loader under certain circumstances.

Novell say "to fix the incompatibility would require a redesign and this is
just not commercially viable"

If you use a linux machine with a combination of the grub boot loader and
certain linux filesystem types in the combination listed below and you
happen to have pxe boot on (which a lot of laptops default to having on, or
automatically gets enabled when using a docking station in some cases) the
preworx pxe boot code overwrites part of the partition table that isn't
necesserily its to overwrite and renders your machine unbootable.

Novell are saying that they don't use the preworks code in zen 7 and that it
is not commercially viable to get preworks to fix it or port their own zen 7
code back to the netware 6.5/zenworks 6.5 platform. So much for still
supporting netware eh!!!! Their suggested workarounds are that we should

a) turn off/block pxe boot on certain points - yeah right
b) dictate to everyone that visits our institution how they should
reconfigure their personal laptops to avoid this issue (like we are going to
screen every laptop that comes in here! checking whether they have pxe boot
enabled and which boot loader and linux file system they have!!!)
c) change our infrastructure to OES linux and zen 7! - so much for
supporting the current zenworks 6.5 and netware then - what do we pay
maintenance for?

I have another option d) FIX THE BUG IN THE CODE - they should never have
made an assumption that they are allowed to write to this area of the disk.
The way I see it should work is if somebody has installed Zen imaging on
their windows PC and it already has marked the image safe area of the disk,
then it is ok for the preworks code to write here - otherwise do not write
to this area of the disk as this machine has nothing to do with zenworks
imaging and should be left alone!!!!!

After some investigation by Novell, this is what they say happens. "when PXE
starts it writes hardware information in sector 16 on the harddisk. We use a
PXE solution from Preworks and they hard coded this functionality in their
code. This limitation is not with an ZDM 7 backend on Linux or ZLM 7 on
Linux. GRUB uses different loadstages 1, 1.5 and 2.

Some information about GRUB, an example with the Filesystemtype ReiserFS :-

When installing GRUB, it checks for the existence of the particular
(depending on the partition's file system) Stage 1.5 install file. If it
exists, then it uses a function called embed and installs stage 1.5 from (in
this case) the file "/boot/grub/reiserfs_stage1_5" to reserved space after
the boot sector and before the file system on the ReiserFS partition. It is
important to note that ReiserFS reserves 64 Kb before the file system for
this reason. JFS also reserves this space but Ext2 does not and so the stage
1.5 must be installed to the reserve space directly after the MBR (first 30
Kb (63 sectors)). This is why there are different stage1_5 files for
different file systems.

A workaround for the customer could be:

1.Use an file system type ReiserFS

2.Install grub without loadstage 1.5

3.Disable PXE on those workstations"

We believe this issue is caused by the Preworx DINIC.SYS file."

So over to you the community what do you think? should Novell support the
code and fix it regardless of any cost implications, as it is not on, to
leave their product trashing peoples machines over which I have no control.

Your comments please, also bear in mind that I only have the word of our uk
education Novell Support Provider that this is Novells' position, it may
only be coming from their helpdesk and may not actually reflect the policy
of Novell as a whole or their Zenworks team.

Nathan Lock