Need to boot from 3.0 kernel

[jhd0044]

I have been pulling my hair out recently. I have some new machines which I want to image, and they are using a network adapter which does not have driver support in the 2.6 image shipped with fog 0.32.

There are 3.x kernels available via upgrade, and I can make custom kernels.

However… I do not know how to work with the initial ram disk image. The boot arguments for 2.6 do not work for 3.x, and I’m not sure what to use. I heard somewhere that the initrd format (compressed filesystem) has been replaced with initramfs (compressed cpio archive), and I can create/boot those. Well sorta…

I used the busybox shipped with 0.32, and it wants 2.6 style configuration files. I have tried to create those, but am running in circles. Currently the network driver is not loading – the card enumerates (I see it in lspci), but dmesg does not show the driver. I have compared the dmesg output with that from a Fedora 19 system (running 3.9.9 kernel).

I was hoping that the e1000e driver would be statically linked in the kernel – the driver is selected in the config. But nothing starts. I have a loadable kernel module from a production machine, but busybox says that it is in the wrong format.

Can someone please suggest how I can proceed. Is there a ramdisk usable by a 3.x kernel available? And if I need to create one, what is the quickest way to go about it – modifying the 2.6 image / modifying the initramfs which ships with 3.x?

I am currently experimenting with a Frankenstein disk image (a combo of 3.x and 2.x), but am throwing in the towel so to speak. I need to get that driver to load/start.

Please help. Every day that goes by I am doing uglier and uglier things to Linux.

[Tom Elliott]

I’ve not noticed an issue with 2.6 headers and 3.X kernels. We use 0.32 on our systems and have tested kernels all the way up to 3.10.7 (so far as I’m currently building 3.10.9)

It seems to me, possibly, that you’ve got a custom init.gz file? I don’t know all of those details.

I’ve been building my own custom init.gz for use with FOG 0.33b and the option for cpio filesystem is unchecked, with the 0.33b REV 899 fog.buildroot.config file. I’ve not tried using cpio enabled in my building, but I don’t think all of your information is correct. The init.gz files compressed, but not with cpio. It’s compressed with gzip.

The quickest way to modify the init.gz file system is to:
cd /tftpboot/fog/images; gunzip init.gz; mkdir tmp; mount -o loop init tmp

Once completed with your modifying the files in init.gz You will simple perform
umount tmp; gzip -9 init

[jhd0044]

Thanks for the reply, it is great to have someone else to talk to. I’ve been at this for a few days. I didn’t mean to suggest that cpio was used to compress, but that initramfs is a cpio archive which has been gzipped (not a filesystem like initrd)

However… if it is possible to boot 3.10 with the stock init.gz then I’m happy. Let me summarize a couple of experiements.

The stock bzImage with the stock init.gz hangs with a green screen. The last message was a normal PCI bridge message. I have no clue what the problem is.

A production 3.9.9 kernel with the stock init.gz panics after mounting the root filesystem. (This is what led me to suspect initrd=)
This is using the same kernel parameters as in the previous test (I just changed the symbolic link for bzImage to point to a 3.99 kernel and rebooted). I’m not sure if there is a problem with the filesystem. The last entry in the trace is for “rest_init”. There is no init in the image, but there is linuxrc linked to bin/busybox.

I have been able to boot 3.9 with a gzipped cpio archive (but not the files from 0.32 init.gz, I threw together some files from a 3.9 system). However the network driver never loads.

When I try to boot 3.9 with the 0.32 files (gzipped cpio again), the system again panics after rest_init.

I have modified copies of init.gz as you suggested, but if the stock image will work then so much the better. Can you confirm that the stock init.gz will work with 3.x? Perhaps different kernel parameters are needed.

[Tom Elliott]

This is your own custom kernel?

And init.gz is a compressed ext2 filesystem, not cpio.

If this is a custom kernel, how was the kernel created? 3.8.8 is the latest released by fog. Having a custom kernel is fine, especially if you have special hardware within your setup.

Add the caveat for custom kernel, is the system you created it based on 64bit? If it is, when you run the make commands, don’t forget to do it with make ARCH=i386 menuconfig and make ARCH=i386 bzImage

Notice the ARCH in the make command as without it, it is going to try to build your image based on your systems current architecture which the init.gz system does not recognize.

I use 3.2.4 at work, and we’ve tested (working) 3.8.8, just we don’t use the 3.8.8 kernel as video on our laptops doesn’t work.

[jhd0044]

