Symantec Ghost Console Client under Dosemu
Hello.
Quoted 1 line · [email protected] wrote:
1) The MAC address of seen by Ghost in DOS needs to be the same as the physical MAC address, and outgoing packets need to have the MAC address of the physical card.
This is possible, although in that mode dosemu will monopolize your NIC so that Linux will no longer use it. This also requires root. The setup for that is simple:
$_pktdriver=(on)
$_vnet=""
$_netdev="eth0"
Though right now the comments in the dosemu.conf do not suggest $_vnet can be set to "", it only says about "dosnet" and "tap". This needs to be fixed to avoid confusion.
Though keep in mind that Ghost under dosemu will see only the packet interface, not your card. Ghost supports the packet driver interface, so this should be not a problem.
Quoted 1 line
Dosnet, but this should probably be doable.
Forget about dosnet. It is going to be removed. If you want dosemu to cooperate with your linux box wrt networking, use TAP. In that case though the DOS box will have the different (virtual) MAC, not the real one.
Quoted 1 line
2) Ghost will probably need to be able just to access the hard drive directly
As you know, this is no longer supported.
Quoted 2 lines
I can't seem to find if this is possible in current versions in
the HOWTO, although I seem to have seen indications that this at least used to be possible in earlier versions.
So it was removed. Not really, just disabled in global.conf, AFAICS. You can easily get it back with a trivial hack in global.conf (or even without any hacks at all).
But I don't think it really had to be removed. People used it on their own risk, it worked for them, and suddenly it is not any more.
Of course it is horribly unsafe, but not so much when your drive is not mounted at all, and it was available only for root, and being root you can corrupt your drives if you want to. So the removal probably have to be reconsidered. And if you'll manage to get the positive results, that will probably be a good motivation.
Quoted 1 line
I'd also like to know if any of the components, specifically Dosnet
Forget it.
Quoted 2 lines
direct
hard disk access is known to be particularilly flaky.
To my own expirience (when it was still there) - it was not flakey. It was not perfect either (I had a few progs that worked with partition access, but not with wholedisk access), but it never, never ever costed me a single byte of lost info, even though I tried it with accessing the same space from within linux at the same time, and other weird things. And I have not seen any negative comments about it here either, although probably they took place before I subscribed. Yet I've seen (rightfull) complains when it was removed. This all doesn't look right to me. At least dosemu could check whether the drive is in use (any partition is mounted), and allow the access only if it is not. Or explicitly ask the confirmation for allowing it to corrupt the data...
Quoted 4 lines · Stas Sergeev
So it was removed. Not really, just disabled in global.conf, AFAICS. You can easily get it back with a trivial hack in global.conf (or even without any hacks at all).
you don't even need global.conf -- global.conf syntax also works in dosemu.conf.
$_hdimage = ""
disk {wholedisk "/dev/hda"}
in dosemu.conf (or root's ~/.dosemurc if root runs dosemu) does the job. Though I had to use $_vbootfloppy (a floppy image) to boot, since DOSEMU doesn't like GRUB in the MBR (tries to go to protected mode itself).
It was never really removed, just never supported in the new dosemu.conf syntax (Feb 98, 0.97.2, over two years before I was involved). But right now there isn't much of a reason anymore; as it used to be dosemu was suid-root by default and any user could get the wholedisk (depending on dosemu.users), now it solely depends on the permissions of /dev/hda.
So I'm not opposed to it, just too lazy to add the support to dosemu.conf ;)
Bart
Thanks to Stas Sergeev for the very helpful post, and to Bart Oldeman for the supplementary comments. Both posts have been very helpful.
Dosemu monopolising the network card as well as the hard drive will not be a problem, since the only thing needing those resources would be Ghost itself, which runs under Dosemu. So, as I see it there are no theoretical reasons why this won't work.
I'm going to try this as soon as possible. I'll see if I get the time to do it tomorrow -- and then I'll probably just launch a Knoppix CD or something and see if I can get Dosemu installed under that.
If results of that are favorable, I'm going to try running some different imaging tasks, and network operations, to see if it'll work.
If that in turn works, I'll start investigating the possibility of creating or modifying some form of custom Linux distribution to do what I want.
A few question marks still remain to be straightened though.
First of all, where can I find the DOS side of the packet driver? As I've understood it, there needs to be a EXE on the DOS side containing a packet driver for the particular network card. From the point of view of Ghost, I'll need some sort of packet driver for DOS in order for Ghost to see the emulated network card. Is this a specialized driver that the Dosemu project provides, and/or does Dosemu just emulate some popular network card, allowing me to use one of Ghost's supplied packet drivers?
Second, is there simple way to detect if a BAT file is running under Dosemu? One method that comes to mind would be if the DOS side of the packet driver produces useful return codes if not run under Dosemu. I need to make an ugly hack whereby the same partition is booted twice, once on the bare metal just to run Loadlin on the kernel, and the second time under Dosemu. This is because I don't want to step on how Ghost handles bootable flags and other doodads when invoked over the network. Best not to be looking for more trouble than I'm already in. :-) Suggestions on this point would be nice, but if nothing else, I should be able to pull this off using some hacks whereby control files are created, checked and destroyed -- but better ideas would be appreciated.
Signature · 1 line
Per von Zweigbergk <[email protected]>