[SOLVED] Does FLEXlm still cause problems to Linux bootloaders?
Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Does FLEXlm still cause problems to Linux bootloaders?
I have a laptop with Windows 7 and Linux installed, and I might soon need some commercial Windows software released in 2015 that apparently uses FLEXlm for license checking.
Should I expect problems if I install this software? Is there a workaround for GRUB to prevent such problems before the installation of this software?
The software can be also DRM'ed by using a USB "hardlock" dongle and I'm going to do that. But I'm not sure if this FLEXlm thing is used with the dongle too.
I'm not familiar with this issue or the mechanism by which it causes problems, but unless it somehow hacks into the BIOS then surely you can get around the problem with a USB thumbdrive to boot up your Linux install. Basically, use something like "grub-install /dev/sdb" to install GRUB onto the MBR of the thumbdrive, and then remove the thumbdrive (if you're paranoid) when booting up into Windows.
I'm guessing that the fundamental problem is that FlexNet overwrites the bootloader with its own bootloader which does the license checkout or something. But it won't be able to overwrite a bootloader on a USB thumbdrive that isn't even plugged in. And so long as it leaves your ext4 linux partition(s) alone, /boot will still be okay (the GRUB bootloader points to the partition /boot is in to bring up the GRUB menu etc).
OTOH, if it hacks into the BIOS and locks it down in some way so it's impossible to boot from USB or CD or anything other than the internal hard drive? Okay, that's theoretically possible but it would be a nightmare to develop for every BIOS out there. And also, it would brick a ton of computers, which would make corporations avoid the product like the plague. Somehow, I doubt this is what FlexNet does.
I'm not familiar with this issue or the mechanism by which it causes problems, but unless it somehow hacks into the BIOS then surely you can get around the problem with a USB thumbdrive to boot up your Linux install. Basically, use something like "grub-install /dev/sdb" to install GRUB onto the MBR of the thumbdrive, and then remove the thumbdrive (if you're paranoid) when booting up into Windows.
I'm guessing that the fundamental problem is that FlexNet overwrites the bootloader with its own bootloader which does the license checkout or something. But it won't be able to overwrite a bootloader on a USB thumbdrive that isn't even plugged in. And so long as it leaves your ext4 linux partition(s) alone, /boot will still be okay (the GRUB bootloader points to the partition /boot is in to bring up the GRUB menu etc).
OTOH, if it hacks into the BIOS and locks it down in some way so it's impossible to boot from USB or CD or anything other than the internal hard drive? Okay, that's theoretically possible but it would be a nightmare to develop for every BIOS out there. And also, it would brick a ton of computers, which would make corporations avoid the product like the plague. Somehow, I doubt this is what FlexNet does.
Using USB stick for emergency booting sounds like a good idea. Thanks!
As far as I understand, the FlexNet/FLEXlm DRM system writes information to some hard disk sectors (at least sector 32 is a known place) that are assumed to be unused but are (sometimes?) used to store GRUB code. This can cause a warning during GRUB installation if this DRM system is already installed, or it may break GRUB if the DRM system is installed later.
For a MBR BIOS based system, Grub2 installs the core.img in the (supposedly) unused sectors following the MBR in the first "cylinder" (to use old terminology).
As does this licensing rubbish - Dell used to drop some tools there too.
gpt would solve the grub[2] issue (BIOS boot partition), not so sure about Win7 and Flexlm. You might need that external boot medium.
Well, if it were me, I would not use that software!
I've sold a lot of software over the past couple decades, and I quickly found out that "less is more" when it comes to license checks. You do have to have one, since (for example) governments aren't allowed to spend public money for something that can be obtained or run for free, but you do not want it to be onerous to your customer. I've elected not to buy a lot of software because it required a "dongle" or somesuch.
For a MBR BIOS based system, Grub2 installs the core.img in the (supposedly) unused sectors following the MBR in the first "cylinder" (to use old terminology).
As does this licensing rubbish - Dell used to drop some tools there too.
gpt would solve the grub[2] issue (BIOS boot partition), not so sure about Win7 and Flexlm. You might need that external boot medium.
Thanks for clarification.
Is it possible, in MBR BIOS systems, to install Grub2 to a partition in a way that it doesn't put stuff into the space between the MBR and the first partition?
While such behavior by a DRM system is bad, I do not consider it good by GRUB either. This is just my personal opinion.
Quote:
Originally Posted by sundialsvcs
Well, if it were me, I would not use that software!
I've sold a lot of software over the past couple decades, and I quickly found out that "less is more" when it comes to license checks. You do have to have one, since (for example) governments aren't allowed to spend public money for something that can be obtained or run for free, but you do not want it to be onerous to your customer. I've elected not to buy a lot of software because it required a "dongle" or somesuch.
I agree, but this software is provided by my employer that has a dongle license for it, for short-term use.
I just installed the software using a DRM dongle, and didn't notice any problems. Perhaps FLEXlm is not used when the dongle is used.
I created a USB stick for emergency booting before installation.
Can I virtualize your software, and how can that be done?
Tell them "it's the latest thing".
That's possible too but would they answer? Also, I don't know what version of FLEXlm would be used by this software.
I'll mark this as solved soon. But to benefit other users that come across this thread, it would be useful to know if the new versions of FLEXlm/FlexNet DRM system continue to use the hard disk sectors.
Is it possible, in MBR BIOS systems, to install Grub2 to a partition in a way that it doesn't put stuff into the space between the MBR and the first partition?
You can force grub to install to a partition - but then you would need to re-install the Win7 boot-loader to the MBR, then chain-load your Linux system - which would actually load grub. EasyBCD might be simplest. I have used it on Win7, but eventually discarded it in favour of grub in the MBR.
As the grub documentation states this is somewhat fragile as it relies on a (static) block list - updates/reinstall of grub could cause the file to move, and subsequent boots to fail.
You can force grub to install to a partition - but then you would need to re-install the Win7 boot-loader to the MBR, then chain-load your Linux system - which would actually load grub. EasyBCD might be simplest. I have used it on Win7, but eventually discarded it in favour of grub in the MBR.
As the grub documentation states this is somewhat fragile as it relies on a (static) block list - updates/reinstall of grub could cause the file to move, and subsequent boots to fail.
I see, thanks for the information.
Just out of curiosity: (Why) is the following scheme not possible:
Grub boot.img on MBR (nothing in the following free space) --> Grub on VBR/partition --> Chainload Windows on another partition if desired
I mark this as solved but information about the behavior of FLEXlm/FlexNet DRM software would still be useful for other users who find this thread.
It's just because GRUB has grown in size because of the capabilities required to hunt down and read the various possible /boot partition/volume/etc. The idea being, that using UUID is more robust and easier to troubleshoot/rescue/repair than creating and maintaining an alternative smaller bootloader which uses a static block list or something.
The thing is, maybe it's not that hard to make an alternative smaller bootloader. But if hardly anyone actually uses it, how do you ensure it actually works? Sometimes, an alternative option is just too much of a niche to be confident it is truly functional.
Personally, I'd rather just put the initial grub bootloader on a small USB thumbdrive (which can also be used as a dumb FAT32 data drive or it can hold an entire rescue OS or whatever). I'd value the simplicity and piece of mind, over doing some sort of clever hack.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.