While looking for solutions to my problems booting from a CF flash IDE emulator - for my firewall -
I found gujin. After using grub and before that lilo, I am quite impressed with what gujin can do.
Unfortunately I have not been able to make gujin work either and was wondering if any one else had tried it and (hopefully) succceeded or if there is a fundamental problem for some older BIOSes
Also I had hopes to be able to use some of the debugging files to help in sorting out the problem, but have had no luck so far.
Any comments one way or the other would be much appreciated.
When using an IDE Compact Flash emulator (opposed to a USB Compact Flash emulator), Gujin should exactly behave like a hard disk.
There is few usual things to check, related to the special disk you then have:
1- If you are using the BIOS interface to load Gujin from the MBR, is that the right BIOS disk number? i.e. the parameter 0x80 in "--disk=BIOS:0x80"
Also, do you have the right BIOS geometry for the hard disk? i.e. parameter "--geometry="
A simple way to check is to boot a floppy disk with Gujin, it will tell you what is detected on which BIOS numbers.
2- If you are using the EBIOS interface, Is the drive useable under Extended BIOS?
Same simple way to check, boot a floppy with Gujin with the same hardware configuration, the Compact Flash adapter still plugged in the same P-IDE port.
3- Is Gujin correctly written on the Compact Flash card, how about Compact Flash bad sectors?
When you boot Linux to install Gujin on the Compact Flash, the instboot software will write the Gujin bootloader and then re-read all sectors to check if there was a problem (difference in what has been written and what is read back). It should warn you about any difference, you should not ignore the error message (if you do ignore, you have a partially working Gujin).
If you have a bad sector (sometime even on NEW devices) in the middle/end of the compact Flash, then you can try to install Gujin to different sectors, for instance creating with fdisk a partition starting at cylinder 2 instead of 1, or finishing before the end of the disk, and install Gujin in this partition - or create a partition containning all the bad blocks, never to be used.
If you have a strange MBR, some Compact Flash restrict the byte writable on the first sector, you may be forced to use a special partition scheme on this device (or use another brand of Compact Flash). You should be able to see instboot complainning at the end of the install about comparing the MBR, and see what you can do with fdisk under Linux: maybe only a floppy image (no partition table) or maybe even the MBR of this Compact Flash is forced to zero and so Gujin will not be able to boot this device.
When dealing with Compact Flash, I am used to do "xxd /dev/hdc | less" and "xxd /dev/hdc1 | less" to see the MBR, coupled with "dd if=/dev/zero > /dev/hdc bs=512 count=1" and "dd if=/dev/yes > /dev/hdc bs=512 count=1" you may see the problem.
Note that sometimes the bad sector is in the FAT of the filesystem created, that is still a bad idea to use this filesystem and you should try to create a partition where all sectors are working - the "--full" parameter of Gujin installer may be usefull there.
In short (because you did not state the exact message when Gujin fails), I would check if the Compact Flash installation reports an error and then check with another Compact Flash - maybe another brand.
If you have a BIOS/EBIOS problem (low probability) you can use the IDE/lba or IDE/chs parameters for instboot to boot using the IDE interface bypassing totally the BIOS.
Note that the problem are worse when using a USB<->Compact Flash adapter because the write errors are never reported on a USB adapter, and then even the "badblock" software is ususeable.
Thank you for your reply.
I have meanwhile resolved my problem of booting to the CF disk..
All of the info I had read on the net, told me to use "syslinux [-s] x:" to install linux on the CF. After reading up on syslinux some more, I found that there are other options and tried them. Using -m (install a MBR) and -a (make partition active) I was able to boot to my CF disk directly - and have been able to do so on another older machine as well.
Back to this issue: I've just installed gujin 1.4 using a linux machine to a clean floppy.
The floppy boots without problems, but cannot find the linux system on the CF disk - which boots ok by itself.
During the boot, the initial display shows:
0: IDE/lba master@0x1f0,03xf6, size 123 Mb, 1 partition
1: BIOS 0x80 C/H/S: 250/16/63, size 123 Mb, 1 partition
2: BIOS 0x00 C/H/S: 80/2/18 size 1.440 Kb, 0 partitions
Analyse filesystems: found 0 ways to boot and 2 inital RAM disks.
After that it says that it had found "Not even one selectable item!""
Although the CF disk, which it found, will boot on its own.
If the floppy says "Not even one selectable item", then Gujin installed on the Compact Flash will say the same.
Which filesystem are you using for the partition? (Gujin only handle FAT, E2/3FS and ISO9660 - you can create a small partition to mount on /boot). Beacuse Gujin found two initial RAM disks, that does not seem to be your problem.
Which name did you use for the Linux kernel? (Because of automatic detection without configuration, it has to be "vmlinuz*", "bzImage*", "zImage*" or "*.kgz",
case insensitive / initrd have to be named "initrd*").
If you install Gujin on the Compact Flash by the command:
dd if=/dev/zero of=/dev/hdc bs=512 cout=64 # NEEDED to erase the MBR and partition table
./instboot boot.bin /dev/hdc0 --disk=EBIOS:0x80
The the installer will create the FAT partition by itself to the maximum size (size of the disk minus size of the bootloader installed at end of disk).
If you want to set up yourself the partition table by "/sbin/fdisk", you do so and then type:
./instboot boot.bin /dev/hdc1 --disk=EBIOS:0x80
You may have to use parameters --cmdline="" and --geometry=/dev/hdc1
You may want to use --disk=ide:lba28,ide0,master or --disk=EBIOS:0x80,auto
instead of --disk=EBIOS:0x80
Eventually I am thinking I may want to use the floppy to boot, rather than the flash drive, but I'm still undecided on that issue - and even then I may stick with syslinux, as I won't be trying to boot multiple OS on my firewall :-)
Currently the CF disk is FAT16, but I suppose the real problem is that the linux file to be booted for the LRP firewalls is named simply 'linux' - thus gujin does not recognize it as a bootable system.
Both the LEAF/LRP Dachstein and Bering firewall software systems seem to use that name - presumably it is compressed, but the name does not seem to reflect it.
If I rename the system file to vmlinuz to satisfy gujin, it will no doubt cause problems for the rest of the system :-( and it won't boot on its own.
I am using grub on another multi-boot system right now and am considering moving to gujin for it, even though I may or may not use gujin for my firewall system.
Initially I had looked at gujin for this job mainly because I had trouble booting the CF disk on its own.
There should be no problem to simply copy the file named "linux" to "vmlinuz", at least until you upgrade the kernel on "the LEAF/LRP Dachstein and Bering firewall software systems", but they probably have no package management...
Even if you are not multi-booting (then you can set up Gujin auto-boot system after one second), you can still modify the Linux command line before loading Linux - for instance define the init=/bin/sh if the system no more start correctly at some point.
Gujin also handle full serial line input/output if you plan to remove the video card, a firewall may work better without a screen and a keyboard.
Thank you your comments.
As I'm not too familiar with all of the firewall software, I like to keep a close eye on it when it boots, but your suggestion regarding a serial link is of some interest because it allows me to keep the firewall box out of the way once it is all running without problems and once I'm done setting up and experimenting.
As it is, there seems to be a way to run some of the kernels 'headless' - without video and/or keyboard, but there are some messages during the early stages of booting which don't show on a serial link under those conditions.
gujin seems to be doing things differently, so I am planning on giving it a try once I sort out all of my other problems ;-)
For several reasons I am moving from my working system running Dachstein to Bering. Some of the things work the same, others don't and those of course are the ones taking some time to sort out.
Out of curiosity I copied the file linux -> vmlinuz and gujin then tells me it found two ways to boot the system and gives me the choice to boot via F1 & F2, but either way fails to boot and gives me the same error message:
error 0x35BF, loading file, error 0x04, loading file.
Concerning the error 0x35BF loading file, I have just rebuild an incomplete signification table:
0x2??? -> (system_file_load) DOS (INT0x21) loading interface
0x3??? -> (system_file_load) Gujin FS loading interface
0x3200 -> (file_treat) failed to get file mapping
0x34?? -> (file_treat) read disk error
0x35?? -> (file_treat) treat function error
0x35B? -> (gzlib_extract) vmlinuz header problem
0x359? -> (gzlib_extract) inflate problem
0x3592 -> (inflate) general error
0x3593 -> (inflate) data error, not a GZIP file or file corrupted?
0x3594 -> (inflate) 32K window alloc error
0x3596 -> (inflate) output full, no enought memory to load kernel
0x3597 -> (inflate) bad length (in the GZIP descriptor)
0x3598 -> (inflate) bad CRC32 (in the GZIP descriptor)
0x359A -> (treat_data if XMS used) _XMS_alloc_memory failed
0x359B -> (treat_data if XMS used) _XMS_realloc_memory failed
0x359C -> (treat_data if XMS used) _XMS_move_memory failed
0x359F -> (gzlib_extract) inflate returns with non empty input! and no Z_STREAM_END.
0x3600 -> (file_treat) Gujin malloc out of memory
0x3700 -> (file_treat) buffer smaller than hardware sector?
0x3800 -> (file_treat) incompatible filesize, checkdisk?
0x3900 -> (file_treat) too many fragment for file mapping
The second ", error 0x04, loading file" is a bug that I have already removed in my development version.
It seems your error 0x35BF is due to the GZIP decompressor waits for more data to decompress, there was no error up to there but also the decompression is not finished: as if you did not have enought space on the device to copy "linux" to "vmlinuz" and so a short file has been created.
Can you do a "ls -l linux vmlinuz" to check that?
Please tell me if you have any other problem with Gujin once you solved your other problems.
The resulting file sizes for linux and vmlinuz are identical - 516718, as are the dates.
Could it be because it tries to uncompress a file which may not be compressed?
As far as I can tell, vmlinuz (being simply a copy of linux) is not compressed. Inspecting it with a hex editor confirms that suspicion.
As for the rest, I'll keep you posted.
The vmlinuz file is a compressed file with a binary header added (containning the no-more used bootsector, the decompressor and the real-mode initialisation code), so it does not have the GZIP signature at it beginning but at few Kbytes offset.
Gujin has found the GZIP signature because it has started the decompression.
I think I corrected a problem like yours in Gujin version 1.3, can you confirm you are using the latest Gujin version v1.4 ?
Did you recompile Gujin or use the files in install-1.4.tar.gz or standard-1.4.tar.gz; if you recompiled with which compiler version?
To be able to find the bug, I would need this "linux" file, can you sent it to me (email@example.com) or can I download it from somewhere on Internet?
It is version 1.4 as per the sign-on screen, from the downloaded package. I believe it came from ./instboot boot.bin >dev/fd0 on my linux box, according to my notes. No recompiling at all.
I had looked at it and found some plain text early in the file and concluded it was not compressed, but since I'm not familiar enough with the formats, I may well be wrong on this.
I will compress the linux file and send it on to you. Let me know if you have any problems with it or with receiving it.
Thanks for sending this LINUX file.
I invertigated, so get back the compressed file (knowing that the first two bytes of a GZIP compressed file are 1F 8B) like this:
xxd LINUX | less
-> search 1f8b i.e. type /1f8b
0005550: 67a3 b895 1f8b 9bbe e141 0ab0 5475 e160 g........A..Tu.`
-> offset 0x5554
LINUX filesize = 516718
-> keep 516718 - 0x5554 = 516718 - 21844 = 494874
tail -c 494874 LINUX > aa.gz
gunzip: aa.gz: unknown method 155 -- not supported
So it seems that this kernel version 2.4.32 was compressed with something else than GZIP, maybe to save space by better compression.
$ strings LINUX | head -18 | tail -3
$Info: This file is packed with the UPX executable packer http://upx.sf.net $
$Id: UPX 1.93 Copyright (C) 1996-2005 the UPX Team. All Rights Reserved. $
Gujin is a bit special in the way it boots Linux kernels, and I have to say that it is incompatible with such a kernel.
I may try to support this UPX patch in the future, but only if that is still maintained for linux-2.6.
Finaly, I have to add that I forgot to say that the error 0x359F also cover a Gujin error while treating the vmlinuz header file.
0x359F -> (gzlib_extract) inflate returns with non empty input! and no Z_STREAM_END.
(vmlinuz_header_treat) error treating vmlinuz header (not for *.kgz)
As far as the compression system used you are probably very much more informed than I am. I've never really worried about any of this stuff before, but as far as I can tell, all of the LEAF/LRP systems use this scheme as I've never came across any sort of mention of this being an exception to any rule.
As far as I can tell, it is simply handled by syslinux.
I tried to have a look at what LEAF/LRP systems are doing to the Linux kernel, and so searched at:
for some kind of linux patch file or even the source of their kernel, I did not find it.
Is it one of those binary-only Linux distribution, and is it a good choice for a firewall? Or is the source file of the GPL kernel hidden in an obvious place I did not look at - for instance in a CDROM released to each costumer? Maybe it is just monday morning...
LEAF/LRP comes in several 'flavors'. The basic idea is to be able to use an older model PC (as low as a 486 with a single floppy) as a firewall.
I have used and am currently using "Dachstein", but want to move up to Bering-uCLib because of some additional features available and is more active support.
If you follow the link in your post to the "download" section, you can download one of the 'images' - either for a 1.68 M floppy or the ISO image for a bootable CD, depending on what hardware you have or want to use.
It gives you a very minimal (on purpose) linux system with either an iptables (or ipchains, for some of the older version) based firewall.
I had been using an old DEll 486 for several years until recently when the motherboard/memory started to show some problems - I never tracked it down to a more detailed level since I would not be able to get spare parts for it in any case.
Currently I am using another temporary machine running my old Dachstein - ipchains - firewall for now, but once I sort out all the new things I want on my new firewall, I will be using another Compaq 586 as my replacement running Bering-uCLib off a CF drive.
One of the safety features of a floppy based system is that one can run the machine with the floppy removed and thus it can not be rebooted remotely by any intruder. Since I don't need to use my systems remotely, that has no detrimental consequences for myself - which is also one of the resons I may want to use a floppy based gujin to boot my CF based system.
As for installing the software, I've been using the floppy image and then transferred the files to my CF drive after formatting it and after installing the syslinux boot software.
Additional modules - or facilities - are available in the 'modules' package. Typically, one has to select and possibly install the proper modules for the NICs and, in my case, IDE support, for the floppy based system.
I guess, I overlooked your question - yes it typically is a binary only distribution. Although the source is available freely, for most uses and users - the binary packages suffuce.
I may repeat myself, but I search the kernel source or even the patch file and did not find it.
I will not spend time on a binary-only Linux distribution.
I suppose this LEAF/LRP stuff is as much a binary-only distributions as is Debian ;-)
I have treated it as such, as I did Debian - although I have dabbled a bit with source-only Gentoo - only because I have no need for the source for my work.
The sourceforge site: http://leaf.cvs.sourceforge.net/leaf/
has a CVS repository available.
I'm not sure if that is sufficient for what you need. I've never tried to find the sources, particulalrly for the kernels used.
In any case - with or without the kernel source - I guess, the problem boils down to gujin not being able to handle kernels which syslinux can boot.
So, even if you cannot find the LEAF/LRP kernel source, I would expect that if gujin can boot a kernel which syslinux can, then it it would also handle the LEAF/LRP kernels.
OTOH, most LEAF/LRP projects will likely not need booting to different kernels, so perhaps, it is a moot point in any case. :-)
I will be away from the keyboard for a few days as of tomorrow.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.