Tiny Core Linux
Tiny Core Base => TCB Q&A Forum => Topic started by: yetanotherusername on May 02, 2011, 03:41:51 PM
-
I know there are many posts on this subject because I have combed through them but nothing really to solve my issue. I still don't know how find out if this is a problem that requires a driver or extension. So far I tried dmesg | grep eth0 (and e100) but nothing comes back.
I am using a fork of microcore called mine os+ for hosting minecraft server. I had a lot of succes on vmware to install and run so I ran out and got myself a dedicated server and since it was quite the custom install, they gave me remote access through DRAC for a Dell PowerEdge R410, Bios v 1.1.5, I don't know details on the network adapter, but I've been told that the eth0 port is up and ready for usage, I have 5 ip addresses.
ifconfig only returned lo, now it returns dummy0 and lo, looks like support tried a few things to make it work, looks like scripts for configuration files like /etc/resolv.conf. and commands like route add default gw xx.xx.xx.xx
I've read that there are no configuration files in tiny core, per se.
Support there suggests using ifup eth0 and proper configuration fies are populated but ifup: command not found :-P
Pretty lost at this point, but I'm invested to make this work.
-
Ifconfig -a should show you your interfaces.
You probably will have to write your own network startup scripts.
Forked OS suppliers must do their own support.
-
You need to determine what ethernet adapter you have. There are several available for the PowerEdge R410 (http://i.dell.com/sites/content/shared-content/data-sheets/en/Documents/R410-Spec-Sheet.pdf) (pdf). For example, the Broadcom NetXtreme II 5716 (http://pci-ids.ucw.cz/read/PC/14e4/163b/1028028c) is supported by Tiny Core, so I am guessing you don't have that. It may be that you have a NIC which is too new, but we need the PCI ID to solve your problem.
You need to find a way to load the pci-utils extension. This includes the "lspci" program which will tell you what you have. Simply run "lspci" to display all devices. Executing "lspci -d 8086:" will list all Intel devices and "lspci -d 14e4:" will list all Broadcom devices. After you have identified which PCI device is your network interface, use "lspci -n" to display the PCI ID. For example:
# lspci -d 14e4:
06:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5761 Gigabit Ethernet PCIe (rev 10)
# lspci -n -d 14e4:
06:00.0 0200: 14e4:1681 (rev 10)
-
I found the extension pci-utils.tcz and downloaded it, then "burned" to an image file and remotely used the virtual media manager on DRAC which is basically a usb device for a virtual dvd.
sudo mount -t udf -r /dev/sr0 /mnt/sr0
sudo cp /mnt/sr0/pci-utils.tcz /mnt/sda1/tce/optional/pci-utils.tcz
guess what...? overwrite? ::)
Okay, so I don't have app browser, but the command line version of Appbrowser can be started using the ab command, but all I get is an empty list to choose from
and applications can also be loaded using terminal commands. 1. tce-run pci-utils 2. tce-load -i pci-utils 3. tce-load -is pci-utils
but all this returns mount: mounting /dev/loop42 on /tmp/tcloop/pci-utils failed: Invalid argument
At this point I am done with a pot of coffee and need to brew more.
Thanks for pointing me so far, love the learning process.
-
Note: you will also need the libpci.tcz file on your image file as well.
For temporary use, it is sufficient to load the extensions from the virtual CD:
tc@box:~$ tce-load -i /mnt/sr0/libpci.tcz
/mnt/sr0/libpci.tcz: OK
tc@box:~$ tce-load -i /mnt/sr0/pci-utils.tcz
/mnt/sr0/pci-utils.tcz: OK
You should then be able to run lspci.
-
hmmm, wasn't easy to find libpci.tcz, as it is listed in the repository, so I could download libpci.tcz from http://distro.ibiblio.org/tinycorelinux/3.x/tcz/libpci.tcz, but it is not listed in any mirrors that I went to from http://wiki.tinycorelinux.net/wiki:install_apps
I am curious where the deb file is, I could have looked at the dependencies list.
Anyway, I got this far:
tc@box:~$ tce-load -i /mnt/sr0/libpci.tcz
/mnt/sr0/libpci.tcz: OK
tc@box:~$ tce-load -i /mnt/sr0/pci-utils.tcz
mount: mounting /dev/loop43 on /tmp/tcloop/pci-utils failed: Invalid argument
maybe just a little more hand-holding to get me through? thanks!
-
tc@box:~$ tce-load -i /mnt/sr0/pci-utils.tcz
mount: mounting /dev/loop43 on /tmp/tcloop/pci-utils failed: Invalid argument
This error means that pci-utils.tcz is not a valid file. Try re-downloading it. I didn't ask before, but have you tried booting from the tinycore iso image over this virtual CD connection?
-
re-downloading and a reboot and mounting the dvd again did the trick, I'm at the point I know its a Broadcom Corporation NetXtreme II BCM5716 Gigabit Ethernet (rev 20) device, as a matter of fact, two of them, 01:00.0 Ethernet controller and 01.00.1 Ethernet controller.
tc@box:/mnt/sr0$ lspci -n -d 14e4:
01:00.0 0200: 14e4:163b (rev 20)
01:00.1 0200: 14e4:163b (rev 20)
As far as booting tinycore (microcore) from this virtual CD connection, it is where I originally booted from onto a cleaned harddrive, all remotely through DRAC (Dell Remote Access Controller), then ran some scripts to create the partitions, some file paths, and finally removed the virtual dvd and rebooted with another script whose purpose was to make everything persist as far as setting up passwords and such, and now booting with grub, but no eth0 device found. It is essentially microcore OS as far as I can tell, with some added core files and extensions.
If you want to play with it, I can even give remote access, it has its own ip address and even connects to the dedicated server if its powered off. I was able to run DOS tools, etc., all remotely. Quite user friendly too. For anyone interested, it is presented on youtube http://www.youtube.com/watch?v=gz60zgxqwRM (http://www.youtube.com/watch?v=gz60zgxqwRM).
-
re-downloading and a reboot and mounting the dvd again did the trick, I'm at the point I know its a Broadcom Corporation NetXtreme II BCM5716 Gigabit Ethernet (rev 20) device, as a matter of fact, two of them, 01:00.0 Ethernet controller and 01.00.1 Ethernet controller.
tc@box:/mnt/sr0$ lspci -n -d 14e4:
01:00.0 0200: 14e4:163b (rev 20)
01:00.1 0200: 14e4:163b (rev 20)
Tiny Core should support this NIC then. So you are saying you booted a recent version of Tiny Core (not the minecraft image) and it did not work?
-
I have only booted from the minecraft image, which is based on microcore 3.5
-
Then it appears this minecraft image does not contain the necessary driver. You can confirm this by:
1) Booting the microcore 3.6 image to confirm you have a working eth0, and
2) Look in /lib/modules/2.6.33.3-tinycore/kernel/drivers/net for your driver: bnx2.ko.gz.
Do both, and reply with your results. If the minecraft image does not have the driver, you must petition the creator to restore it.
-
booting from microcore-current.iso, I still don't get eth0, from dmesg I caught:
bnx2 0000:01:00.0: firmware: requesting bnx2-mips-09-5.0.0.j3.fw
bnx2: Can't load firmware file "bnx2/bnx2-mips-09-5.0.0.j3.fw"
I dunno
-
some more info from dmesg | grep bnx2
Broadcom NetXtreme II Gigabit Ethernet Driver bnx2 v2.0.3 (Dec 03, 2009)
bnx2 0000:01:00.0: PCI INT A -> GSI 36 (level, low) -> IRQ 36
bnx2 0000:01:00.0: setting latency timer to 64
bnx2 0000:01:00.0: firmware: requesting bnx2-mips-09-5.0.0.j3.fw
bnx2: Can't load firmware file "bnx2/bnx2-mips-09-5.0.0.j3.fw"
bnx2 0000:01:00.0: PCI INT A disabled
bnx2: probe of 0000:01:00.0 failed with error -2
Then it repeats, but with PCI INT B and IRQ 48
-
booting from microcore-current.iso, I still don't get eth0, from dmesg I caught:
bnx2 0000:01:00.0: firmware: requesting bnx2-mips-09-5.0.0.j3.fw
bnx2: Can't load firmware file "bnx2/bnx2-mips-09-5.0.0.j3.fw"
I dunno
That was the other possibility, which is good because this file is part of the firmware.tcz extension. You can make this work, but you need to incorporate that extension into your minecraft image/installation.
-
man, I am so close I can taste it. I have both files in my /mnt/sda1/tce/optional directory and tried sudo filetool.sh -b, tce-load -i firmware.tcz (and firmware-2.6.29.1-tinycore.tcz) and then I reboot but still the same issue. I don't have the AppBrowser but I'm working from the command line. I need to know how to make this work with terminal commands, but I can't seem to get my head wrapped around how to do that.
I can see now that my problem is related to the other posts on this issue, but it seems they all had AppBrowser, local or whatever, I just have a terminal.
-
make sure firmware.tcz in listed in /mnt/sda1/tce/onboot.lst. However, you will still get a firmware error on bootup because the extension isn't loaded yet. If you execute "sudo udevadm trigger" it will attempt to reload the driver.
If you are booting with syslinux instead of grub, you can load the firmware at the proper time by adding it to /tmp/tce in a cpio archive:
mkdir -p /tmp/tce/optional/
cp /mnt/sda1/tce/optional/firmware.tcz /tmp/tce/optional/
echo firmware.tcz >> /tmp/tce/onboot.lst
find /tmp/tce | cpio -o -H newc | gzip -9 > /tmp/firmware.gz
Then put this firmware.gz in the same directory as your microcore.gz and add it to your syslinux.cfg initrd option. If you are using grub, then the process is a little more involved:
mkdir -p /tmp/tinycore/
cd /tmp/tinycore/
zcat /mnt/sda1/boot/microcore.gz | cpio -id
mkdir -p tmp/tce/optional/
cp /mnt/sda1/tce/optional/firmware.tcz tmp/tce/optional/
echo firmware.tcz >> tmp/tce/onboot.lst
find . | cpio -o -H newc | gzip -9 > /tmp/microcore.gz
-
Using grub.
adapted a couple of the commands to sudo, but at the final line,
find . | cpio -o -H newc | gzip -9 > /tmp/microcore.gz
cpio: can't open 'usr/bin/sudo" : Permission denied
---s--x--x and root:root is what the permission/owner is set at (s = Unix domain socket) ???
-
sorry, a "sudo su" at the beginning should solve your problems. rm -rf /tmp/tinycore and try it again. Be careful to type it exactly as it appears (assuming your microcore.gz is in /mnt/sda1/boot):
sudo su
mkdir -p /tmp/tinycore/
cd /tmp/tinycore/
zcat /mnt/sda1/boot/microcore.gz | cpio -id
mkdir -p tmp/tce/optional/
cp /mnt/sda1/tce/optional/firmware.tcz tmp/tce/optional/
echo firmware.tcz >> tmp/tce/onboot.lst
find . | cpio -o -H newc | gzip -9 > /tmp/microcore.gz
-
That will not run as ascript.
The "sudo sh" will start its own subshell,
and on exit the user will be back to tc at the second line.
-
that went through okay, no errors
now I can just reboot? or do I have to use filetool.sh -b or any other persistence measure?
(i'm on the edge of my seat, :-\ btw)
I just went line by line, I'm still root@box:/tmp/tinycore#
-
Don't reboot yet, you need to copy /tmp/microcore.gz over your old one (but make a backup first!). I didn't explicitly state that because I wasn't sure how far you'd get.
-
alright
mv /mnt/sda1/boot/microcore.gz /mnt/sda1/boot/microcore_bak.gz
cp /tmp/micorcore.gz /mnt/sda1/boot/microcore.gz
done
anything else? :)
-
alright
mv /mnt/sda1/boot/microcore.gz /mnt/sda1/boot/microcore_bak.gz
cp /tmp/micorcore.gz /mnt/sda1/boot/microcore.gz
done
anything else? :)
You've got it. When you reboot, it should all be good.
-
Ah, sorry. I had a typo in my instructions to you. It should be:
sudo su
mkdir -p /tmp/tinycore/
cd /tmp/tinycore/
zcat /mnt/sda1/boot/microcore.gz | cpio -id
rm -rf tmp/tce
mkdir -p opt/tce/optional/
cp /mnt/sda1/tce/optional/firmware.tcz opt/tce/optional/
echo firmware.tcz >> opt/tce/onboot.lst
find . | cpio -o -H newc | gzip -9 > /tmp/microcore.gz
cp /tmp/micorcore.gz /mnt/sda1/boot/microcore.gz
The /opt/tce directory is a special directory from which extensions are loaded before network initialization begins. The underlined step is to remove the mistake from earlier.
-
I noticed that onboot.lst in opt/tce was a little scarce, then read up on that /opt/.tce_dir has the path to where the onboot.lst file should go, and I made the necessary changes to add firmware.tcz (as well as firmware-2.6.29.1-tinycore.tcz) to onboot.lst, which was in /mnt/sda1/tce
Still no eth0, but if I try to tce-load -i firmware.tcz it says its already installed. I noticed that I can add a command line while grub is loading the OS, don't know if there is anything I can do there, and in the meantime I have over 30 tabs open on chrome and another dozen or on firefox on another monitor searching out forums. In the meantime I am at least getting very familiar with the file system in tinycore.
-
Is there any way to confirm that the missing firmware file, bnx2/bnx2-mips-09-5.0.0.j3.fw is actually included in the firmware.tcz extension?
-
Is there any way to confirm that the missing firmware file, bnx2/bnx2-mips-09-5.0.0.j3.fw is actually included in the firmware.tcz extension?
Execute "unsquashfs -l firmware.tcz" to show the files in it.
I noticed that onboot.lst in opt/tce was a little scarce, then read up on that /opt/.tce_dir has the path to where the onboot.lst file should go, and I made the necessary changes to add firmware.tcz (as well as firmware-2.6.29.1-tinycore.tcz) to onboot.lst, which was in /mnt/sda1/tce
There are two extension locations in TC: The /opt/tce directory and the directory pointed to by /opt/.tce_dir. The extensions in /opt/tce are loaded before network initialization in order to load firmware or other drivers. The extensions in your regular tce directory are loaded later. The instructions in my last post should get you going. If the firmware extension is loaded, you should have an eth0. Check dmesg after loading the extension and see if there is a new message.
I sent a note to wdchromium, recommending he add firmware and scsi drivers to his setup in order to prevent these sorts of issues.
In the meantime I am at least getting very familiar with the file system in tinycore.
If you are really interested, read the /etc/init.d/rcS script. It is the script executed during bootup and contains a wealth of information.
-
Check dmesg after loading the extension and see if there is a new message.
The message persists to say that the firmware can't be loaded, same message.
I compared the two boot.lst files (/opt/tce and /mnt/sda1/tce) and noticed the permissions were different between them but changing them in opt/tce didn't "stick" on reboot, if that is even an issue, it is -rw-r--r--, compared to -rwxrwxr-x respectively. Also ownership of the former is root:staff compared to tc:staff, but my guess it should be getting read by the system anyway. Maybe the whole path needs to change permissions? I don't think this /opt/tce path even existed before we created it.
-
The message persists to say that the firmware can't be loaded, same message.
The module may need to be reloaded. Execute:
rmmod bnx2
modprobe bnx2
I compared the two boot.lst files (/opt/tce and /mnt/sda1/tce) and noticed the permissions were different between them
I've never had to worry about the permissions of /opt/tce files. They are never written, so it should be fine. I typically "chown -R tc:staff /opt/tce" but I don't think it matters.
I don't think this /opt/tce path even existed before we created it.
Yes, it does not exist by default.
-
I had written earlier to the hosting company that I got the dedicated server from and explained my situation. The fact is, I tried a couple different distros, including debian 6 and got back complaints about the firmware needed to be loaded. Before I could try to reload the module, I was put on a HP DL160 G6 instead.
I don't know how its going to go there, but even if it goes smooth, I will continue to play with tinycorelinux on my vmware to build on what I've learned here, thanks you, danielibarnes, of course.
I don't want to play minecraft as much as I wanted to play with linux and it just seemed like a good learning opportunity to work with something that gave me a project where some friends depended on it working (the minecraft part).
You gave me really good insight and few things to chew on meanwhile, thanks again.
-
Before I could try to reload the module, I was put on a HP DL160 G6 instead.
The HP ProLiant DL160 G6 has an "HP NC362i Integrated Dual Port Gigabit Server Adapter" which uses the "Intel(R) 82576 Gigabit Dual Port Server Network Connection." The PCI ID is probably 8086:10E7, and is supported (http://lxr.free-electrons.com/source/drivers/net/igb/e1000_hw.h?v=2.6.33#L42) in Tiny Core by the igb kernel module.
-
It seems that is also uses cciss driver with hp Smart Array controller in the hp ProLiant server, which means I don't see my hard drive as /sda1. Instead it is not even mounted and can't be found. There is no hard drive detected as far as I can tell, with what I know.
A /cciss/c0d0 exists which I have only been able to determine through some DOS partitioning tools, which how I came to know about the smart array controller.
Should I start another thread? or try to get another server (I think they might give me a Supermicro, its the only other brand they have) :-\
-
Again, best to check the PCI ID of the device using lspci to identify it. The HP SmartArray P410 (http://h10010.www1.hp.com/wwpc/us/en/sm/WF06a/15351-15351-3328412-241644-3328421-3884343.html) is 103c:3243, supported by the hpsa module (http://lxr.free-electrons.com/source/drivers/scsi/hpsa.c?v=2.6.33#L106). Per instructions in the Debian Wiki (http://wiki.debian.org/HP/ProLiant#line-65), you may need to add a file "/etc/modprobe.d/cciss_allow_hpsa.conf" containing the single line "options cciss cciss_allow_hpsa=y". I am unsure because it doesn't appear that Tiny Core has the cciss module anyway.
As soon as you confirm the scsi-2.6.33.3-tinycore extension works, you can install minecraft and re-create your microcore.gz to include it like you did for firmware.tcz:
sudo su
mkdir -p /tmp/tinycore/
cd /tmp/tinycore/
zcat /mnt/sda1/boot/microcore.gz | cpio -id
mkdir -p opt/tce/optional/
cp /mnt/sda1/tce/optional/scsi-2.6.33.3-tinycore.tcz opt/tce/optional/
echo scsi-2.6.33.3-tinycore.tcz >> opt/tce/onboot.lst
find . | cpio -o -H newc | gzip -9 > /tmp/microcore.gz
cp /tmp/micorcore.gz /mnt/sda1/boot/microcore.gz
-
I didn't know the vendor id to use with lspci -n so I did lspci -nn and it just listed all the devices including the PCI IDs and determined:
07:00.0 RAID bus controller [0104]: Hewlett-Packard Company Smart Array G6 controllers [103c:323a] (rev 01)
I loaded the extension with tce-load -i scsi-2.6.33.3-tinycore.tcz and fdisk -l showed the 500Gb hard drive and sda was detected, but trying to install mine os with its included scripts seemed to have problems when cfdisk ran, so i partitioned the harddrive in advance with another tool before booting back up to mine os. But it seemed to skip over copying files and another script to check file paths afterward produced only a screen full of:
SQUASHFS error: Unable to read data cache etnry [xxxxx]
SQUASHFS error: Unable to read page, block xxx, size xxx
SQUASHFS error: squashfs_read_data failed to read blcock 0x....
I'm pretty sure there is no support for scsi drives and this falls under that domains somewhere.
At this point I am going to request that Supermicro system and return back to this issue about supporting scsi and related things. I am thinking after I get this working (somewhere) and perhaps I found a niche where I can contribute to development of a linux distro, something I've wanted to do but never really had a project to try to make work. Getting this to work on this HP just feels a little out of reach right now.
-
Getting this to work on this HP just feels a little out of reach right now.
I agree. It is possible, but nontrivial. I can assist with getting microcore to work, and you've done that. Anything else requires wdchromium's help. He has a forum for that purpose; I'd suggest posting there to let him know your story.
-
I'm now maintaing [remaster]+ and I'm at a loss as to why SCSI support just isn't working.
I've tried following both the instructions above, on the wiki (both cat and pack and repack), all of which produce a useable microcore.gz which boots properly from a cd, loads all required extensions, and correctly detects, mounts and allows read/write access to any SCSI drives through the bus logic controller.
When Microcore is subsequently rebooted after copying (successfully) all the extensions, boot items e.t.c. onto the SCSI hdd, it boots as normal up until the extensions are loaded, at which point it fails ... no extensions are loaded, the SCSI disk (sda1) is shown to be blank, and the SCSI drivers are shown to be loaded (tce-load -wi scsi...... shows 'already installed!')
If it's of any significance, we are still running the micro core_3.6 intrid.
Any help would be much appreciated.
Nick
-
I'm at a loss as to why SCSI support just isn't working.
Since it is definitely off-topic here, I'll PM you with assistance.