Tiny Core Linux
General TC => Tiny Core on Virtual Machines => Topic started by: rrajarajan on May 22, 2014, 12:24:56 PM
-
I am using microcore (Core-current for 5.3) in Virtualbox. I followed instructions from http://wiki.tinycorelinux.net/wiki:remastering to unpack and repack the ISO to run it in Virtualbox and am having problems with the repacked ISO not showing interface eth0
The core current boots up in Virtual box and shows eth0 and everything works (wrt IP connectivity).
The remastered ISO (with none of my changes, I just followed the directions on the wiki to unpack and repack) boots up fine in VirtualBox but there is no eth0.
ifconfig only shows lo.
ifconfig -a shows dummy0, ip_vti0-00, lo and tun10-00
There are no error messages in dmesg.
dmesg | grep eth - does not show anything
Other than the absence of eth0 the system comes up fine and things appear fine at the shell prompt for commands like ps, ls etc.
I have 2 VM's side by side (one with the remastered ISO and another using the original ISO) and other than the absence of eth0 in dmesg I don't notice any difference.
Could someone help? I assumed just a unpack/repack of the ISO should no have any affect on the run time behavior.
Am I missing something?
-
What extensions are loaded in the stock Core that works?
What extensions are loaded in the remastered Core that doesn't work?
Do you see any differences?
There is a reason that remastered versions are not supported. We have no idea what you have done.
-
You might want to read http://wiki.tinycorelinux.net/wiki:virtualbox
-
Err, is there a command to find the loaded extensions?
On both the original and remastered Core VM's there are no files in /usr/local/tce.installed/.
-
"losetup -a" will show you loaded extensions.
lsmod will show loaded modules.
I don't know what you might have changed, but if a proper depmod was not performed, you may not be loading the drivers in your remastered version that are being loaded in the unmodified version.
-
ls /usr/local/tce.installed
-
"losetup -a" will show you loaded extensions.
Not those copied to RAM
-
He claimed only an unpack and a repack. That would not have resulted in any extensions being loaded into RAM.
He did not mention extracting any extensions in the remaster, but then again he gave zero useful information.
-
"losetup -a" will show you loaded extensions.
lsmod will show loaded modules.
I don't know what you might have changed, but if a proper depmod was not performed, you may not be loading the drivers in your remastered version that are being loaded in the unmodified version.
losetup -a showed nothing for both original/remastered ISO's.
lsmod is different. For the remastered ISO lsmod is blank. For the original ISO lsmod shows 14 loaded modules for mperf, cpufreq_*, ppdev, ac, squashfs, parport_pc, parport, loop, microcode, e1000, pcspkr.
I think the depmod hint might be the key as I noticed the following print when running depmod
"""
depmod...
depmod: ERROR: fstatat(3, kernel.tclocal): No such file or directory
depmod: WARNING: could not open /tmp/extract/lib/modules/3.8.13-tinycore/modules.order: No such file or directory
depmod: WARNING: could not open /tmp/extract/lib/modules/3.8.13-tinycore/modules.builtin: No such file or directory
""
The command I used for depmod was
sudo depmod -a -b /tmp/extract 3.8.13-tinycore
where 3.8.13 was the kernel number I saw as all the files were in in /tmp/extract/lib/modules/3.8.13-tinycore
There are several module.* files there but no modules.order or modules.builtin, are these two files tool generated or should they have carried over from the original ISO.
Thanks
-
The wiki says:
sudo chroot /tmp/extract depmod -a 2.6.29.1-tinycore
You must use chroot because “depmod -b /tmp/extract” will not follow the kernel.tclocal symbolic link to find modules under /usr/local.
-
Ah, I did see that but ignored it as it said "If you are mastering 2.x where x <= 1'
Now I am getting
~/tinycore$ sudo chroot /tmp/extract depmod -a 3.18.3-tinycore
depmod: can't change directory to 'lib/modules/3.18.3-tinycore': No such file or directory
Even though the following works
~/tinycore$ sudo chroot /tmp/extract ls -l lib/modules/3.8.13-tinycore
total 32
drwxr-xr-x 8 root root 4096 May 22 17:39 kernel
lrwxrwxrwx 1 root root 46 May 22 17:39 kernel.tclocal -> /usr/local/lib/modules/3.8.13-tinycore/kernel/
-rw-r--r-- 1 root root 45 May 22 17:42 modules.alias
-rw-r--r-- 1 root root 12 May 22 17:42 modules.alias.bin
-rw-r--r-- 1 root root 0 May 22 17:42 modules.builtin.bin
-rw-r--r-- 1 root root 0 May 22 17:42 modules.dep
-rw-r--r-- 1 root root 12 May 22 17:42 modules.dep.bin
-rw-r--r-- 1 root root 52 May 22 17:42 modules.devname
-rw-r--r-- 1 root root 131 May 22 17:42 modules.softdep
-rw-r--r-- 1 root root 49 May 22 17:42 modules.symbols
-rw-r--r-- 1 root root 12 May 22 17:42 modules.symbols.bin
Why is depmod having problems when run inside chroot
-
Whoops, I had a typo. In one place I had 3.18.3 and 3.8.13 in another. Let me fix that and try it out.
-
YES, now it works after fixing my typo.
Could the wiki http://wiki.tinycorelinux.net/wiki:remastering (http://wiki.tinycorelinux.net/wiki:remastering) be fixed as it clearly says -
For versions 2.x where x >= 2 and later (replace the kernel uname with the right one):
sudo depmod -a -b /tmp/extract 2.6.29.1-tinycore
as that didn't work and the chroot approach was needed.
-
There's something else afoot, as a mere repack would not require a depmod run.
-
But running a depmod when not needed, and doing it incorrectly could cause the problem.
-
But running a depmod when not needed, and doing it incorrectly could cause the problem.
I think that is the case. I am testing it out again - both with and without depmod to see. Shall update soon.
-
But running a depmod when not needed, and doing it incorrectly could cause the problem.
Yes, that is correct. By skipping depmod the iso does boot up.
The root cause was the depmod that was done incorrectly in my script when things didn't work.
I had depmod in place so that things would continue to work if I added stuff to the core.
Thanks to all of you - I might not have narrowed it down to depmod at all.
Since the the VM booted up and there were no error messages I was stumped.