Like some previous Parallels users, I've had some problems with running Debian GNU/Linux as a guest OS. In all recent Parallels builds, booting into Debian (kernel 2.6.15+) results in the a kernel panic from the agpgart module (as seen in this post) . Previously, Debian would boot normally following the kernel panic, but more recently, it consistently hangs while loading cupsd. After a great deal of hassle, I found that cupsd was hanging while it tried to load a parallel port module. After renaming the agpgart.ko module file to prevent it from loading, cupsd started normally. I tried to prevent agpgart from loading during the boot process by adding it to a blacklist. In Debian, one can prevent modules from loading by creating a file in /etc/hotplug/blacklist.d/ and adding the module name to this file. Adding a line with "agpgart" to /etc/hotplug/blacklist.d/agpgart didn't prevent the kernel panic. Checking the /lib/modules/2.6.15/modules.dep, I found the intel-agp module depends on agpgart and it was the attempt to load this module that caused agpgart to load despite being blacklisted. I removed agpgart from the blacklist file and added intel-agp instead. This removed the kernel panic, agpgart loaded normally, cupsd didn't hang, and Debian booted normally. With regard to Ubuntu, I tried loading the live CD and experienced the same hang at "loading drivers" that other users have reported. After leaving the system loading for sometime, Ubuntu reports that /sbin/modprobe quits abnormally and then continues booting and hangs on loading cupsd. I suspect this behavior is due to the same issue I experience with Debian. I am less familiar with Ubuntu, but likely downloading the alternative installation CD and using that install process should allow one to blacklist intel-agp. I would be interested in feedback from Parallels developers as to why intel-agp might be causing issues. As reported by the thread referenced above, I did experience some relief in previous builds of Parallels by changing the amount of available RAM, but that has no longer prevented the intel-agp kernel panic recently. I hope this helps others who have had trouble running Debian. Jeremy
I think this is a wider kernel problem than with just Debian. I have SUSE 10.1 installed with the latest patches (2.6.16.21, I think) and have the same problem on boot up. Waiting a few minutes, the machine continues to boot up and everything else has behaved normally so far as I can tell. Next week, I'll try your suggested fix, though. Thanks for reporting your success.
I'm am trying to install Debian and getting the same agpgart error, but don't understand your fix. I am assuming you changed the iso image before installation, is this correct. If so, could you give me brief explanation of how you do this in OS X - I've tried several methods unsuccessfully.
Actually, I had already installed Debian successfully before running into the agpgart kernel panic, so I didn't need to modify the ISO before installation. If the installation can proceed to the point where you can attempt to boot into Debian, then you should be able to boot into single user mode from the grub menu and then blacklist intel-agp. Otherwise, try and install a minimal set of packages as you might be able to proceed with the installation even with the kernel panic.
That is limitation of linux kernel. Parallels emulates Intel i815 Solano chipset, that physically can't have more then 512 Mb of memory. But Parallels can provide to guest OS more then 512 Mb. Somebody from linux kernel team read Intel datasheet thoroughly and somewhere wrote code based on assumption that there can't be more that 512 Mb of physical memory. As a result - linux kernel crashes there successfully when it sees more memory. Also you can refer to that topic, there is the solution of that problem -
Same here, both with Parallels for Mac (build 1970) and Parallels Work Station for Linux: guest OS'es Debian Sid and Ubuntu Feisty show erratic behaviour --- sometimes booting OK, sometimes freezing with a whole slew of debug messages on account of the AGP problem. Now, in all of these cases I've managed to make the problem go away by blacklisting the intel-agp kernel module (which also prevents the agpgart module from loading). So far, so good... and the Linux guest OS'es seem to be running fine without the AGP feature. My question: why is there an AGP feature in the VM in the first place? Or is there a hidden performance penalty that I'm not yet aware of?
Ubuntu 6.10 Solution that allows me to use 1.5GB: sudo vi /etc/modprobe.d/blacklist add "blacklist intel-agp" somewhere in the file. That's a dash, not an underscore, btw. Reboot.