Forum Replies Created

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
  • in reply to: A report from a new user #52454

    @gianxxx wrote:

    Hello. I’m interested too

    I’ve got a FUTRO S300 floating around, with a D-Link multi LAN or a simple PCI card it could be a good solution…I hope so…

    Yep, that’s exactly the machine I had lying around.
    As said it was a temporary workaround since the idea was to use an Epia 5000 (of which I had two “lying around”).
    But after some experiments with them, and besides the fact that I didn’t manage to resolve the error I posted about, I looked a bit around and found how it esy to find Futro’s, the 210 or 220 model for anything between 20 and 50 Euro on e-bay (in Germany).
    I then bought two “new” Futro S220 for 70 Euros, they came with 128 Mb RAM and a 128 Mb CF card.
    The one I used temporarily was a S300, and I installed the Zeroshell 1 beta 16 on the internal (4 Gb) CF card.
    Because of the issues with BIOS (see below) I temporarily used a “standard” MBR, as detailed in my initial post.
    The thingy is working (though I have not particularly “high” needs) since beginning on september without a hitch.
    The only issue is that in case of blackout the Futro does not re-power itself (no such setting in the BIOS) so you have to physically push the power button.
    Since the BIOS has two settings for PME and WOL, I will have to experiment with re-powering it remotely through network.

    For this new test with S220 I started with a new approach:

    1. leave the 128 Mb card
    2. use a USB stick for Zeroshell (I have a bunch of 2 Gb no-name ones)

    The Futro is more or less a Commercial operation by Fujitsu-Siemens, the actual PC is a TR5670 manufactured by Teco, they seemingly just change the splashscreen and print “Fujitsu Siemens” on the unmodified case.

    I won’t comment (in order to avoid cursing) about the amount of data/documentation/drivers/support/etc. provided by Fujitsu Siemens (next to none) or by Teco (actually none) and about the amount of available data from third parties (very, very little). (and let’s not comment about the Insyde guys, see below)

    The issue is – as often is – the BIOS, it is made by Insyde and it is the MobilePro version 4.20.80 (BIOS 1.05.05).
    In my experience I have seen crappy BIOSes, but the ones made by Insyde are the worst of all.
    Besides the way to select choices is simply crazy, you use Space or Enter to select/enable things on a “random” basis, it has very limited options, most of them poorly implemented or simply mislabeled/wrong.
    Additionally that BIOS “checks” the MBR boot code and won’t accept the GRUB one (but see below).
    The boot options are:

    1. IDE
    2. USB Floppy
    3. USB CDROM
    4. Network (PXE)

    What is NOT specified/documented is that if you insert a (partitioned) USB stick in a USB port, the thingy will attempt to boot from it first.
    As said the GRUB MBR code (used in Zeroshell 1 Beta 16) is NOT compatible with that stupid BIOS /as well as the GRUB2 one used in Zeroshell 2), the good news being that some time ago this issue was found during the development of grub4dos and solved.
    For reference:

    For some strange reasons (that I have not yet fully understood/tested) the USB ports have both the USB 1.1 and the USB 2.0 speed and it seems like it boots anyway at USB 1.1 speed (slow) though as said it could be an issue with the BIOS settings I haven’t yet fully experiemnted with.
    So, the “easy” way to have the Zeroshell booting from it on a USB stick or CF Card is the following (under Windows, but under Linux it won’t be any different).
    I used the Qemu + Qemu Manager using a grub4dos Dos floppy (If you need info on how to make one ask) and the latest “Featured” release of grub4dos Chenall:
    You can boot Qemu allright from the Zeroshell “ZeroShell-1.0.beta16-CompactFlash-IDE-USB-SATA-1GB.img” then copy to first partition (or “boot” partition) the files grldr and bootlace.com.
    Then you run from the booted Zeroshell bootlace.com to replace the GRUB (legacy) MBR boot code with the grub4dos one, you can leave the “standard” /grub/menu.lst as is.
    Then you dd the image to the stick.

    Due to having the USB 1.1 speed issue and an otherwise unused 128 Mb CF CARD, I went a bit further.
    Since my USB sticks are 2 Gb, I created on the stick (mounted in Qemu as \.PhysicalDrive) a FAT 16 partition and added to it a DOS floppy image with the PLoP install files (but the floppy image can be added to the first partition or “boot” partition allright), mounted it to –mem and installed PLoP to the CF Card.
    A word of warning though.
    The 128 Mb CF card is seen by the Futro BIOS as 500/16/32, since the PLoP code is longer than 32 sectors if you are going to make a partition on the CF card, it will overwrite the PLoP code, so you either leave the CF-Card UNpartitioned (with just the PLoP installed) or you need to make the first partition start on at least third head.
    So, I disable the “legacy USB” support in BIOS, the thingy boots from the CF card (and thus to PLoP) which I set – after a few experiments – to boot automatically from USB with a delay of 10 seconds (there were some timeing problems if the delay was shorter when rebooting from Zeroshell), then grub4dos “takes control” and loads the kernel and initrd fast (USB 2.0) speed.

    I have no idea – sorry – about the -O2 flag and Transmeta, the thingy is working, boots and actually routes what it should route, the only issue is the mentioned “init: Id 7 respawning too fast: disabled for 5 minutes.” messages (and I am not sure to understand your note about inittab)

    The inconsistencies I mentioned are mostly because I am a rather picky (and critical) kind of guy and would like to have things “clear” and “as simple as possible”.
    As said the partitioning scheme of the images seems like having been made using numbers obtained by dice throwing, no “common” tools, including the Linux fdisk included in Zeroshell “like” them, the choice of using GRUB (legacy) and all ext2fs/ext3fs partitions (including the partition ID of the CDROM one) makes matters much more difficult for non-expert Linux users, the choice to have the CDROM partition in the middle of the image makes the first one, and more generally the whole image, “unmodifiable” (unless you know where your towel is) with “common” tools such as gparted, let alone the Dos/Windows tools.
    It seems to me like Zeroshell is the second or third best thing after the invention of the ice cream, and has (IMHO) the greatest potentialities, but right now to have to deal with it is extremely difficult unless you have some good backgrounds in booting matters (of which I know something) AND a “solid” background with Linux (which I almost completely lack of).
    Some things are most probably – as said – perfectly “natural” to an expert Linux user, but believe me they do look “queer” to someone coming from a different experience, another thing that I banged my head against some time (before understanding and finding the solution):

    Let me know if (apart form the ranting parts) the “how to” instructions are good enough or you need further assistance.


    in reply to: Zeroshell issues on Epia 5000 #52459

    @fulvio wrote:

    the release 2.0.RC1 solves the issue of hang at the boot time if the ldap db is corrupted. Could you upgrade?

    Yes and no.
    See my other post here:

    The Zeroshell 2.0 RC1 refused to boot (at all) on the Transmeta 800, so I installed there the 1.0 beta 16 (and it is working allright 🙂 ).
    Now the idea is:

    • have the EPIA 5000 work with 1.0 beta 16
    • once it has been tested “in parallel”, replace the Transmeta 800 with the EPIA 5000

    as a matter of fact the 2.0 RC1 refuses to boot at all on the EPIA 5000 also, but that could be well an issue with the filesystems/BIOS/whatever, I need to do a few more tests to make sure, and hopefully find the issue for both the hardwares.

    In a more general “plan” the idea is:

    • test BOTH the 2.0 RC1 AND the 1.0 b16 in the EPIA 5000 (and have BOTH releases working) but temporarily have it running the 1.0 b16
    • have the Wi-Fi access (for which I am now using the Transmeta 800 with Zeroshell 1.0 b16) be NOT interrupted if not for the strict time needed to switch the hardware, replacing it with the EPIA 5000
    • test the 2.0 RC1 on the Transmeta 800, and IF successful, configure it and have the Wi-FI access again interrupted for the sheer needed time to switch the hardware
    • have the EPIA 5000 with 2.0 RC1 installed ready as “backup/emergency” machine
    • in a longer period, when I will be able to take “out of current use” another EPIA 5000, and I will then “retire” the Transmeta and have two identical hardwares running the same version of Zeroshell and easily “flippable” in case of need


Viewing 2 posts - 1 through 2 (of 2 total)