Results 1 to 10 of 10

Thread: Sort of not finding media with HD live with 6.4.4, fine before

  1. #1
    Junior Member
    Join Date
    May 2011
    Posts
    3

    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.)

  2. #2
    Senior Member registered user
    Join Date
    Sep 2006
    Posts
    801
    Quite frankly, I think you provide a good illustration of wrong ways to use Knoppix6.X.

    First, with grub, I don't have to perform that renaming game for kernels and initrds, just place them in different subdirectories. We don't know how much those names may be hard-coded either, so the safest is to keep renaming at a minimum. So, your kind of multi-booting is easily implemented with grub, but it seems from your description that it is way harder with extlinux. Your choice.

    Second, it should be enough just to rename the KNOPPIX directory, e.g. to KNOPPIX644, and then use the cheatcode knoppix_dir=KNOPPIX644

    Third, I try to minimize kernel graphics parameters, just using, for example, xmodule=nouveau, and doing the resolution adjustments in X. This is because this stuff has not been stable and fully reliable in 6.X, variable from release to release, and at least in part it is due to X changes. I think you may easily shoot yourself in the foot heaping up graphics parameters like you do - the graphics stuff just isn't that reliable nowadays.

    Fourth, Knoppix is extremely flexible, provided you use the right cheat codes. But what do you do?
    Obviously "fromhd" isn't any better since it still wants an exact location.
    Well, simply using fromhd=<your single ext3 partition>, copying the KNOPPIX directory as KNOPPIX644 there, telling Knoppix about that with knoppix_dir=KNOPPIX644, and dropping that renaming game in extlinux should almost certainly give you a boot. You might even get it from USB, dropping the fromhd=, but keeping knoppix_dir=KNOPPIX644 on the command line.

    I think one may even place the KNOPPIX directory in a subdirectory, and prepend that name in knoppix_dir, but I haven't tried.

  3. #3
    Junior Member
    Join Date
    May 2011
    Posts
    3
    Quote Originally Posted by Capricorny View Post
    Quite frankly, I think you provide a good illustration of wrong ways to use Knoppix6.X.
    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.

    First, with grub, I don't have to perform that renaming game for kernels and initrds, just place them in different subdirectories.
    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.

    We don't know how much those names may be hard-coded either
    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.

    Second, it should be enough just to rename the KNOPPIX directory, e.g. to KNOPPIX644, and then use the cheatcode knoppix_dir=KNOPPIX644
    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.

    Third, I try to minimize kernel graphics parameters, just using, for example, xmodule=nouveau, and doing the resolution adjustments in X.
    Good for you. Parameters do exist to use them though.

    I think you may easily shoot yourself in the foot heaping up graphics parameters like you do - the graphics stuff just isn't that reliable nowadays.
    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.

  4. #4
    Senior Member registered user
    Join Date
    Sep 2006
    Posts
    801

    Semantics etc... and then some suggestions

    Lots of semantic issues her, let's see.

    Quote Originally Posted by Nazo View Post
    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.

    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.


    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?

    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..

    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.

    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.

  5. #5
    Moderator Moderator
    Join Date
    Jan 2010
    Location
    Asheville, NC, USA
    Posts
    528
    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):
    Code:
    chvt 1
    I used to reach them by hitting ctrl-alt-F1 but that doesn't work for me any more. I do hope it helps -

    Cheers!
    Krishna

  6. #6
    Senior Member registered user
    Join Date
    Sep 2006
    Posts
    801

    Works for me in a Knoppix variant

    Quote Originally Posted by krishna.murphy View Post
    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):
    Code:
    chvt 1
    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

  7. #7
    Senior Member registered user
    Join Date
    May 2006
    Location
    Columbia, Maryland USA
    Posts
    1,631
    Is tz=localtime in there twice for some reason?

  8. #8
    Senior Member registered user
    Join Date
    Sep 2006
    Posts
    801
    Quote Originally Posted by utu View Post
    Is tz=localtime in there twice for some reason?
    I haven't checked it - it might have been added by the 0wn installer, not seeing that it was already in place in the running version to be copied from.. I absolutely don't touch it more than I have to, you see - but it should surely occur only once..

  9. #9
    Moderator Moderator
    Join Date
    Nov 2010
    Location
    Germany/ Dietzenbach
    Posts
    1,124
    ... most of the entries are twice

  10. #10
    Senior Member registered user
    Join Date
    Sep 2006
    Posts
    801
    It's the first time ever I have used 0wn in its present version, and the install works perfectly fine Really thought I should not fiddle with the parameters...
    I actually much prefer poor man's installs, this was only for creating a 64-bits version.
    BTW, ctrl-alt_F1 works for me with poor man's installs w/64-bits kernels too.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •