Sort of not finding media with HD live with 6.4.4, fine before
For various reasons I like to keep my live distros running live even when put on the harddrive. I have a single ext3 partition acting as my boot partition where I keep filesystem images, kernels, initial ramdrive images, and etc. On this I use extlinux (the ext FS variant of syslinux) because I absolutely abhor Grub. So when it comes to dealing with live distros like this I generally can just copy the kernel, initrd, and filesystem image to appropriate locations and copy the syntax from isolinux.cfg to my extlinux.conf adjusting only for filenames or etc (since most distros like this insist on calling the kernel "linux" and obviously one "linux" would just clobber another "linux," so it ends up being knoppix and knopprt.gz or etc.) Overall this has been a very useful solution over the years where if I have a problem I could usually boot a live distro and fix it easily and quickly enough without having to dig for USB drives or anything like that even. (Especially handy since this means I can fix those USB drives even.) I think this may be basically the same thing as the "poor man's install" (though I'm not 100% clear from looking over the documentation) only done manually? I realize I could specify manually the location, but for various reasons I really prefer that it does the usual scan (one of which being the fact that I want it to work even if boot device orders or etc change -- I really don't want to play the guessing game any time such a thing happens...)
But suddenly this isn't working for me now with the latest non-exclusive version, 6.4.4 (CD version. Not customized in any way at this point.) I believe I was using 6.2.1 before just off the top of my head. It starts up and searches for the boot media as usual, but never finds the media. It just keeps trying, waiting for the USB devices to "settle" and trying over and over until it eventually gives up and dumps me at a debug shell. I tried mounting manually, but I guess I just don't know enough about loopback mounting because if I try a command line like "mount -o loop/mnt/KNOPPIX/knoppix /mnt-system" (or by trying to specify the filesystem -- but I wasn't sure off the top of my head if it was SquashFS or what exactly) I get an error telling me invalid syntax. I'm guessing that the simplified mount at this stage doesn't work the same? I remember there's some sort of way to actually first point a /dev/loop device to an image and then mount that loopback device in such a way that as far as mount is concerned it is just mounting a hardware device, but I forget what it was off the top of my head. More importantly, this still leaves the fundamental problem.
To make matters more interesting, I was renaming the filesystem image to "knopp644" and trying to use the knopp_name=knopp644 "cheatcode" because when live distros like this use a generic filename like this it causes problems if you try to boot a different version -- eg I had 6.2.1 on my flash drive and tried to boot that to fix things only to get a black screen since it was booting the newer filesystem image from the harddrive using the old kernel and initial ramdrive. (I really think that live distros like these should make a habit of using a version-specific filename in some form by default so conflicts like these won't happen every time some device with a different version ends up earlier in the device order on a system.) Here's what's really interesting: I thought maybe it was ignoring the knoppix_name parameter, so in testing, I made a symbolic link called "knoppix" in the KNOPPIX directory pointing to that knopp644 file and then when I booted (leaving that knoppix_name=knopp644 cheatcode in) it informed me that the knopp644 file was damaged and was 0 bytes (which makes me think it looked at the "knoppix" symlink instead of knopp644, but didn't look at it correctly.) Thus it apparently sees the filesystem and even could see the files, but it obviously handled them incorrectly in some way. Sadly, when I changed the filename back to "knoppix" (removing the symlink first of course) instead of knopp644 and removed that cheatcode entirely it still wouldn't boot (once again going back to the original issue of just going through all devices, waiting, retrying, and eventually giving up.) So it sort of sees things, but it's as if somehow it doesn't recognize them correctly once it does. Oh, and just to be on the safe side, I did update the sha1sums file, though as far as I'm aware it doesn't actually check the checksums unless you specifically tell it to.
I was able to get it to boot by putting the filesystem image on a USB drive (the one that currently won't boot directly,) but it didn't work while I was using the renamed filesystem image and the knoppix_name cheatcode interestingly enough. So I still wonder a bit if that cheatcode may still not fully work right now. Though at this point I'd rather have it working even without that cheatcode if necessary. I also thought about using the "bootfrom" cheatcode along with the ISO image, but as far as I can tell it wants an exact location, device and partition and if either of these changes in any way it wouldn't work anymore until changed again. Obviously "fromhd" isn't any better since it still wants an exact location.
Any ideas on why it might not be finding the boot media 100% correctly?
PS. In case it helps, here's basically the configuration I'm using for Knoppix in my extlinux.conf file:
LABEL knoppix
MENU LABEL ^Knoppix 6.4.4 - Text Mode
MENU PASSWD
KERNEL knoppk
INITRD knoprt.gz
APPEND ramdisk_size=100000 lang=en vt.default_utf8=0 apm=power-off nomce quiet loglevel=0 tz=localtime noswap noeject noprompt dma keyboard=dvorak home=scan 2 vga=788 video=800x600
(And I have basically a carbon copy of that for the GUI mode sans the "2" parameter of course, but I usually use the text mode for the stuff I run Knoppix to do.) Most of this is really mostly just a copy of the same stuff from the isolinux.cfg file really.
PPS. BTW, for some odd reason 6.4.4 doesn't like me using the vga= parameter. If I have that in there, the monitor says "no signal" and shuts off after the initial startup stuff finishes (note that I actually originally used a different number to get the closest I can to my monitor's native 1920x1080 resolution (1600x1050 or somewhere in that general range I think, but I forget since I had to do a scan and everything just to find it due to it not being a standard VESA value -- it's not a standard number.) However, thinking something was going wrong due to that, I dropped it down to a mere vga=788 (standard VESA 800x600x16, which should be about as well supported as you get) but I still get the no signal problem. I really can't stand a plain VGA console, but if I don't specify a vga= parameter, it really doesn't work right for me. Note that the initial startup stuff works fine both with the original vga= parameter and the 788 and it doesn't go blank until it's more or less completely done and dropping me at a terminal. (Also, it is just the video. I can do stuff like type "shutdown -r now" and it will respond.)
Semantics etc... and then some suggestions
Lots of semantic issues her, let's see.
Quote:
Originally Posted by
Nazo
There is no right or wrong. You may not like the way I use it, but that doesn't make it wrong. That just makes it wrong for you.
In the grand scheme of things, you are of course perfectly right. In the smaller contexts, we often use the words somewhat differently, like
Q: Is this the right way to get there?
A: There is no really right or wrong way, my son
Q: OK then, is this the right way to get there in 5 minutes?
A: No
You have a setup very similar to mine, except for me using grub, which in this context is equivalent. Yours, doing quite a bit of modifications, broke on a version upgrade, mine didn't. I think it could tell something about robustness, but you may disagree.
Quote:
Syslinux supports directories. I just don't want to use them. Whenever I have to use Grub, I prefer to rename as well. Actually, it's very unlikely this has anything to do with the bootloader anyway since the problem is long after the bootloader is gone.
You rather insist on renaming. Which may indeed lead up to problems - long after the bootloader is gone. You simply have no guarantee it won't. You insist on unsafe and, for most of us, error-prone, methods even when you could play it safer. OK.
Quote:
None. They wouldn't hard-code them. There is no benefit in doing so, but much harm in doing so. The Knoppix team knows better.
You are probably right, in a narrow sense of hard-coding. But there is no guarantee you are, and I consider it a bad software practice to rely on good guys not making mistakes. You don't know for sure that may not have happened here, do you? And in a wider sense: Hard-coded defaults that have to be explicitly reset. You may think you have set all the relevant parameters, but are you sure? That something that has worked for a long time, suddenly breaks, indicates some "invisible" change, no?
Quote:
Well, it has been a month and a half, but I'm pretty sure I remember having tried that and it just didn't find it. I'll try it again later, but at this point I've about given up on the whole thing.
Sure, and when it does not work with your method, there is still absolutely nothing to adjust in your method..
Quote:
Good for you. Parameters do exist to use them though.
Sure, but HOW to use them? I have probably used Knoppix some hundred times more than you, including experimenting with parameters. Because of X changes, this has been much of an unstable kludge, with results changing from release to release. In such a situation, I advise to work defensively, start out with as few as possible, only adding more with experience. But of course you know better.
Quote:
I need a higher resolution in the console regardless. However, I'm willing to bet that the graphics settings are absolutely unrelated to the issue at hand in every way possible.
That may well be true.
In summary, I suggest you
- Use original names of kernel and minirt.
- Create sys(ext)linux subdirectories, e.g. knx621, knx644 etc, where they reside.
- Copy command lines from actual syslinux entries for the release EXACTLY, only modifying by adding knoppix_dir (plus evt fromhd).
- Rename the KNOPPIX directory to, say, KNOPPIX644 - try them in root directory before moving them to a common, say knoppix_releases, folder.
- Add graphics parameters one by one, or two by two.
- Maybe unzip minirt.gz and look at graphics handling of console during init - there is quite a bit of switching going on, which might be usable for modifying console mode.
Works for me in a Knoppix variant
Quote:
Originally Posted by
krishna.murphy
I don't see any reference to one of my favorite modes (from earlier versions), the virtual terminals. I offer the following in case it helps - you can reach those terminals by giving the command (in a terminal as you seem to be doing):
I used to reach them by hitting ctrl-alt-F1 but that doesn't work for me any more. I do hope it helps -
It works for me in the hybrid (arch=x86_64) 64-bits Knoppix 6.4.4/Debian 6.0.1 full HD install that I'm running right now (assembling for later remastering):
ctrl-alt-F1: Gets me a console
ctrl-alt-F5: Returns me to X
The init parameters I currently use:
Code:
knoppix@Microknoppix:~$ cat /proc/cmdline
root=/dev/sda3 rootwait lang=us apm=power-off nomce libata.force=noncq tz=localtime loglevel=1 ramdisk_size=100000 lang=en keyboard=no nosound vt.default_utf8=0 apm=power-off initrd=minirt.gz nomce libata.force=noncq loglevel=1 tz=localtime rw
