Adding firmware and utils to MC initrd?

[firestorm_v1]

Hello all:

I'm trying to build a customized version of MicroCore to assist in re-imaging recycled computers from a master image however I'm running into some trouble.  Hopefully it's just a matter of my research missing that something.   These recycled computers are hardware-identical to one of two versions that are minimally different (namely the existence of a RAID card) however a few questions/concerns have come up:

1)  Is it possible to insert/compile the firmware for the Broadcom BCM5716 NIC into the kernel so that the networking will start when microcore boots?  I am somewhat comfortable with compiling custom kernels however I've not had to mess with firmwares until this project.  Is there a .config file I can download that contains the existing kernel's conf so I can just add/remove what I need or a howto describing how to build a kernel for microCore?

2)  The imaging application makes use of /dev/disk/by-label/#### where #### can be "ROOT" "BOOT" "VAR", etc...  I noticed that the current version of microCore doesn't support this method just yet. as only /dev/disk/by-path is the only directory that is populated I'm guessing that this would have to be added to the kernel?

3) Is there a way to include parted and lspci into the initrd image rather than including it from a USB stick?  I do not need to store any data during the imaging session and would prefer not to have to swap a USB stick between machines.

The issue is that I am using MicroCore in a PXEboot environment and it works very well however due to a lack of firmware, the network interface can not route or get an IP address from a DHCP server. With no way to get the image, I can't reimage the computers. I am not concerned with storage of the session post-image, I just need to figure out the remaining bits of the puzzle. 

Thank you in advance for any assistance.


[Mods], If this is the wrong place for this thread, please feel free to move it to a more suitable location.

[gerald_clark]

You can't be using PXEboot with Wireless.
If you have wired, you can PXEboot, and install whatever you need from the network, including firmware.
For this you do not need to build a new initrd.

[firestorm_v1]

Hello Gerald:

Thank you for your reply.  The BCM5716 NIC mentioned in my post is NOT a wireless card, it is a Gigabit Ethernet adapter. The PXE environment works as I can boot into MicroCore but due to the missing firmware, once the kernel takes over from PXEboot, I can not route nor get a DHCP lease.  The kernel prints an error on boot citing the missing firmware however it is too fast for me to screen capture it.

After rebooting the device several times, it looks like the error is below:
"bnx2: Can't load firmware file "bnx2/bnx2-mips-09-6.2.1a.fw"

[gerald_clark]

You can make a gz out of the firmware, and have PXE load the initrd=core.gz,firmware.gz.
This way you can update core.gz and do not have to remaster.

You can also cat the firmware.gz onto the end of core.gz ( cat core.gz firmware.gz > mycore.gz ).

[curaga]

2) is udev, mainly that we don't ship the additional binaries and rules that depend on them. The additional binaries can be found in the udev-extra extension IIRC, the rules in the udev 173 source tarball.

If you are not familiar with udev rules, it may be easier to create those symlinks yourself (blkid knows the device labels).

3) yes, by extracting the extension(s) to an initrd, or including them as tcz files and loading in a script. ezremaster can also be used, it supports both methods.

[firestorm_v1]

Sorry for taking so long to get back to you both. Thank you for your input.  I'm going to give it a shot and see what happens.

My biggest issue currently is where to get the extension from without having to rely on Tinycore (because I need an extension to get the firmware to initialize my NIC, but my NIC has to work before it will init)

Remastering the initrd is unavoidable simply because I have utilities that must be present in the PXEboot environment. Plugging in a USB stick is just not feasible for what I am needing to deploy.

I will update this thread later on with my progress.  If you have any suggestion on where/how to download the extensions without using the tinycore extension manager, please advise.

As always, thank you for your time.


EDIT:  I think ezremaster will give me all the options I'm looking for and will allow me to cook the initrd to have what I need.  I just got to remember to use "Add to initrd on boot" and make sure I include the firmware-bnx2 package.

Wish me luck!

[Rich]

Hi firestorm_v1
You can find extensions for 4.x here:
http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/4.x/x86/tcz/
Depending on your connection speed, the page may take a minute or two to load due to the large
number of extensions listed. If you are doing this from a Windows environment, save what you
need to a FAT base file system.

[firestorm_v1]

Hello Rich:

Thank you for the informaiton, I went ahead and cached what I needed for this project.  I have my custom PXE-bootable MicroCore image and it works.  The only issue is that I have now is that I keep getting "Firmware Warn: GHES: Failed to read error status block address for hardware error source (49376, 49377 or 49378)."

The OS appears usable however I don't know how to suppress these error messages.

I'm not sure what on a kernel level is different between MicroCore OS and the MicroCore OS that i rolled with ezremaster, but one works perfectly, and the other works with the exception of the errors endlessly scrolling. 

Any suggestions?

[Rich]

Hi firestorm_v1
I don't suppose these recycled machines are Dells with 64 bit processors by any chance.
Anyway, even though I don't see it documented here:
http://www.mjmwired.net/kernel/Documentation/kernel-parameters.txt
you could try the boot code   ghes.disable=1   and see if that makes any difference.
Alternatively, if you are feeling adventurous, and you are running 64 bit Dell hardware, you could
try the 64 bit kernel instead.

[firestorm_v1]

Hello Rich:

You are correct, a vast majority of the machines to be recycled are Dells and do have 64 bit procs.  I came across the same boot code however it had no effect on the firmware warning messages.  The thing that I find especially weird is that none of the Core OSes will generate errors as long as the broadcom firmware isn't added.  As soon as it's added in however, GHES goes nuts.

I wonder if it's possible to disable ACPI in the kernel (which would fix the GHES errors as research indicates that it is a part of the ACPI subsystem in the kernel.).  Also, research shows that this issue appears to be a kernel issue as opposed to a distro-specific issue.

I'll try disabling ACPI and will post results here. Since the target machine will only be on long enough for the image to download and scrub the drive, I don't think that ACPI is needed.  If this was a running production machine, I would have to find another way around. 

[firestorm_v1]

Well, I'm happy to announce that it works!

Disabling ACPI at boot (acpi=off) does the trick and results in a quiet terminal.  I'm not sure why, but the GHES boot option (ghes.disable=1) did nothing to change the output in the terminal.

Now it's just a bit of scripting and adding the utils I need to the CoreOS image using ezremaster and I'll be all set.  Thank you again for all your help!