Find the answer to your Linux question:
Results 1 to 3 of 3
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    May 2009

    Slackware 13.37 boot from USB on an ASUS EeePC 900

    Hi Everyone,
    I'm trying to install Slackware onto an ASUS with an Intel Graphics i915 card and getting working with X11; I am having two problems -- the X11 program will not detect the intel i915 graphics correctly; even if explicitly entered into the configuration file -- however from a running copy of Ubuntu on the SAME laptop -- i can read the log files and see that it somehow auto-probes the i915 graphics card, and forces the driver to load -- but I can't replicate the success on a slackware system using the same drivers.

    The second problem is more critical, and that is getting a minimized kernel to boot. (eg: drive space is critical on this system, so un-needed modules are removed as much as possible). However, a kernel compiled with SCSI disk, USB mass storage turned on, EHCI, UHCI, in the kernel hangs when booting from USB (I have successfully gotten a 2.6.24 kernel booting in the past).

    When I boot it says:

    Loading CoCleo............................................ .........................
    BIOS data check successful

    Decompressing Linux. . . Parsing ELF . . . done.
    Booting the kernel.

    And then it hangs forever, and does nothing more.
    The command line parameters to the kernel are the same as for the other kernel which did boot: eg:

    append="rootdelay=10 root=/dev/sda1 vt.default_utf8=0 init=/sbin/init pci=bios idle=halt acpi_sleep=s3_bios"

    What might I be doing wrong with the new kernel that would cause the boot to hang?

  2. #2
    Just Joined!
    Join Date
    May 2009

    USB boot stick for slackware 13.37

    I never was able to get that kernel off the slackware 13.37 disk to compile correctly. I went to and downloaded and did a somewhat optimal configuration for the Asus (I will post it after I get all the kinks worked out.)

    The new kernel boots correctly on the ASUS and runs the slackware 13.37 installation just fine: although I am still working on the graphics problems, and volume ID problems.

    When using a USB stick on the ASUS, ( and this is probably a general purpose problem in Linux and not just Slackware ) the enumeration of the SCSI device changes depending on which slot the stick plugs into.

    The BIOS correctly identifies the stick and can boot it -- but once the kernel begins executing, getting it to correctly mount the root partition from the same drive is a problem.

    There is no obvious way in LILO 22.7.3 to have it pass the BIOS drive parameter from whatever drive LILO second stage loader was run on, rather than passing a fixed string to the Kernel.
    (I may be fixing this shortly with a patch if no one has a solution....)

    Since LILO had no obvious fix, I tried a UUID specification in the kernel parameter list. eg:
    append="rootdelay=10 root=UUID=cffd0d5c-04c8-4038-b7cc-xxxxxxxxxxxx vt.default_utf8=0 init=/sbin/init"

    The time delay before mounting root is to allow the linux kernel to register all USB and SCSI devices before attempting to mount the root partition; If I specify a drive, occasionally I can get the system to boot -- but if I specify a UUID, I get:

    [10.437112] 0820       7816704 sdc driver: sd
    [10.437535]    0821        523677 sdc1 00000000-0000-0000-0000-000000000sdc1
    [10.437535]    0822       6768247 sdc2 00000000-0000-0000-0000-000000000sdc2
    Kernel panic - not syncing VFS: Unable to mount root fs on unknown-block(0,0)
    Which obviously has the UUID set to all zeroes for all partitions.
    Googling around, most people solve this by creating an initrd disk, which allows the kernel to run blk-id on each of the partitions and informing the kernel of their values. But without initrd UUID values aren't available at boot time before the "init" script is run.

    I am not interested in making an initrd for this system, and am curious if anyone knows of a reliable way to get either LILO to pass a correct root= partition; or if there is a kernel parameter I can pass (besides sdc which is sometimes wrong) so that whichever disk the BIOS booted from becomes the drive the root partition is on. eg: FOO: root=boot drive & boot partition.

    This has to be a very common problem for SCSI and USB system users who's drives don't always enumerate the same; but I have been unable to find any solution other than a complex initrd.

  3. #3
    Just Joined!
    Join Date
    May 2009


    I learned a bunch today.....

    LILO from 22.5 up uses a 32 bit number like a UUID (Volume Number) from the partition table to identify the drive when booting Linux from arbitrary/changing drives;
    During installation, when Lilo is run, it checks the Volume Number of whichever drive the kernel resides on, and saves it in the boot loader so that it boots the kernel from THAT same drive, regardless if the BIOS renumbers it.

    Unfortunately, LILO does nothing to inform the kernel of which drive it booted from; and although I can modify Lilo to output the bios number and partition digit eg: 0x8?1, Linux does not have to respect the bios numbering when enumerating drives.... If I could always guarantee the Linux did, then I could modify LILO to output that number easily enough.

    The fact that it can be inconsistent is why booting a ram drive and getting the UUID's to be parsed is the normal solution. I think a simple kernel patch might be useful....

    I looked into the linux kernel to see how the UUID system works from the kernel parameter line; and the names are parsed by "linux/init/do_mounts.c"
    in the function dev_t name_to_dev_t()

    The name of the drive passed as a kernel parameter is supposed to be converted by that function into the correct enumerated drive under linux.
    The UUID matching algorithm is already present and correct in the kernel; From LILO I have to pass the command:
    There must be an exactly 36 character UUID string attached after it.
    It seems to me, that since a UUID of all zeroes is obviously *wrong*, that a call could be made from name_to_dev_t() to whatever function on each block device reads the UUID.
    So, I just need to find that, and I think I can patch the kernel to work properly even without a ram drive....
    Last edited by andrewr; 11-14-2011 at 07:41 AM.

  4. $spacer_open

Posting Permissions

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