init.gz is a compressed ext2. initramfs is a compressed cpio. ([url]http://en.wikipedia.org/wiki/Initrd[/url] explains it better than I can)

I have tried using 3.9 from Fedora 19 (I know it runs on this hardware). I have built 3.10 from source with various configurations – initially starting with kitchensink, but adding debug objects and a couple of other minor things. I have tried the 3.x kernels via update kernel. None will boot with the stock init.gz (or perhaps the stock kernel parameters in the boot menu).

The only problematic hardware we have is a network adapter which e1000e doesn’t support until sometime around 3.x release. I’ve had problems with the kernel green-screening (not exactly a panic, more of a hang) if nvidia framebuffer support wasn’t in the kernel.
I tried booting in text mode, forcing vesa framebuffer and a ton of other things.

I have been using ARCH=i386 religiously. And I have been able to boot my custom kernel, just not with init.gz. Do you remember what kernel parameters you use? Because if I use the same boot parameters as 0.32 supplies, it panics. I have assumed (maybe incorrectly) that the panic meant that I needed different parameters. This is one reason why I started messing around with initramfs, since Fedora boots using one. I was able to rip it open and start messing with it. Yes it boots. But it is too horrible to imagine. Since the stock init.gz from 0.32 works for everyone else, I’d sure like to use it. I know nothing about busybox, which I’m reminded of regularly.

[Tom Elliott]

The default pxe file with all stock settings (less our passwords of course).

There haven’t been any kernel parameters added. To my knowledge, 0.32 doesn’t use initramfs. If it did, that’s news to me. What kernel parameters are you using? What does the kernel panic message state?

I’ve been building my own init.gz files for the last month, for fog 0.33, of which, I know is using ext2 filesystem, and no compression. The compression is performed by hand with a simple gzip -9 < output/images/rootfs.ext2 > init.gz

Also, to help in troubleshooting, what is your setup? Are you on VM? When did you start having problems with fog? When was the installation performed? Is the storage node on the same server or separate?

[jhd0044]

This is good info. I really appreciate hearing that a 3.x kernel will work. I’ve read so much over the last few days, and it gets blurred together. I am at home now, going to grab some sleep and start in again on this tomorrow morning. I’ll supply what details I can now, and the rest tomorrow.

OK, the default PXE file works with the init.gz file for you with 3.2 and 3.8. And the combo did not work for me.

Here is the params used for 3.9 and the stock init.gz earlier tonight:

kernel fog/kernel/bzImage
append initrd=fog/images/init.gz root=/dev/ram0 rw ramdisk_size=127000 ip=dhcp dns=10.0.1.7 mode=onlydebug keymap= consoleblank=0

I couldn’t read the panic message, since it scrolls off of the screen too fast. There is a stack trace ending with rest_init. These machines do not have serial ports on them, so I cannot log the console output that way. I tried recording the boot sequence with my phone, but it scrolls off too fast for the phone to catch (even viewing one frame at a time). This is one time when having really fast machines does not help. I’ll take a photo of it tomorrow and post the link.

You are correct that 0.32 does not use initramfs. When initrd did not work, I read something which suggested that 3.0 switched to initramfs. I assumed that support for initrd was gone, and pursued initramfs. I also wondered if ramfs was gone from 3.0, but I guess not. So far, the only way I can boot a 3.x kernel is to use initramfs for the root filesystem.

As for my setup: Our server is not on a VM, but is running on a Fedora 17 machine. We have been running fog 0.29 on this for a few years, upgrading to 0.32 when we switched to Windows 8. I read reports on these forums that some have successfully imaged Windows 8 with 0.32. We have two types of client machines: one is circa 2010 hardware, the other are brand new machines (3930k with 32G). The new machines are using Asus Sabertooth X79 motherboards with bios one rev from current. The latest bios has
a bug where it will not boot anything but a Windows 8 partition. If I remove all boot devices but the DVD and try to boot a Fedora install disk, I end up in the bios setup screen. Asus had us move to the previous rev of the bios, and everything works as expected.

Our problems started when I first tried to register one of our new 3930K machines. That failed, and further investigation showed that the network was not functional on those machines when using fog. These machines work fine with Fedora 19 / Windows 8 booting from disk. So I guess I can say that our problems with fog showed up with these new machines.

The upgrade from 0.29 to 0.32 was done this past Saturday. This was the first time I attempted to image one of our new machines.

The storage node is on the same server. The 0.32 software sees it just fine. The upgrade to 0.32 went very smoothly.

Edited to try to restore paragraph breaks.

[jhd0044]

Here is a photo of the call trace when booting 3.9 with the stock init.gz
[IMG]http://i1287.photobucket.com/albums/a632/jhd5/20130822_100737_zps8b576dc9.jpg[/IMG]

As you can see, the trace has scrolled everything else off of the screen.

Rest_init launches init (which is linked to bin/busybox I believe).

I know that busybox will run on this platform since I was able to boot a busybox image with my own ramdisk.

[jhd0044]

Update: Got past this. Thanks for everything. The default init.gz (the compressed filesystem) is working with 3.9 on our hardware. I needed to make a custom kernel and remove some drivers, and turn a few things off in the BIOS. There were IRQ conflicts, which do not occur when I boot from disk. Fortunately they were with unused devices (chipset support, but not motherboard support). PXE was configured in two different screens on the BIOS (and was not documented in the motherboard manual).

My remaining problems are fog-specific, so I’ll create a thread in that forum.

[Tom Elliott]

Alright man,

Sorry I wasn’t able to help out too much but good luck. Maybe I can help with your other issues then.