Problem with an embedded Linux system

At work we have a book scanner, a Copibook from I2S. When we tried to turn it on it complained about no operating system, so we opened it to try to find what was wrong. We found out that it has a common computer inside, with a flash memory disk. In that disk it has two partitions, a Windows partition with some configuration files and a Linux partition with the scanner's operating system.

I made an image of the disk, mounted it on a virtual machine using VMWare and, after some looking around and questions in Linux forums, I was able to create a LILO configuration that looks like this:

boot=/dev/sda
bitmap=/run/media/one/ec3c7e92-7d49-42e0-8ae8-ffe59bd02d9c/boot/bootsplash.bmp
map=/run/media/one/ec3c7e92-7d49-42e0-8ae8-ffe59bd02d9c/boot/map
install=/run/media/one/ec3c7e92-7d49-42e0-8ae8-ffe59bd02d9c/boot/boot-bmp.b
prompt
timeout=50
image=/run/media/one/ec3c7e92-7d49-42e0-8ae8-ffe59bd02d9c/boot/linux
label=linux
root=/dev/sda2
read-only

That returned an error:

VFS: Cannot open root device "802" or unknown-block(8,2)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount fs on unknown-block(8,2)

After some more searches I thought this was a result of using "/dev/sda" when creating the LILO config (the live CD I used sees the disks as "sd"), while the scanner's system is older and should use "/dv/hda", so I used "linux root=/dev/hda2" at the next boot and got this error:

VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory:152k freed
Warning: unable to open an initial console.
Kernel panic - not syncing: No init found. Try passing init= option to kernel.

On a Linux forum someone told me I should have used "chroot", but me attempt returned a "failed to run command '/bin/bash': No such file or directory".

Thanks in advance for any ideas.

a reply to: ArMaP

Q: does the Cobald even have an Intel (compatible) processor? If not, its binaries will not run on your VMware VM, which emulates an Intel(compatible) system.

a reply to: ForteanOrg

Yes, there's a real PC inside the box, with an Intel motherboard.

a reply to: ArMaP

.. and /run/media/one/ec3c7e92-7d49-42e0-8ae8-ffe59bd02d9c .. that looks a lot like a udisk mount point. Are you running this as user 'one'?

a reply to: ForteanOrg

Yes, I forgot to say that I was using SalixLive, the default user is "one".

a reply to: ArMaP

I'm a bit confused here on what you try to do. Let's check.

• You have somehow copied the contents of the flash drive to an ISO file
  
• You then started up a SalixLive image on a VMware system
  
• You mounted the Cobald ISO and edited it's /etc/lilo.conf
  
• You then tried to boot your new ISO as an independent system
  

Correct so far?

a reply to: ForteanOrg

Yes, that's the situation, the only difference being that I didn't make an ISO file, I made a vmdk file for VMWare.

The Copibook disk doesn't have a /etc directory, only a boot directory with the following files:
boot-bmp.b
bootsplash.bmp
fs.img.gz
linux
map
System.map

originally posted by: ArMaP
a reply to: ForteanOrg

Yes, that's the situation, the only difference being that I didn't make an ISO file, I made a vmdk file for VMWare.

And now you try to boot the image on a VMware host, right?

The Copibook disk doesn't have a /etc directory, only a boot directory with the following files:
boot-bmp.b
bootsplash.bmp
fs.img.gz
linux
map
System.map

Still assessing the situation: my guess is that you believe the MBR was somehow damaged and you try to reconstruct it, right? So you created a new lilo.conf file somewhere (in your Salinux environment, methinks) and have created a lilo config file per the format you specified in the OP. So, what you try to do is to rewrite the MBR, right?

Try to add this to your lilo configuration file (wherever you have it):

initrd=/run/media/one/ec3c7e92-7d49-42e0-8ae8-ffe59bd02d9c/boot/fs.img.gz

Note that LILO requires you to run the lilo utility to write the MBR to the image. I assume you already knew this and are using the Salix distro to do so, correct?

Hope it helps.

originally posted by: ForteanOrg
And now you try to boot the image on a VMware host, right?

Right.

Still assessing the situation: my guess is that you believe the MBR was somehow damaged and you try to reconstruct it, right?

Right.

So you created a new lilo.conf file somewhere (in your Salinux environment, methinks) and have created a lilo config file per the format you specified in the OP. So, what you try to do is to rewrite the MBR, right?

Right again.

Try to add this to your lilo configuration file (wherever you have it):

initrd=/run/media/one/ec3c7e92-7d49-42e0-8ae8-ffe59bd02d9c/boot/fs.img.gz

Thanks, I will try that.

Note that LILO requires you to run the lilo utility to write the MBR to the image. I assume you already knew this and are using the Salix distro to do so, correct?

Correct, I am using Salix because it was the only one I could find that still uses LILO.

originally posted by: ArMaP
Correct, I am using Salix because it was the only one I could find that still uses LILO.

Just curious: how did you create the disk image?

a reply to: ForteanOrg

I don't remember exactly what I used, but I used some Linux LiveCD on a computer with the disk connected to it (although it's a flash disk it has an IDE connector), then I searched the Internet to see what I should do in Linux to create an image of the disk (I knew it was possible).

