(So I downloaded a amd64 installcd and ndiswrapper sources to build the much polemic not included drivers...) Couldn't find "make". So I tried the larger livecd, same luck. But examining the image.squashfs I can see it's there in /usr/bin, though it isn't in the same folder as the live system, so I'm guessing the image isn't getting properly mounted.
Forgot to mention this is for amd64-2008-r1.
The 'make' command isn't supposed to be available on the minimal CD. However, it should be available on the LiveCD. The kernel sources aren't, though, which will probably make it somewhat problematic to build ndiswrapper.
Ok, so the bug is something completely different. I took a close look of the boot process and noticed that he thought my usb key w/ 2007 installcd was the 2008 cd I was booting. If I recall he tries to load anything with a "livecd" file on it. I mentioned some time ago in the ml this is a problem easily fixed. Catalyst would do something like "echo ${arch}-${version}-${type}" >> livecd", also catalyst would add boot option "livecd=${arch}-${version}-${type}". Genkernel initrd would look for the media with "cat livecd" equal to ${livecd}. done.
(changed summary)
While this is "easy" to implement, it does require passing another commandline option (as you mentioned). However, the "simple" solution to this problem is to remove your USB stick when you boot :P This solution does cut down on the obvious mismatches, but it wouldn't help in the case of someone copying the CD to a USB stick, making a few mods to the squashfs without changing the 'livecd' file, and then trying to boot the original CD with the USB stick in. Unless the solution is completely "fool proof", I'd rather not change the way it currently works.
(In reply to comment #5) Exactly, that's the only case that it doesn't cover. However it happens wo/ the solution, and a user can do a billion things to break the livecd/usb. The key point is, any change he makes, won't be supported. This would solve for any release media built by Catalyst. I should point that the problem I had was fixed (not finding make), only because I read the genkernel code. Otherwise, I (and you?) would lose a lot of time solving this. Could happen to many people: users w/ livecd's and system rescue usb's, developers using multiple livemedia. The only solution I see that is more complete, would be too slow: to run a sort of md5sum check on the whole cd. Know any appropriate signature programs?
Oh, and having this "livecd" boot argument present and documented, should make those "hackers" aware they should hack the livecd values too ;)
Yeah, I don't really see the reasoning for adding another command-line option. In fact, I'm actually opposed to it, as we're only allowed a limited amount of characters for the entire thing. Making the "livecd" file a bit more useful isn't a problem, since it's already used by some of the LUKS stuff.
(In reply to comment #8) > as we're only allowed a limited amount of > characters for the entire thing. Ah, I wasn't aware there was a limit here, that changes everything. How about genkernel, when building the initramfs, dynamically add to linuxrc a line (to the beginning) that defines LIVECD_VER="${arch}-${version}-${cdtype}...", with that value being in /livecd ? (if I recall the Luks thing I wrote would need an update). As an alternative, is there a way to add a VERSION sort of name to the initramfs, like for the kernel? And a command like "uname -r"? Then you could leave the LIVECD value here.
(In reply to comment #9) > How about genkernel, when building the initramfs, dynamically add to linuxrc a > line (to the beginning) that defines > LIVECD_VER="${arch}-${version}-${cdtype}...", with that value being in /livecd > ? (if I recall the Luks thing I wrote would need an update). And where would genkernel get this string? Genkernel has no knowledge of the LiveCD's type, version stamp, etc. > As an alternative, is there a way to add a VERSION sort of name to the > initramfs, like for the kernel? And a command like "uname -r"? Then you could > leave the LIVECD value here. Just adding the kernel version isn't enough to make this "fool proof". Have a USB stick with an image that uses the same kernel version (but it completely different) would break this solution.
(In reply to comment #10) > And where would genkernel get this string? Genkernel has no knowledge of the > LiveCD's type, version stamp, etc. Well, you would need a new parameter like "--live_ver" in genkernel (not necessarily public). Catalyst which knows all those variables would invoke genkernel with it. > > As an alternative, is there a way to add a VERSION sort of name to the > > initramfs, like for the kernel? And a command like "uname -r"? Then you could > > leave the LIVECD value here. > > Just adding the kernel version isn't enough to make this "fool proof". Have a > USB stick with an image that uses the same kernel version (but it completely > different) would break this solution. Here the point wasn't using the default kernel version. You know that you can identify a kernel with something like 2.6.26.3-gentoo. Instead of gentoo you would have 2.6.26.3-gentoo-installcd-2008.1-x86. For instance with: sed -i s@'EXTRAVERSION ='@'EXTRAVERSION = -installcd-2008.1-x86'@ Makefile Then in linuxrc you compared the livecd value with the tail of this version ;). (Now if you decide to hack the livecd/usb you need to update this too, or in the worst case they get the same behaviour as now. You can't do anything this, otherwise you would need to check the whole image to see if they changed anything.)
I looked to see if genkernel supported setting EXTRAVERSION, while he does something with it, doesn't seem to depend on user input. Setting a new --extraversion could be useful for other purposes, and would be a clean solution for this.
I'd prefer not do something that touches the kernel config/version, since it means touching a lot of code, but --extraversion does seem like a good way to go about it.
