Re: [Fwd: Re: Re: Third-Party Software Needs Non-Debian Format for Kernel Version]
What I'm wondering is whether I can get uname to return the desired format by somehow compiling a custom kernel. Yes you can, by getting the source code from kernel.org. If you simply copy the config from the Debians kernel, then IIRC # make-kpkg --initrd kernel-image kernel-headers won't use the Debians naming, but name the package and the output for uname -r and any string else as the original kernel.org name is. Thank you very much! That worked well and was easy! -- Thomas E. Vaughan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caao_ux-s-lz2rtcqmg1kjzdffzrmewogt7uwfyem1bpca03...@mail.gmail.com
Re: Re: Third-Party Software Needs Non-Debian Format for Kernel Version
Thomas Vaughan tevaug...@gmail.com writes: isn't supported per se. But when [the software], or the makefiles, parse the string 3.12-1-amd64 they don't get the expected result. If the uname -r were the string 3.12.9-1 then parsing it would yield the expected result. ---END QUOTE FROM VENDOR--- Is the reported kernel-version string, 3.12-1-amd64, something that I could change by compiling a custom kernel? Might a shell script that output the expected string work? An appropriately named shell script in the right place in the path might take care of uname(1), but I don't see how to take care of uname(2), the system call. When the vendor says that the software parses the string, I think that the software is calling uname(). So my question is whether there is a way by compiling a custom kernel for me to alter what the uname() system call reports. You can replace functions from dynamically linked libraries using LD_PRELOAD. Check using ldd on your third party binary to verify it is dynamically linked. A quick search found this fragment of code: http://www.technovelty.org/c/using-ld_preload-to-override-a-function.html. That example is replacing getpid with a function that calls the original getpid and prints a message, but you can use the same trick for uname and modify the utsname structure to taste before returning. There are restrictions on what you can LD_PRELOAD, which are covered in the manpage for ld.so(8). But as long as you satisfy those constraints, this should be significantly easier than building your own kernel. -- regards, kushal pgp77iOTL_sm5.pgp Description: PGP signature
Re: Third-Party Software Needs Non-Debian Format for Kernel Version
On 2014-02-22 00:20 +0100, Thomas Vaughan wrote: I have downloaded some proprietary software that I want to install onto a 64-bit Debian machine. The software is written for 64-bit linux, but the kernel version reported, for example, by uname (and perhaps by some system call that the compiled software uses) is not in a format that the software expects. ---BEGIN QUOTE FROM VENDOR--- Its not that 3.12-1-amd64 isn't supported per se. But when [the software], or the makefiles, parse the string 3.12-1-amd64 they don't get the expected result. If the uname -r were the string 3.12.9-1 then parsing it would yield the expected result. ---END QUOTE FROM VENDOR--- Is the reported kernel-version string, 3.12-1-amd64, something that I could change by compiling a custom kernel? You could do that, but I would first try to run the software under setarch x86_64 --uname-2.6 which should let it see a kernel version of 2.6.52-1-amd64. Cheers, Sven -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sirbblqc@turtle.gmx.de
Re: Third-Party Software Needs Non-Debian Format for Kernel Version
On Fri, 21 Feb 2014 22:58:40 -0500, Jerry Stuckle wrote: abiname shouldn't change should it? I wouldn't think so - but I also don't know. However, if you do change something basic like the kernel version, what else will it affect? You might get a kernel which will boot but nothing will run, for instance. When you install your custom kernel, make sure you keep an old kernel around, just in case. -- hendrik -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/leao5j$g51$3...@ger.gmane.org
Third-Party Software Needs Non-Debian Format for Kernel Version
I have downloaded some proprietary software that I want to install onto a 64-bit Debian machine. The software is written for 64-bit linux, but the kernel version reported, for example, by uname (and perhaps by some system call that the compiled software uses) is not in a format that the software expects. ---BEGIN QUOTE FROM VENDOR--- Its not that 3.12-1-amd64 isn't supported per se. But when [the software], or the makefiles, parse the string 3.12-1-amd64 they don't get the expected result. If the uname -r were the string 3.12.9-1 then parsing it would yield the expected result. ---END QUOTE FROM VENDOR--- Is the reported kernel-version string, 3.12-1-amd64, something that I could change by compiling a custom kernel? -- Thomas E. Vaughan
Re: Third-Party Software Needs Non-Debian Format for Kernel Version
On Feb 21, 2014, at 4:20 PM, Thomas Vaughan tevaug...@gmail.com wrote: isn't supported per se. But when [the software], or the makefiles, parse the string 3.12-1-amd64 they don't get the expected result. If the uname -r were the string 3.12.9-1 then parsing it would yield the expected result. ---END QUOTE FROM VENDOR--- Is the reported kernel-version string, 3.12-1-amd64, something that I could change by compiling a custom kernel? Might a shell script that output the expected string work? -- Glenn English -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/303a8294-5998-46d3-aebd-cab21fa97...@slsware.net
Re: Third-Party Software Needs Non-Debian Format for Kernel Version
Forwarded Message From: Ralf Mardorf To: debian-user@lists.debian.org Subject: Re: Third-Party Software Needs Non-Debian Format for Kernel Version Date: Sat, 22 Feb 2014 01:54:59 +0100 Mailer: Evolution 3.10.4 Forwarded Message From: Ralf Mardorf To: debian-user@lists.debian.org Subject: Re: Third-Party Software Needs Non-Debian Format for Kernel Version Date: Sat, 22 Feb 2014 01:49:25 +0100 Mailer: Evolution 3.10.4 Forwarded Message From: Ralf Mardorf To: debian-user@lists.debian.org Subject: Re: Third-Party Software Needs Non-Debian Format for Kernel Version Date: Sat, 22 Feb 2014 01:35:26 +0100 Mailer: Evolution 3.10.4 On Fri, 2014-02-21 at 17:03 -0700, Glenn English wrote: On Feb 21, 2014, at 4:20 PM, Thomas Vaughan tevaug...@gmail.com wrote: isn't supported per se. But when [the software], or the makefiles, parse the string 3.12-1-amd64 they don't get the expected result. If the uname -r were the string 3.12.9-1 then parsing it would yield the expected result. ---END QUOTE FROM VENDOR--- Is the reported kernel-version string, 3.12-1-amd64, something that I could change by compiling a custom kernel? Might a shell script that output the expected string work? Or link or what ever? I don't understand what the software is doing, that the output of uname -r doesn't fit to some other string. More information is needed. Sure, Debian packages might be named 3.x for kernels 3.x.y, 3.x.z, 3.x.n. I like this, since I don't need to manually fix my manually customized grub.cfg, when such a kernel is upgraded and especially those kernels are updated and older versions automatically will be removed, while kernels build by myself are never touched. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1393032256.695.90.camel@archlinux
Re: Third-Party Software Needs Non-Debian Format for Kernel Version
On 22/02/14 11:03, Glenn English wrote: On Feb 21, 2014, at 4:20 PM, Thomas Vaughan tevaug...@gmail.com wrote: isn't supported per se. But when [the software], or the makefiles, parse the string 3.12-1-amd64 they don't get the expected result. If the uname -r were the string 3.12.9-1 then parsing it would yield the expected result. ---END QUOTE FROM VENDOR--- Is the reported kernel-version string, 3.12-1-amd64, something that I could change by compiling a custom kernel? Might a shell script that output the expected string work? Or sed? Or export? Or, um, more information about what Debian release is being used and the third-party software. :) Kind regards --- Dunno how to solve the problem but I know what you need to know to fix it for me? ;) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5307ff47.4070...@gmail.com
Re: Re: Third-Party Software Needs Non-Debian Format for Kernel Version
isn't supported per se. But when [the software], or the makefiles, parse the string 3.12-1-amd64 they don't get the expected result. If the uname -r were the string 3.12.9-1 then parsing it would yield the expected result. ---END QUOTE FROM VENDOR--- Is the reported kernel-version string, 3.12-1-amd64, something that I could change by compiling a custom kernel? Might a shell script that output the expected string work? An appropriately named shell script in the right place in the path might take care of uname(1), but I don't see how to take care of uname(2), the system call. When the vendor says that the software parses the string, I think that the software is calling uname(). So my question is whether there is a way by compiling a custom kernel for me to alter what the uname() system call reports. -- Thomas E. Vaughan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caao_ux-kfd6odmkp0fzzznwdbm1kljy+mykbknl9wfd6+qy...@mail.gmail.com
Re: Re: Third-Party Software Needs Non-Debian Format for Kernel Version
isn't supported per se. But when [the software], or the makefiles, parse the string 3.12-1-amd64 they don't get the expected result. If the uname -r were the string 3.12.9-1 then parsing it would yield the expected result. ---END QUOTE FROM VENDOR--- Is the reported kernel-version string, 3.12-1-amd64, something that I could change by compiling a custom kernel? Might a shell script that output the expected string work? Or link or what ever? I don't understand what the software is doing, that the output of uname -r doesn't fit to some other string. I think that the build system is using the uname(1) command, but the compiled software is calling the uname(2) system call. More information is needed. I have not very much information, but let's assume the worst: The vendor has some compiled code that calls the uname() system call. Is it possible by compiling a custom kernel for me to make what uname() returns be the format that the vendor desires, something like '3.12.9-1', or whatever? Sure, Debian packages might be named 3.x for kernels 3.x.y, 3.x.z, 3.x.n. I like this, since I don't need to manually fix my manually customized grub.cfg, when such a kernel is upgraded and especially those kernels are updated and older versions automatically will be removed, while kernels build by myself are never touched. I'm not sure that I understand. The package name is one thing, but isn't what uname returns something else? -- Thomas E. Vaughan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAO_ux8TwPVzU-NmP==wyqe23gia4ukkpujtdgpdprtc1v_...@mail.gmail.com
Re: Re: Third-Party Software Needs Non-Debian Format for Kernel Version
isn't supported per se. But when [the software], or the makefiles, parse the string 3.12-1-amd64 they don't get the expected result. If the uname -r were the string 3.12.9-1 then parsing it would yield the expected result. ---END QUOTE FROM VENDOR--- Is the reported kernel-version string, 3.12-1-amd64, something that I could change by compiling a custom kernel? Might a shell script that output the expected string work? Or sed? Or export? Or, um, more information about what Debian release is being used and the third-party software. :) If the compiled program calls the uname() system call, then script-related fixes won't work. I don't have the source to the compiled program. I'm running Debian testing (jessie). Kind regards And kind regards to you for replying so promptly to my plea for help! What I'm wondering is whether I can get uname to return the desired format by somehow compiling a custom kernel. If so, then any help doing that properly would be appreciated. -- Thomas E. Vaughan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAO_ux8P23JyZr3NyL_qR3K=0nzkeybr4vso9xsnj6+z_k-...@mail.gmail.com
[Fwd: Re: Re: Third-Party Software Needs Non-Debian Format for Kernel Version]
Forwarded Message From: Ralf Mardorf To: debian-user@lists.debian.org Subject: Re: Re: Third-Party Software Needs Non-Debian Format for Kernel Version Date: Sat, 22 Feb 2014 03:28:15 +0100 Mailer: Evolution 3.10.4 On Fri, 2014-02-21 at 19:20 -0700, Thomas Vaughan wrote: What I'm wondering is whether I can get uname to return the desired format by somehow compiling a custom kernel. Yes you can, by getting the source code from kernel.org. If you simply copy the config from the Debians kernel, then IIRC # make-kpkg --initrd kernel-image kernel-headers won't use the Debians naming, but name the package and the output for uname -r and any string else as the original kernel.org name is. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1393036199.695.111.camel@archlinux
Re: Third-Party Software Needs Non-Debian Format for Kernel Version
On 22/02/14 13:20, Thomas Vaughan wrote: isn't supported per se. But when [the software], or the makefiles, parse the string 3.12-1-amd64 they don't get the expected result. If the uname -r were the string 3.12.9-1 then parsing it would yield the expected result. ---END QUOTE FROM VENDOR--- Is the reported kernel-version string, 3.12-1-amd64, something that I could change by compiling a custom kernel? Might a shell script that output the expected string work? Or sed? Or export? Or, um, more information about what Debian release is being used and the third-party software. :) If the compiled program calls the uname() system call, then script-related fixes won't work. I don't have the source to the compiled program. Aaah - more information makes a difference. Yes - sed won't work with compiled (though you can often make simple changes in a compiled file with a binary editor - simpler than NOP hops). an alias will work. I'm running Debian testing (jessie). Kind regards And kind regards to you for replying so promptly to my plea for help! What I'm wondering is whether I can get uname to return the desired format by somehow compiling a custom kernel. Long way - try an alias first - it 'should' work fine. (The Debian promise applies - if it breaks you get to keep both pieces). If so, then any help doing that properly would be appreciated. Kind regards -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/53080cde.5040...@gmail.com
Re: Third-Party Software Needs Non-Debian Format for Kernel Version
On 2/21/2014 9:20 PM, Thomas Vaughan wrote: isn't supported per se. But when [the software], or the makefiles, parse the string 3.12-1-amd64 they don't get the expected result. If the uname -r were the string 3.12.9-1 then parsing it would yield the expected result. ---END QUOTE FROM VENDOR--- Is the reported kernel-version string, 3.12-1-amd64, something that I could change by compiling a custom kernel? Might a shell script that output the expected string work? Or sed? Or export? Or, um, more information about what Debian release is being used and the third-party software. :) If the compiled program calls the uname() system call, then script-related fixes won't work. I don't have the source to the compiled program. I'm running Debian testing (jessie). Kind regards And kind regards to you for replying so promptly to my plea for help! What I'm wondering is whether I can get uname to return the desired format by somehow compiling a custom kernel. If so, then any help doing that properly would be appreciated. I'm not sure if it will work or not - I'm far from a Debian kernel expert. But one thing to consider: are there any packages which require the correct Debian format? If so, what would happen to them if you changed it in the kernel? Jerry -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/53080cf8.3020...@attglobal.net
Re: Third-Party Software Needs Non-Debian Format for Kernel Version
On 22/02/14 13:35, Jerry Stuckle wrote: On 2/21/2014 9:20 PM, Thomas Vaughan wrote: isn't supported per se. But when [the software], or the makefiles, parse the string 3.12-1-amd64 they don't get the expected result. If the uname -r were the string 3.12.9-1 then parsing it would yield the expected result. ---END QUOTE FROM VENDOR--- Is the reported kernel-version string, 3.12-1-amd64, something that I could change by compiling a custom kernel? Might a shell script that output the expected string work? Or sed? Or export? Or, um, more information about what Debian release is being used and the third-party software. :) If the compiled program calls the uname() system call, Good point. I should have given that more than a few seconds thought - and I suspect Jerry has pointed out a simpler way than intercepting sys calls. Is the name of the third-party software a secret? then script-related fixes won't work. I don't have the source to the compiled program. I'm running Debian testing (jessie). Kind regards And kind regards to you for replying so promptly to my plea for help! What I'm wondering is whether I can get uname to return the desired format by somehow compiling a custom kernel. If so, then any help doing that properly would be appreciated. I'm not sure if it will work or not - I'm far from a Debian kernel expert. Likewise. http://kernel-handbook.alioth.debian.org/ch-versions.html:- Kernel version This is the version that appears in kernel messages, filenames, package names and the output of 'uname -r'. In official kernel packages it follows the format upstreamversion[-abiname][-featureset]-flavour. It is not changed for every new package version. The abiname is changed as explained below. Many programs parse the kernel version string reported by the uname system call or command and expect to find at least 3 version components separated by dots. For compatibility, the official kernel packages currently add '.0' to the upstream version, but this will be dropped in wheezy+1. So it appears to be possible. But one thing to consider: are there any packages which require the correct Debian format? abiname shouldn't change should it? If so, what would happen to them if you changed it in the kernel? Jerry Kind regards -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/530813c6.3050...@gmail.com
Re: Third-Party Software Needs Non-Debian Format for Kernel Version
On 2/21/2014 10:04 PM, Scott Ferguson wrote: On 22/02/14 13:35, Jerry Stuckle wrote: On 2/21/2014 9:20 PM, Thomas Vaughan wrote: isn't supported per se. But when [the software], or the makefiles, parse the string 3.12-1-amd64 they don't get the expected result. If the uname -r were the string 3.12.9-1 then parsing it would yield the expected result. ---END QUOTE FROM VENDOR--- Is the reported kernel-version string, 3.12-1-amd64, something that I could change by compiling a custom kernel? Might a shell script that output the expected string work? Or sed? Or export? Or, um, more information about what Debian release is being used and the third-party software. :) If the compiled program calls the uname() system call, Good point. I should have given that more than a few seconds thought - and I suspect Jerry has pointed out a simpler way than intercepting sys calls. Is the name of the third-party software a secret? then script-related fixes won't work. I don't have the source to the compiled program. I'm running Debian testing (jessie). Kind regards And kind regards to you for replying so promptly to my plea for help! What I'm wondering is whether I can get uname to return the desired format by somehow compiling a custom kernel. If so, then any help doing that properly would be appreciated. I'm not sure if it will work or not - I'm far from a Debian kernel expert. Likewise. http://kernel-handbook.alioth.debian.org/ch-versions.html:- Kernel version This is the version that appears in kernel messages, filenames, package names and the output of 'uname -r'. In official kernel packages it follows the format upstreamversion[-abiname][-featureset]-flavour. It is not changed for every new package version. The abiname is changed as explained below. Many programs parse the kernel version string reported by the uname system call or command and expect to find at least 3 version components separated by dots. For compatibility, the official kernel packages currently add '.0' to the upstream version, but this will be dropped in wheezy+1. So it appears to be possible. But one thing to consider: are there any packages which require the correct Debian format? abiname shouldn't change should it? I wouldn't think so - but I also don't know. However, if you do change something basic like the kernel version, what else will it affect? You might get a kernel which will boot but nothing will run, for instance. Just a thought. I always worry about side effects :) Jerry -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/53082070.6050...@attglobal.net
