Courtesy of Prit! Copy these additional files from the PRO1000\NDIS5x\ folder of the driver software to your [IMAGEROOT]\i386 folder -
elc5132.sys
e1c5132.din
e1cmsg.dll
nicco2.dll
nicinstc.dll
e1c5132.inf
Not sure exactly which one makes it work ;-D
LongTom's Tech & Music
Teccy stuff - probably work related - I work as in tech support so I'll post anything useful my day to day work brings up! Do a lot of stuff like virus scanning, file recovery... a fair bit of linux geekery too! I mange my org's ageing RIS system as well & I'm getting better at hacking it around... Music production is my main thang but don't get nearly enough time for it! Almost always end up making techno / trancy stuff so I'll post some links to that here too...
Friday, 10 June 2011
Friday, 4 February 2011
For posterity... how to get fglrx / debian / ati working!
Re: FGLRX failing at DKMS
I've been having these same problems with the 2.26.32-xx-Generic kernels on Kubuntu 10.04 64-bit and I was just now able to get the fglrx module to build without having to downgrade kernels.
Here's what I did. Chances are some kernel developer will start yelling at me for doing this, but oh well.
As root, open up the file /usr/src/linux-headers-2.6.32-24-generic/arch/x86/include/asm/compat.h in a text editor, inserting your version of the kernel in place of mine. That directory should be correct for both 32-bit and 64-bit systems. Go to the very botton of the file; you'll see
.
Between that line and the curly brace ( } ) two lines above it, paste in the following:
.
(It isn't really necessary that the function go exactly where I said to put it, but this will make sure that you don't accidentally paste it into another function or something like that.)
Now save the file and try reinstalling the fglrx drivers. My xorg.conf file was messed up and causing problems for me, so check that before you restart X. With any luck, you should now be rolling in fglrx goodness!
I don't think that will hurt anything, but you can remove your changes to that file after you build the module if you want.
You may have noticed that the function I had you paste in looks very similar to another function in there called 'arch_compat_alloc_user_space'. As far as I can tell, they are exactly the same except for the name and parameter type (unsigned long). It appears that 'compat_alloc_user_space' was renamed to 'arch_compat_alloc_user_space' for just this version of the kernel, so really we just put the old one back for the ATI module builder to use. This shouldn't hurt anything since the contents of the two functions are identical.
Here's what I did. Chances are some kernel developer will start yelling at me for doing this, but oh well.
As root, open up the file /usr/src/linux-headers-2.6.32-24-generic/arch/x86/include/asm/compat.h in a text editor, inserting your version of the kernel in place of mine. That directory should be correct for both 32-bit and 64-bit systems. Go to the very botton of the file; you'll see
Code:
#endif /* _ASM_X86_COMPAT_H */
Between that line and the curly brace ( } ) two lines above it, paste in the following:
Code:
static inline void __user *compat_alloc_user_space(unsigned long len) { struct pt_regs *regs = task_pt_regs(current); return (void __user *)regs->sp - len; }
(It isn't really necessary that the function go exactly where I said to put it, but this will make sure that you don't accidentally paste it into another function or something like that.)
Now save the file and try reinstalling the fglrx drivers. My xorg.conf file was messed up and causing problems for me, so check that before you restart X. With any luck, you should now be rolling in fglrx goodness!
I don't think that will hurt anything, but you can remove your changes to that file after you build the module if you want.
You may have noticed that the function I had you paste in looks very similar to another function in there called 'arch_compat_alloc_user_space'. As far as I can tell, they are exactly the same except for the name and parameter type (unsigned long). It appears that 'compat_alloc_user_space' was renamed to 'arch_compat_alloc_user_space' for just this version of the kernel, so really we just put the old one back for the ATI module builder to use. This shouldn't hurt anything since the contents of the two functions are identical.
Thursday, 11 November 2010
vPro Woe
Soooo... vPro is a nice handy way to reboot & diagnose PC problems before the o/s loads... you can remote into the bios etc...
One problem if you need to use it to remote a PC into PXE boot (for RIS / WDS) is the lack of F12 passthrough! Suggested fixes from the msg boards suggest simply setting the client to one time boot to PXE then set the PXE server to auto it... not possible in all environments as you may have clients (like here) always going to PXE...
So we hack around it! Using rom-o-matic.com's PXE boot disk creator with custom script on the end -
ifstat
ifopen
dhcp net0
chain n12\i386\startrom.com << this points to a different dir on the RIS filesystem (standard would be OSChooser\i386\startrom.com) where startrom.n12 has been renamed to startrom.com (the standard way to get PXE clients to network boot automatically) *edit* Found out if you simply put the path as OSChooser\i386\startrom.n12 you won't need the extra directory...
So now you can remote the client (I'm using radmin viewer) & redirect to the boot image (iso) and voila! it "auto" F12's and you're into the OSChooser.
Now just need to fix the network driver conflict in the next phase!
One problem if you need to use it to remote a PC into PXE boot (for RIS / WDS) is the lack of F12 passthrough! Suggested fixes from the msg boards suggest simply setting the client to one time boot to PXE then set the PXE server to auto it... not possible in all environments as you may have clients (like here) always going to PXE...
So we hack around it! Using rom-o-matic.com's PXE boot disk creator with custom script on the end -
ifstat
ifopen
dhcp net0
chain n12\i386\startrom.com << this points to a different dir on the RIS filesystem (standard would be OSChooser\i386\startrom.com) where startrom.n12 has been renamed to startrom.com (the standard way to get PXE clients to network boot automatically) *edit* Found out if you simply put the path as OSChooser\i386\startrom.n12 you won't need the extra directory...
So now you can remote the client (I'm using radmin viewer) & redirect to the boot image (iso) and voila! it "auto" F12's and you're into the OSChooser.
Now just need to fix the network driver conflict in the next phase!
Friday, 22 October 2010
Grub / Chroot problems
"block device: Not found or not a block device." when trying to install GRUB whilst chrooted... run these commands before -
mount --bind /proc /mnt/sysimage/proc
mount --bind /dev /mnt/sysimage/dev
mount --bind /sys /mnt/sysimage/sys
Thanks novell :D
mount --bind /proc /mnt/sysimage/proc
mount --bind /dev /mnt/sysimage/dev
mount --bind /sys /mnt/sysimage/sys
Thanks novell :D
Monday, 20 September 2010
Sunday, 8 August 2010
Thursday, 5 August 2010
Running Linux Installers from Windows Remote Installation Service (RIS)
There may be a time when you need to use some ancient Windows software to deploy a Linux O/s... setting up a Linux PXE / TFTP system is no fun at all and far too obvious a solution! Anyway here's how to use RIS (WDS running in Legacy) to launch a Linux network install (or could be a LiveCD etc...)
RIS looks for a .sif file in your images folder, so make a new folder for your install then create a /i386/templates/pxelinux.sif file (you can call it whateveryoulike.sif) and it needs the following -
pxelinux.0 looks for a pxelinux.cfg directory which usually has a file "default" which is a plaintext file detailing the boot menu and pointing to the relevent initrd.img file you're trying to load... there will probably be one of these files in your linux distro's isolinux dir and you can mess around with it to give different boot options.
Anyway thats basically how it's done, information from a variety of sources and some trial and error!
RIS looks for a .sif file in your images folder, so make a new folder for your install then create a /i386/templates/pxelinux.sif file (you can call it whateveryoulike.sif) and it needs the following -
[OSChooser]
Description="Whatever You Are Installing"
Help="Linux install blah blah blah"
LaunchFile="%INSTALLPATH%\%MACHINETYPE%\templates\pxelinux.0"
ImageType=Flat
Version="1.00"Version can be whatever you like, as can the description and help. You need to copy pxelinux.0 from your distro to \templates and from there it basically runs the same as it would on a Linux PXE/TFTP server... so have a look at instructions on how to get that working from there.
pxelinux.0 looks for a pxelinux.cfg directory which usually has a file "default" which is a plaintext file detailing the boot menu and pointing to the relevent initrd.img file you're trying to load... there will probably be one of these files in your linux distro's isolinux dir and you can mess around with it to give different boot options.
Anyway thats basically how it's done, information from a variety of sources and some trial and error!
Subscribe to:
Posts (Atom)