Kernel 5.0.3

As I'm sure the Parallels Linux team is aware... New major kernel out. Tools will not build against it.

 

Hello Mark,
That's correct, the 5th kernel version is not currently supported in Parallels Desktop as it's been released not so long ago. No ETA so far, but our Development team is working on it.

 

Hey Parallel's folks,
Looking forward to get this fix. Every year, same story.
Last year you took 36 days to release a fix for kernel 4.15 on Ubuntu 18.04 LTS. How long will it take this year?
Thanks

 

The only module that is failing with the latest Parallels Tools (14.1.3) is prl_fs and the fix is trivial:

Code:

diff -puNr parallels.orig/prl_fs/SharedFolders/Guest/Linux/prl_fs/super.c parallels/prl_fs/SharedFolders/Guest/Linux/prl_fs/super.c
--- parallels.orig/prl_fs/SharedFolders/Guest/Linux/prl_fs/super.c	2018-09-07 13:15:08.000000000 +0000
+++ parallels/prl_fs/SharedFolders/Guest/Linux/prl_fs/super.c	2019-04-02 06:45:15.675125322 +0000
@@ -116,11 +116,11 @@ static int prlfs_remount(struct super_bl
 {
 	int ret = 0;
 	DPRINTK("ENTER\n");
-	if ( (!((*flags) & MS_RDONLY) && PRLFS_SB(sb)->readonly) ||
-	       ((*flags) & MS_MANDLOCK) )
+	if ( (!((*flags) & SB_RDONLY) && PRLFS_SB(sb)->readonly) ||
+	       ((*flags) & SB_MANDLOCK) )
 			ret = -EINVAL;
 
-	*flags |= MS_SYNCHRONOUS; /* silently don't drop sync flag */
+	*flags |= SB_SYNCHRONOUS; /* silently don't drop sync flag */
 	DPRINTK("EXIT returning %d\n", ret);
 	return ret;
 }
@@ -270,7 +270,7 @@ static int prlfs_fill_super(struct super
 	sb->s_maxbytes = MAX_LFS_FILESIZE;
 	sb->s_blocksize = PAGE_SIZE;
 	sb->s_blocksize_bits = PAGE_SHIFT;
-	sb->s_flags |= MS_NOATIME | MS_SYNCHRONOUS;
+	sb->s_flags |= SB_NOATIME | SB_SYNCHRONOUS;
 	sb->s_magic = PRLFS_MAGIC;
 	sb->s_op = &prlfs_super_ops;
 	PRLFS_ALLOC_SB_INFO(sb);

 

Thanks, (GalaxyMaster). I was able to update my Fedora 28 VM to the latest kernel (5.0.7) and reinstall the Parallels Tools with those changes. I had previously blocked the kernel updates to avoid problems. After taking a snapshot, I'm trying to upgrade to Fedora 29 now to see if that works with your fix.

Edited: The VM won't boot past a black screen after the Fedora 29 upgrade. I've tried it a couple of different ways.
Edited: I was also able to install Ubuntu 19.04 beta with kernel 5.0.0 and install the Tools using your fix, after which I was able to upgrade an existing customized Ubuntu 18.10 VM to 19.04 beta and reinstall the Tools. When I tried after its initial release, the Tools wouldn't install under 19.04.

 

@jhfenton, the black screen has nothing to do with Parallels Guest Tools, JFYI. The reason is that the VM is supposed to work even without Guest Tools (you may lack networking capability (no prl_vmnet), there will be no shared folders (no prl_fs)), but other than this it should work.

I am running quite a few "unsupported" VMs which do not have any knowledge of being run under Parallels Desktop. When I start to investigate a boot up issue -- the first question is usually: does OS get any control at all? E.g. do I see the bootloader screen? If yes, then the issue is with the startup sequence. I usually enter the bootloader and try to boot the minimal version of the OS (e.g. on Linux it would be passing "init=/bin/bash" to the kernel command line). If it boots and I can see the prompt, then I start to analyse the initialisation sequence of the chose OS (e.g. will look into "journalctl -b -1" if the system is systemd-based), etc.

Hope this helps.

 

just seeing this now... apparently got no notification this convo continued.
going to add the fix later.

edit: love it when people get the great idea of randomly making arbitrary flags name-conform to the module they exist in (e.g., MS_ to SB_). actually, I'm pretty sure there was a good ocd-ish reason for it.

 

For those not familiar with the process...
1. while still under kernel 4.20.16 (or other 4.x.x), mount the virtual Tools CD ISO in Parallels (prl_tools_lin.iso) and copied it into a directory called tools_cd
2. make everything under tools_cd writable (chmod -R +w .)
3. cd into kmods and untar the tools file (tar -zcvpf prl_mod.tar.gz)
4. cd to prl_fs/SharedFolders/Guest/Linux/prl_fs (cd prl_fs/SharedFolders/Guest/Linux/prl_fs)
5. edit super.c by copying/pasting the offending 'MS_' lines shown in the diff and prefacing each with macros to allow rebuilding under the current kernel (note that there are three such sections in the diff above, this is just the first):
#if LINUX_VERSION_CODE < KERNEL_VERSION(5,0,0)
if ( (!((*flags) & MS_RDONLY) && PRLFS_SB(sb)->readonly) ||
((*flags) & MS_MANDLOCK) )
#else
if ( (!((*flags) & SB_RDONLY) && PRLFS_SB(sb)->readonly) ||
((*flags) & SB_MANDLOCK) )
#endif
6. cd back up to the kmods directory and delete the current prl_mod.tar.gz (rm -rf prl_mod.tar.gz)
7. re-tar/gz the edits into a new one (tar -zcvpf prl_mod.tar.gz .)
8. cd up a level (cd ..) and re-run the installer *as an upgrade* (./install). You can also do the Remove, reboot, remember to enter the directory and run the install, but that's a few extra time-consuming steps.
9. when done, reboot the VM back into the same kernel as before, then upgrade the kernel using dnf (or other). In my case I had to remember to comment out the exclude line in /etc/dnf/dnf.conf first. As the new kernel is installed, it should automatically rebuild Tools in the background.
10. Reboot the VM again into the new kernel, everything should work. Can now reset Grub2 to use the first kernel listed (grub2-set-default 0), unmount the Tools image, and delete the tools_cd directory as cleanup, if needed.

Currently running on 5.0.7... Cheers @GalaxyMaster for tracking down the fix.

 

Thanks Mark, that's work

super.c:

Part one:
static int prlfs_remount(struct super_block *sb, int *flags, char *data)
{
#if LINUX_VERSION_CODE < KERNEL_VERSION(5,0,0)
int ret = 0;
DPRINTK("ENTER\n");
if ( (!((*flags) & MS_RDONLY) && PRLFS_SB(sb)->readonly) ||
((*flags) & MS_MANDLOCK) )
ret = -EINVAL;

*flags |= MS_SYNCHRONOUS; /* silently don't drop sync flag */
DPRINTK("EXIT returning %d\n", ret);
return ret;
#else
int ret = 0;
DPRINTK("ENTER\n");
if ( (!((*flags) & SB_RDONLY) && PRLFS_SB(sb)->readonly) ||
((*flags) & SB_MANDLOCK) )
ret = -EINVAL;

*flags |= SB_SYNCHRONOUS; /* silently don't drop sync flag */
DPRINTK("EXIT returning %d\n", ret);
return ret;
#endif
}

Part two:
static int prlfs_fill_super(struct super_block *sb, void *data, int silent)
{
struct inode * inode;
struct prlfs_sb_info *prlfs_sb;
int ret = 0;

DPRINTK("ENTER\n");
sb->s_maxbytes = MAX_LFS_FILESIZE;
sb->s_blocksize = PAGE_SIZE;
sb->s_blocksize_bits = PAGE_SHIFT;
#if LINUX_VERSION_CODE < KERNEL_VERSION(5,0,0)
sb->s_flags |= MS_NOATIME | MS_SYNCHRONOUS;
#else
sb->s_flags |= S_NOATIME | SB_SYNCHRONOUS;
#endif
sb->s_magic = PRLFS_MAGIC;
sb->s_op = &prlfs_super_ops;
PRLFS_ALLOC_SB_INFO(sb);
prlfs_sb = PRLFS_SB(sb);
if (prlfs_sb == NULL) {
ret = -ENOMEM;
goto out;
}
memset(prlfs_sb, 0, sizeof(struct prlfs_sb_info));
prlfs_sb->pdev = tg_dev;
ret = prlfs_parse_mount_options(data, prlfs_sb);
if (ret < 0)
goto out_free;

ret = get_sf_id(tg_dev, prlfs_sb->name);
if (ret < 0)
goto out_free;
prlfs_sb->sfid = ret;
ret = prlfs_bdi_init_and_register(sb, prlfs_sb);
if (ret)
goto out_bdi;

DPRINTK("share=%s id=%u\n", prlfs_sb->name, prlfs_sb->sfid);

inode = prlfs_iget(sb, PRLFS_ROOT_INO);
if(!inode) {
ret = -ENOMEM;
goto out_bdi;
}
#if LINUX_VERSION_CODE >= KERNEL_VERSION(3,4,0)
sb->s_root = d_make_root(inode);
#else
sb->s_root = d_alloc_root(inode);
#endif
if (!sb->s_root) {
ret = -ENOMEM;
goto out_iput;
}
out:
DPRINTK("EXIT returning %d\n", ret);
return ret;

out_iput:
iput(inode);
out_bdi:
prlfs_bdi_destroy(&prlfs_sb->bdi);
out_free:
kfree(prlfs_sb);
goto out;
}

Point 9 and 10 not needed by Ubuntu 19.04
I hope that there will be an update soon because of the new kernel of Linux.

 

Ctr+tab for switching apps doesn't work on Ubuntu 19

 

Why is this a Kernel issue?

 

Alt+tab

Same on Ubuntu 18.10

 

Thank you guys!! This worked for me on 19.04. I just needed to search those 2 functions and add the pre-compile statements since the names have changed in kernel 5.0.

 

If this fix is so trivial, why haven't Parallels Devs released a tools update?

 

The fix provided by Mark Fine as amended by MichaelK41 worked for me on Fedora 30 running 5.0.13. Thanks, guys!

 

Sweet! After spending over 12 hours wrestling with both Ubuntu and Fedora, I've finally got them straightened out!

HUGE thanks to MichaelK41, Mark Fine, and ShawnC4!!!!!!! The combination of instructions provided by you three (and reading between the lines) worked perfectly!!! Ubuntu 19.04 and Fedora 30 are working perfectly now, AFAIK. Thanks!!!!

 

Can

Can you share the '.zip' of your parallels tools folder modified?

 

thanks, patch works perfectly fine on sabayon / 5.0.19 as well.

not so long ago? https://github.com/torvalds/linux/releases/tag/v5.0-rc1
especially with pro license lazy adoption is not what users should have to expect.

 

Especially since a quick-fix has already been handed to them on a silver platter. If us users can fix it, so can they. They just don't care one bit about their customers, after they have our money.