Tiny Core Linux
Tiny Core Base => Micro Core => Topic started by: lid on November 11, 2012, 09:37:36 AM
-
Hi,
I was able to pxeboot the microcore using vmlinuz as kernel and core.gz as initrd.
As far as I can see, the kernel is
tc@box:~$ uname -a
Linux box 3.0.21-tinycore #3021 SMP Sat Feb 18 11:54:11 EET 2012 i686 GNU/Linux
tc@box:~$
The questions are:
1. Is this the stock Linux kernel 3.0? Or has it been modified?
2. If it has been modified, where can I find the diff?
Thanks.
David
-
1. Is this the stock Linux kernel 3.0? Or has it been modified?
2. If it has been modified, where can I find the diff?
1) Yes. 2) with the other source files.
-
Hi lid
Check here:
http://distro.ibiblio.org/tinycorelinux/4.x/x86/release/src/kernel/
-
Hi lid
Check here:
http://distro.ibiblio.org/tinycorelinux/4.x/x86/release/src/kernel/
I got the linux-3.0.21-patched.txz. How do I find out about the diff from the stock kernel? Should I just run diff against stock 3.0.21? Or is there any document that describes the changes.
-
See the patches subdir there ;)
-
See the patches subdir there ;)
OK, got it.
I am trying to understand the magic why microcore can be booted up entirely in RAM. My kernel knowledge is limited. It seems to me that the tmpfs-root.patch is the key. This patch lets the ramfs to be used as root fs. Is this correct?
What I still dont' understand is how kernel knows to use ramfs on boot? In my pxeboot, the bootloader only has the following line:
APPEND initrd=tinycore/core.gz
It's not obvious to me that how the kernel determined to boot everything into RAM.
Can someone give me more pointers or explain a little bit more?
David
-
initrd stands for initial ramdisk.
Linux boots into RAM.
With most distros, the initrd mounts a new root file system and then switches to it.
Core skips this step, and continues to run in RAM.
-
For background, see Core Concepts, and the Distrowatch interview from a couple years back.
http://distrowatch.com/weekly.php?issue=20090323
-
initrd stands for initial ramdisk.
Linux boots into RAM.
With most distros, the initrd mounts a new root file system and then switches to it.
Core skips this step, and continues to run in RAM.
I want to play with it. Should I use config-3.0.21-tinycore as .config to recompile the kernel as 32 bit? If so, should I copy config-3.0.21-tinycore to .config and do a make oldconfig?
Thanks.
-
Yes, that works.
-
initrd stands for initial ramdisk.
Linux boots into RAM.
With most distros, the initrd mounts a new root file system and then switches to it.
Core skips this step, and continues to run in RAM.
A follow up question: Can a stock kernel also bypass mounting the root fs and directly boot into ram? Can this be done just by using kernel boot options like root=/dev/ram0?
-
Without telling the bootloader to load the initrd. there is no RAM filesystem to mount.
There is nothing particularly unique about Core's kernel.
-
Without telling the bootloader to load the initrd. there is no RAM filesystem to mount.
There is nothing particularly unique about Core's kernel.
I mean how about "initrd=core.gz root=/dev/ram0". Will this work with a stock kernel to boot into ram?
-
Go back and reread reply #6.
-
The links under chapter "initramfs" here:
http://www.landley.net/writing/
should pretty much cover the whole subject.
To me it looks like the patch is replacing ramfs with tmpfs, though from what I had read I had always understood that tmpfs could be enabled without a patch, so I am not really sure about that.
-
The links under chapter "initramfs" here:
http://www.landley.net/writing/
should pretty much cover the whole subject.
To me it looks like the patch is replacing ramfs with tmpfs, though from what I had read I had always understood that tmpfs could be enabled without a patch, so I am not really sure about that.
Thanks for the link. Looks it has a lot of good info.
I recompiled the tinycore kernel and on pxeboot, it immediately hit the following line:
panic("No init found. Try passing init= option to kernel. "
"See Linux Documentation/init.txt for guidance.");
I kind of suspect my kernel didn't unpack the initrd cpio file correctly so it couldn't find the init script to run. Does anyone have any suggestions where to look?
-
Show your pxe entry.
See the network booting examples in the wiki.
-
Show your pxe entry.
See the network booting examples in the wiki.
Which pxe entry? pxelinux.cfg/default?
It boots ok if I just use the TC kernel and core.gz.
It only failed when I compiled the kernel downloaded from linux-3.0.21-patched.txz and config-3.0.21-tinycore. It must be something missing from my own config and compiling process.
-
Did you update the cpio archive to reflect changes of modules?
-
Why are you recompiling the kernel?
-
Did you update the cpio archive to reflect changes of modules?
Don't quite understand this. What module is changed?
-
Why are you recompiling the kernel?
Must want to understand the TC kernel patch by playing it.
-
Did you update the cpio archive to reflect changes of modules?
I am not sure I understand your point.
I don't really want to change any kernel modules but maybe accidentally I did it by running make oldconfig using the downloaded config file. There is indeed a diff for .config after make oldconfig. But I am not sure how I need to update cpio.
Can you explain?
-
Noone could possibly ever guess what you did without you providing exact documentation...
Your safest bet might be to follow regular procedure of installing different kernel.
-
Noone could possibly ever guess what you did without you providing exact documentation...
Your safest bet might be to follow regular procedure of installing different kernel.
Here is what I did step-by-step. Prior to these, I was able to pxeboot the microcore with vmlinuz and coregz as initrd.
1. download linux-3.0.21-patched.txz, unpack to a directory linux-3.0.21/
2. download config-3.0.21-tinycore and copy it to linux-3.0.21/ as .config
3. cd linux-3.0.21/, do make oldconfig and accept all defaults
4. make
5. copy linux-3.0.21/arch/x86/boot/bzImage to tftpboot/ directory as vmlinuz (overwrite the previous one)
6. try pxeboot again.
Anything I might have missed in the above?
-
"accept defaults" sounds wrong, as the config is for the same version, it should ask nothing.
-
"accept defaults" sounds wrong, as the config is for the same version, it should ask nothing.
I was also wondering too about this. make oldconfig with the existing .config should be enough. But maybe the kernel source doesn't match the config file.
Can I just do make without "make oldconfig"?
-
It does match, if you grabbed the same versions (3.0.21 instead of 3.0.3). Something in your environment is weird.
One of the *config targets is necessary; if you don't run any of them, the makefiles will run oldconfig for you.
-
You could run a diff between some newly built modules and their correspondent ones in stock cpio archive.
-
It does match, if you grabbed the same versions (3.0.21 instead of 3.0.3). Something in your environment is weird.
One of the *config targets is necessary; if you don't run any of them, the makefiles will run oldconfig for you.
Ok, I made some progress. I ran make oldconfig using the 64 bit config file and this time it passed without asking questions. So I rebuilt the kernel and pxebooted. This time there is no kernel panic. However the problem now is the boot process stops after this:
modprobe: chdir (3.0.21-tinycore 64+) No such file or dir
...
Switching to clocksource tsc.
Maybe I am missing some modules in the initramfs ?
David
-
You could run a diff between some newly built modules and their correspondent ones in stock cpio archive.
I know the initramfs (inside original core.gz) modules live in lib/modules/3.0.21-tinycore/kernel/. But I am not sure where those corresponding modules live inside the kernel tree after compile.
Plus, I am rebuilding the kernel with 64 bit support. The original core.gz is 32 bit. So how can I make sure which modules need to be updated in the initramfs for the rebuilt kernel?
-
I know the initramfs (inside original core.gz) modules live in lib/modules/3.0.21-tinycore/kernel/. But I am not sure where those corresponding modules live inside the kernel tree after compile.
From this: modprobe: chdir (3.0.21-tinycore 64+) No such file or dir
..I'd say you need to put the modules in /lib/modules/3.0.21-tinycore 64+
-
You mustn't mix up 64bit with 32bit of base or module extensions.
http://wiki.tinycorelinux.net/wiki:remastering
-
You never mentioned what you were building on ;)
We assumed TC 32-bit, but it seems you're building on something else 64-bit?
-
You never mentioned what you were building on ;)
We assumed TC 32-bit, but it seems you're building on something else 64-bit?
sorry about that. yes, my build machine is 64 bit.
I think originally I used the stock 32 bit microcore kernel and initramfs to pxeboot. Now I am trying to compile the kernel myself on a 64 bit machine. If I want to stick to the 32 bit, then what I should have done is this:
make oldconfig ARCH=x86
make ARCH=0x86
Hopefully this recompiled 32-bit kernel will be able to use the original core.gz without issues.
I am trying this now, will let you know.
David
-
You never mentioned what you were building on ;)
We assumed TC 32-bit, but it seems you're building on something else 64-bit?
sorry about that. yes, my build machine is 64 bit.
I think originally I used the stock 32 bit microcore kernel and initramfs to pxeboot. Now I am trying to compile the kernel myself on a 64 bit machine. If I want to stick to the 32 bit, then what I should have done is this:
make oldconfig ARCH=x86
make ARCH=0x86
Hopefully this recompiled 32-bit kernel will be able to use the original core.gz without issues.
I am trying this now, will let you know.
David
All right, finally a success!
The kernel needs to be recompiled as 32 bit on the 64 bit machine with ARCH=x86. This way it can take advantage of the existing core.gz. A good learning experience for me and thanks everyone to the help!
I am always wondering about the secret sauce - how the TC initramfs root file system was created. Anyone knows if there is a more detailed reference on that?
-
Rob Landley of Busybox gave talks about this. Search the internet will likely produce, But that was 5+ years ago.
Now most any book on embedded Linux will have a chapter or two on the subject. The concept has been around for a very long time.
If you focus on the embedded area of Linux you will likely find much reference.
EDIT: See http://busybox.net/~landley/ols2006/presentation.txt