Linux From ScratchThis Forum is for the discussion of LFS.
LFS is a project that provides you with the steps necessary to build your own custom Linux system.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
You've talked about and been using different machines and different configurations.
To stay on the right track can you post the error(s) shown (as much as possible, like post #12) from the machine you are having problems with?
I *think* I am having the same problems on all machines. But to be on the safe side I will stick to the virtual machine for now and try to find the error there.
Quote:
First thing that comes to mind without seeing any errors: This one needs to be selected Device Drivers -> Generic Driver Options -> Maintain a devtmpfs filesystem to mount at /dev
Yes, that one is important and it may have caused some of the errors. But not all.
What I did is the following:
- correct /etc/fstab
- compile kernel (3.10.10) with defconfig and the above option
--> it boots ok!
- disable modules
--> ok!
- disable 64bit, change processor family and a few other CPU-related
--> kernl panic - no init found.
So that narrows it down.
I will need to make more tests to find out exactly which option it is.
But I think the "could not mount root fs" kernel panic is solved by either fixing fstab or checking "Maintain a devtmpfs filesystem..." (or both).
You don't mention how you build this 32 bit kernel.
It isn't as simple as un-setting the [*] 64-bit kernel option when running make menuconfig
Assuming a x86_64 based system: If you follow the below steps the build process looks for the current architecture used and it will end up setting options for x86_64
Code:
$ cd /usr/src/linux-3.10.10
$ make mrproper
$ make defconfig # I always use this one to force the current architecture. You can leave it out.
$ make menuconfig
You could try this to force x86 instead of x86_64:
Code:
$ cd /usr/src/linux-3.10.10
$ make mrproper
$ make i386_defconfig
$ make menuconfig
Never tried it myself, but it might be worth looking into.
Defconfig more or less builds against your host and current toolchain system with common hardware on minimum activated. If you want a 32-bit kernel you have to build with either oldconfig, menuconfig, or other GUI driven kernel configure utility and disable 32-bit.
You also have to make sure you built for 32-bit software earlier on, especially for GCC during the Toolchain building stage. If you're trying to build a 32-bit kernel for 64-bit software it will panic.
It isn't as simple as un-setting the [*] 64-bit kernel option when running make menuconfig
Oops...
Quote:
You could try this to force x86 instead of x86_64:
Code:
$ cd /usr/src/linux-3.10.10
$ make mrproper
$ make i386_defconfig
$ make menuconfig
I tried this. It still panics.
Which kernel image is the correct one, the one from the /arch/x86 or the one from the /arch/i386 directory?
x86 works for the 64 bit kernel. None of them work for the i386_defconfig kernel.
Quote:
Originally Posted by ReaperX7
You also have to make sure you built for 32-bit software earlier on, especially for GCC during the Toolchain building stage. If you're trying to build a 32-bit kernel for 64-bit software it will panic.
In this case I might need to start over completely.
In the end I want to build a system with a hard-rt kernel. This requires the high precision timer to be activated which is not available in a 64 bit kernel.
Maybe it would be wise to post the error message the lines leading up to it.
http://postimg.org/image/p9l7nfal5/
That's when I build the kernel from the 64bit virtual machine (i.e. not from the Debian host) using i386_defconfig and "Maintain a devtmpfs filesystem to mount at /dev".
The machine freezes, I can't get any more output.
Quote:
BTW: Just curious, but why do you want to do this?
Once the LFS system is finished I want to use it as audio convolution engine. I will do realtime digital room correction. I.e. I want to correct the audio of my gear for bad effects from the room as it plays.
http://postimg.org/image/p9l7nfal5/
That's when I build the kernel from the 64bit virtual machine (i.e. not from the Debian host) using i386_defconfig and "Maintain a devtmpfs filesystem to mount at /dev".
The machine freezes, I can't get any more output.
Not much to go on and no clues that might help.
Quote:
Once the LFS system is finished I want to use it as audio convolution engine. I will do realtime digital room correction. I.e. I want to correct the audio of my gear for bad effects from the room as it plays.
That's a goal, not a reason. Why wouldn't this work on a x86_64 platform?
Anyway: Maybe you are looking for CLFS instead of LFS (Cross-Compiled Linux From Scratch). Specifically the x86_64 Multilib Builds. This would also be in line with ReaperX7's reply.
That's a goal, not a reason. Why wouldn't this work on a x86_64 platform?
In this case I misunderstood your question.
For a hard-RT kernel to perform well the high presicion timer (HPET) should be activated in the kernel. But this feature is only available for a 32 bit kernel.
The option disappears in the kernel menuconfig as soon as 64 bit is deactivated.
If it was not for this option, I would go with 64 bit.
Edit:
Apparently it is not so easy to build a pure x86 system from the LFS 7.4 book.
In any event jhalfs can't handle this out of the box.
druuna, why did you suggest the x86_64 Multilib Builds, isn't the 32 Bit Builds what I want?
Last edited by lich000king; 12-17-2013 at 07:28 AM.
For a hard-RT kernel to perform well the high presicion timer (HPET) should be activated in the kernel. But this feature is only available for a 32 bit kernel.
The option disappears in the kernel menuconfig as soon as 64 bit is deactivated.
If it was not for this option, I would go with 64 bit.
HPET _is_ activated when using x86_64.
This from the .config file for a x86_64 platform:
Code:
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
HPET entries in output of dmesg on my Intel x86_64 box:
Code:
[ 0.000000] ACPI: HPET 00000000bf78f4b0 00038 (v01 022410 OEMHPET 20100224 MSFT 00000097)
[ 0.000000] ACPI: HPET id: 0x8086a301 base: 0xfed00000
[ 1.065417] HPET: 4 timers in total, 0 timers will be used for per-cpu timer
Well that changes everyting.
The setting disappears from the menuconfig when activating 64 bit. But in this case I can use x86_64 and everything is fine.
1. What architecture is your host OS? x86_32 (iX86) or x86_64 (AMD/EM64T)?
If your host OS is 64-bit, building the standard LFS will require you built for AMD64/EM64T x86_64 architecture.
2. If your host computer or virtual machine, not the OS, is 64-bit, and you are running a 32-bit OS, provided you are running a 32-bit Host OS, did you make sure you used this command at the start of Chapter 6.14 GMP-5.1.2?
Code:
ABI=32 ./configure --prefix=/usr --enable-cxx
If you didn't pass this command when building GMP-5.1.2, then you might have to rebuild again.
Running defconfig on a 32-bit OS will result in a standard 32-bit kernel configuration, where-as on a 64-bit OS, running defconfig will result in a standard 64-bit kernel configuration.
1. What architecture is your host OS? x86_32 (iX86) or x86_64 (AMD/EM64T)?
Code:
root@debian:/# uname -a
Linux Debian 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux
So the host is x86_64 (it's Debian 7.1 64 bit.
Quote:
If you didn't pass this command when building GMP-5.1.2, then you might have to rebuild again.
Jhalfs takes the code directly from the books sources, so the command was used correctly.
I think, given that the Hith Presicion timer is actually active when I build a defconfig (x86_64) kernel, I can go with that.
I erroneously concluded there is no HPET in 64 bit because the option disappeared when I checked the 64 bit flag in the kernel config.
The ABI=32 trigger is only to be used for a 32-bit OS on 64-bit PC, not a 64-bit OS. If JHALFS used this trigger, then it failed completely.
Plus, last to my knowledge ALFS has not been updated for quite some time against the newer books documentation.
You really should maintain your own build scripts for LFS and BLFS. I've been writing my own based on the Slackware SlackBuild scripts scheme, dubbed by me as LFSBuild scripts. It's not completely all automated yet to where a full system can be built to my specifications, but it's just something to keep from having to screw up entering longwinded commands all the time.
You may actually want to recheck your scripts to make sure JHALFS did not pass this trigger on a 64-bit OS, because if it did, your build is completely screwed up and you'll have to start all over.
You may actually want to recheck your scripts to make sure JHALFS did not pass this trigger on a 64-bit OS, because if it did, your build is completely screwed up and you'll have to start all over.
Ok, I found the command used in /jhalfs/077-gmp:
Code:
./configure --prefix=/usr --enable-cxx
I.e. the ABI=32 bit is not passed (this is the default setting from the book, I misread earlier).
With the correct fstab file the system boots successfully in a virtual machine when I build the kernel with 64 bit.
So far everything looks good.
Then I restored the same system on a physical machine (HP workstation with Xeon CPU), the one I run virtual box on) and I get:
Code:
kernel panic - not syncing: VFS: Unable to mount root fs on unknown block (0,0)
I had Core2/Newer Xeon selected as CPU type, but it also happens with generic x86_64.
I am surprised about this. In particular, I get the same message when I rebuild the kernel on the physical machine.
The system freezes, I can't get any more useful info from the screen...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.