Recently, Somebody Somewhere wrote these words
>
> > Your hardware may not be coming up correctly. I'd be looking
> > for your mobo chipset driver(s) and video driver(s) compiled
> > in, and other drivers not compiled in.
>
> The "hardware" is VMWare Player 5.5. It brought up svn-20060108
> without a hitch. AFAIK, the only thing that might vary in
> practice from install to install is the CPU type, which in my
> case is an Athlon MP. However, this is literally the exact same
> install which is (simultaneously) running the LFS livecd and
> HLFS svn-20060108. So, I don't think it's a hardware issue.
Thanks for not putting that in the first post - NOT! :-).
>
> >Mount the disk and go through the logs. Get into /var/log and
> >find the first error in the boot, which usually is the issue.
> >ideally use a distro kernel, made to be as adaptable as
> >possible.
>
> One nice thing about doing this one VM is that this kind of
> thing is very easy.
Maybe we should leave it to you, then :-)).
> I built the HLFS system under the livelfs
> cd, and have been booting back to that and remounting the HLFS
> partition to try new ideas. I can mount it under Fedora Core 4
> if there's some tool there that would make debugging easier...
>
> Some of what I got back from Google suggested a problem with
> /dev, and perhaps with grub not seeing the devices right. The
> latter, at least, doesn't seem to be the issue; I haven't ruled
> out the former yet (trouble with udev). I'm guessing that the
> kernel is bailing out very early in the inittab, but I don't
> know where.
>
> In any event, there's no data in /var/log - literally. They're
> virgin from the install.
That points early. Are you sure the kernel is compiled for the
correct cpu type?
>
> >Another useful thing is to set up another kernel and modules in
> >grub. You may have to copy over /lib/modules/something as
> >well, and boot on a known good kernel & modules, then hunt for
> >errors.
>
> My thought was to copy over and install the known good
> svn-20060108 kernel, system map etc and see what happens. My
> plan was that if that works, I'd recompile the new kernel with
> the config I used for 20060108 and see what happens then.
>
> On what basis would one suspect an issue in the kernel itself
> over the rest of the install?
I don't. Elimination. You can inject a kernel handily enough, and
it eliminates that from the enquiries. It's also a good general rule to
suspect the last thing you did first when you manage to screw up.
>
> Just off of what I've read from Google, my suspicion is that
> something is wrong with udev, and that it manifests when we try
> to remount /dev/hda1 as / rw. But I don't know how to check
> that. When I boot under LFS and chroot in, /sbin/udevstart
> works and populates /dev correctly...
The one I've had there is udev leaving a pid around, and then
barfing on startup. But it happens later. You aren't even getting
the disk mounted rw. There should be startup devices in /dev,
console & null. Udev causes a system panic, but it's graceful, not
a panic. Take it from an expert in screwing up :-).
I would suspect that something has the hd as ro while the kernel
tries to mount it rw. Vmware is probably capable of that. Have you
asked at vmware? They do have tech support.
--
With best Regards,
Declan Moriarty.
--
http://linuxfromscratch.org/mailman/listinfo/hlfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
