[syslinux] Intel Z-U130 SSD

[H. Peter Anvin]

Robert DeLaGarza wrote:
> 
> My hardware is an embedded system using an off-the-shelf COM Express
> module with a Phoenix BIOS.  Mass storage is provided by an Intel
> Z-U130 Solid State Drive (aka "Intel Value SSD").  The SSD is much
> like a standard USB Flash drive.  The main differences are, of course,
> the packaging and connector, and the fact that it is a non-removable
> device ('/sys/block/sda/removable' is 0).
> 
> The SSD is initially loaded with a version of Fedora 8 created using
> 'livecd-creator'.  A build script takes the livecd ISO and produces a
> binary file containing a disk image: MBR, partition table, and two
> partitions.  The first partition is active and contains the Fedora
> files and a syslinux installation.  This disk image is written to the
> SSD using 'dd'.
> 
> Fedora 8 is configured to load into memory and leave the active
> partition on the SSD unused.  The idea is that the Linux installation
> can then be updated in-system by mounting the partition, and simply
> changing the kernel, initrd, and 'syslinux.cfg'.
> 
> When implemented on a standard USB Flash drive, this works!  The SSD
> implementation is a different story.  Fedora 8 boots reliably, but
> updating the kernel, initrd, or syslinux.cfg often (but not always)
> yields a system which hangs during boot, usually during load of the
> initrd.  The error message is "Boot failed: please change disks ..."
> 

This implies a disk I/O error.  Syslinux will try to address a failing 
sector at least six times before giving up, but in your case it keeps 
getting the error repeatedly.

This can be caused either by an actual disk error, a corrupt filesystem, 
or a bug in the code which causes access beyond the end of the disk.

> 2. Are there any issues with the Intel Z-U130 SSD that could cause this?

None that I know of, but it's not exactly like I have ever seen one of 
these devices.  It sounds to me that there might be a compatiblity issue 
between the Z-U130 and the USB storage stack in the mainboard BIOS.

The method you describe should normally work; there isn't anything 
inherently flawed.

	-hpa