After that I used some program (I should have taken notes of what I did) to convert that image to a format used by VMWare,

a reply to: ArMaP

So, you removed the disk from the old computer and connected it to some other computer. If you used Linux chances are you used 'dd' to make the raw copy and something like 'qemu-img' to convert that into a vmbk file.

What commands did you use to create the MBR in the vmbk?

a reply to: ForteanOrg

I used just "sudo lilo -C config", as I thought that would be enough.

PS: as you probably have already noticed I'm a little lost in Linux.

a reply to: ArMaP

Oops. You may inadvertently have changed the wrong MBR then.

What you want to do is have /sbin/lilo write to the part of the mounted image that contains the MBR for the Copibook. What you actually did was have /sbin/lilo write to the MBR of the system it runs on (the SalixLive image). You may be able to repair this by simply running 'lilo' once more, without parameters, assuming the MBR is still adequately described in the original /etc/lilo.conf file.

Still assessing: do you know if the VMBK file you created was a FLAT or a SPARSE file?

originally posted by: ForteanOrg
What you actually did was have /sbin/lilo write to the MBR of the system it runs on (the SalixLive image).

Then why did the boot process changed when I ejected the SalixLive CD and restarted the virtual machine?

You may be able to repair this by simply running 'lilo' once more, without parameters, assuming the MBR is still adequately described in the original /etc/lilo.conf file.

That /etc/lilo.conf file would be in which system, the SalixLive?

Still assessing: do you know if the VMBK file you created was a FLAT or a SPARSE file?

I don't know, I don't even know what you mean by that.

a reply to: ArMaP

I'm a bit puzzled myself now: I assumed that you ran a VM in which you booted SalixLive. I assumed you then mounted the Copibook VMBK in the SalixLive filesystem, and tried to change it by typing 'lilo -C.." etc. - still correct?

So, I reasoned that when you do this using a config file that says /sbin/lilo should use /dev/sda as location to store the MBR (you never changed that, did you?) it would write the MBR to /dev/sda, of course. That would be the /dev/sda known to SalixLive, e.g. the boot disk of that system (I assume). So, yes, that would not have changed the MBR of the Copibook image, but it would have changed the MBR of the SalixLive image.

About the difference between a flat and sparse VMDK:

A flat VMDK is actually just a 'dd' (block by block copy) of the disk. It hence has a fixed size (the size of the disk, actually), and when used as a VMware image, it can not grow. It performs well, and it's robust.

A sparse VMDK consists of an administration of the disk, has a variable size as only changes to the disk are stored. This consumes less disk space, but comes with a performance penalty.

If you have a flat VMDK, the MBR is in the initial sector of the file. A sparse file is more complex to handle.

originally posted by: ForteanOrg
I'm a bit puzzled myself now: I assumed that you ran a VM in which you booted SalixLive.

Correct.

I assumed you then mounted the Copibook VMBK in the SalixLive filesystem, and tried to change it by typing 'lilo -C.." etc. - still correct?

Yes, still correct.

So, I reasoned that when you do this using a config file that says /sbin/lilo should use /dev/sda as location to store the MBR (you never changed that, did you?) it would write the MBR to /dev/sda, of course. That would be the /dev/sda known to SalixLive, e.g. the boot disk of that system (I assume). So, yes, that would not have changed the MBR of the Copibook image, but it would have changed the MBR of the SalixLive image.

As I added the Copibook disk to the virtual machine it appears as sda (with the Windows partition appearing as sda1 and the Linux partition as sda2). I suppose that, because I am using a live CD that runs from the CD and not from the disk, it doesn't have any other disks. I just did a "fdisk -l" to show all partitions and got only sda1 and sda2.

About the difference between a flat and sparse VMDK

Thanks, I understand it now, but I don't know how to answer your previous question.

I wasn't able to use the virtual machine at work, but at home I have another one on VirtualBox, so now I don't remember which one I used before. In Virtual Box the disk appears as "Dynamically allocated storage".

originally posted by: ArMaP
I wasn't able to use the virtual machine at work, but at home I have another one on VirtualBox, so now I don't remember which one I used before. In Virtual Box the disk appears as "Dynamically allocated storage".

It's a sparse file then. What tool did you use to create the image?

I assume you logged in into the SalixLive system, got a prompt and typed 'sudo fdisk -l' to see what disks / partitions you had. Correct?

From what I can compile from your postings it seems you ran the SalixLive from a live-image (so: as if you had a hardware system with a CD drive and you booted from CD instead of disk)?

(I assumed you had INSTALLED SalixLive into a VM, so on it's virtual hard disk - assumption is the mother of..)

originally posted by: ForteanOrg
What tool did you use to create the image?

I don't remember.

I assume you logged in into the SalixLive system, got a prompt and typed 'sudo fdisk -l' to see what disks / partitions you had. Correct?

Correct.

From what I can compile from your postings it seems you ran the SalixLive from a live-image (so: as if you had a hardware system with a CD drive and you booted from CD instead of disk)?

Yes, as I'm not familiar enough with Linux I thought that the less disks I have at the same time the less possibilities of mixing things up, that's why I used a live CD image.

(I assumed you had INSTALLED SalixLive into a VM, so on it's virtual hard disk - assumption is the mother of..)

... too many things.