Slackware 13.37 boot from USB on an ASUS EeePC 900
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 188.8.131.52 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?
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 kernelsource.org and downloaded 184.108.40.206 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:
Which obviously has the UUID set to all zeroes for all partitions.
[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)
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.