[lfs-support] Can't get LFS to boot, fsck.ext4 no such file or directory while trying to open ....
lfs65 at cruziero.com
Sun Mar 24 13:30:41 PDT 2013
> To: lfs-support at linuxfromscratch.org
> From: TJ Olaes <contact at olaes.net>
> Date: Sun, 24 Mar 2013 18:51:59 +0000 (UTC)
> Subject: Re: [lfs-support] Can't get LFS to boot,
> fsck.ext4 no such file or directory while trying to open ....
> akhiezer <lfs65 <at> cruziero.com> writes:
> > Well, (roughly speaking and to paraphrase from old Slackware notes) there was
> > change in the kernel back in ca late 2009 / early 2010, whereby the "old" ide
> > subsystem was deprecated in favour of the newer libata subsystem, and this
> > affected the naming of device nodes for almost all types of disk drives -
> > physically or logically IDE or not: basically anything 'hd..' became 'sd..' .
> > Am not sure how a layer of VM might affect all that.
> > A few years back I used a machine that had, physically, only IDE drives and
> > connectors - no SATA disks or ports at all - to build an LFS from a Slackware
> > ~12.2 (or <= 13.0) host OS: the host OS used /dev/hda, /dev/hdb, &c; and the
> > LFS used a kernel that wanted the new libata 'sd..' naming system; and I _had_
> > tell LFS's fstab &c to use 'sd..' naming system, else LFS would boot only so
> > before hitting a kernel panic.
> > So it's not really a matter of whether the drives are physically or (somehow)
> > logically IDE: your new LFS might require the 'sd..' naming.
> Bingo. That's relevant info that's not mentioned in the LFS book, because
> I just renamed all the hda.'s to sda. and I now have a login prompt.
> Following the LFS steps, this hda/sda naming business isn't mentioned. I
> assumed hd.. because SliTaz had named them hd.., but it's running on a 2.6
> kernel. It might be worth it to note that in kernel 3.8.x the hard disks
> will be referred to as sd..?
The change happened sometime between kernel 188.8.131.52 (Slackware 12.2, released
20081211) and 184.108.40.206 (Slackware 13.0, released 20090828); a google should get
more-precise version if wanted. So (looking at distrowatch page for SliTaz) the
next release of SliTaz might be dealing with the same issue.
IIRC, I did put a note back to the bookmeisters on the matter, but nada: it may be,
if anything, deemed less needed now if it's assumed that more-or-less every host
OS will be on a sufficiently late 2.6 or on a 3.x kernel, and without an especially
> Oh well. Thanks for your help, and the historical tidbit you dropped there
> was pretty clutch in informing me what to do next.
You're welcome - no probs.
More information about the lfs-support