This is a nice alternative to removing unionfs. I have an 8G SDHC card showing up soon. If I have trouble removing unionfs I may go this route instead and if I need to read an SD card I can just use my cheap USB external card reader. Thanks for posting this!

lcangler wrote:

I put xp on my ssd and would like to intall/run xandros from my 8g sd card.  I will leave the sd card in all the time.  Does this procedure preclude using the sd card for anything else?  Can you partition a card and have xandros on part of the card and put some of your other windows type program files on the card in another partition?

You should use the technique given in the wiki http://wiki.eeeuser.com/xandrosbootfromusb for what you have described instead. But since xandros is gone from your ssd you'll need something like puppy linux or eeexubuntu on usb stick to execute the commands. It's possible to partition the sd card in the way you have described to share between xandros and xp. I'm doing something similiar from a USB hard disk.

Last edited by jasonp (2008-01-01 8:35:23 pm)

I am new to all this but I think I understand. With this method, I could install Xandros and XP on an 8GB SD cardd and boot into either? The added benefit is that I could install any apps that I want for Xandros (on the SD card) without worrying about running out of space like he default Xandros?

Do I have that right?

Thanks for all your help

albkwan,

Thank you!  I had posted a request for this a couple of days ago, and you have come through!  I've copied your HowTo (so I can find it again!) and will be trying it tonight.

lcangler wrote:

How is the procedure described in this link http://wiki.eeeuser.com/xandrosbootfromusb different from the procedure that albkwan developed.  I thought there was some issue trying to run xandros from an sb card and that albkwan's procedure fixed this.  Can someone explain this for me before I do anything stupid??

Both steps are written by me. There is not much difference - Only where to mount the USER partition.

The issue that come when booting Xandros from an SD card (i.e. /dev/sdb) comes from udev that mounts removable USB devices. This happens after the system has completely boot up (after X windows is running).

Tonight, while redoing it all over again, I come to a situation when the system has completely boot up, I check and found that /dev/sdb2 has been mounted read/write. But after a few seconds, it becomes read only!

This does not occur at every boot up and it never happen to a USB flash disk (i.e. /dev/sdc), But sometimes it happens. I think the solution should be changing the udev rules to disable udev from re-mounting this SD card again.

In my old system, I have something like this. But since I have format everything (due to a silly mistake), I have to do it all over again!

EDIT: It's too late now. I need some good sleep tonight!

Last edited by albkwan (2008-01-02 10:32:21 am)

lcangler wrote:

Thanks albkwan.  When you do it again and I am sure will get it going, can you edit your original procedure and repost with one writeup.  Linux is so new to me, I get confused trying to paste together different procedures and trying to land on the last one that worked.  One other question that was unclear, if I follow your procedure... normally booting XP from SSD and using SD for program and data file access (office, etc.)  nothing will change for that right?  When I want to run xandros, I get to choose to boot linux from SD card and off it goes.  That would be sweet.

I will repost the steps later. Last night, I was redoing it with Puppy Linux. I found that Puppy Linux has more GUI tools, which I think will be much easier for Window users (not acquainted with Linux) to follow.

As for the dual boot thing, I am also planning to install win2k on my /dev/sda2 partition (the original USER partition). After I get that working, I will also post the steps.

jasonp wrote:

albkwan wrote:

Another application of this modification has come to my mind:

With the USER partition all on a SD card, you can share your eeepc with members of your family, or lend out to students at school. Every user only need to have his/her own SD card, insert it into the eeepc and boot it.

Then every user can have the freedom to install programs he/she like, store their personal data, without the need to config different user profiles ... etc on the limited space of the SSD.

And the best thing of this approach is that it is fully upgradeable and you don't need to worry about wearing of the SSD (which is now read only). Any sign of disk read/write error on the SD, you just buy a new SD and move all your data there.

Russel has done something similiar and included support for using USER as an encrypted container with LUKS and as a ram disk.

http://slofith.org/projects/eeepc/

Just take a look at Russel's init file. Indeed, he has done it in an even smarter way:

There is actually no need to copy the USB modules into init, they can be loaded from within the root filesystem after mounting /mnt-system. This will require fewer changes to the initramfs image. I will test it and update the steps above.

The other thing I like very much is booting with a ramdisk when no SD card is available - just like a Linux on CD!

Hard disks are block devices in Linux. They are special files in the Linux filesystem which need to be created by the mknod command. To help the kernel to identify them, each device is assigned a major and minor number. The scsi disk0 is conventionally assigned a major number of 8. Only the minor number changes for sda, sdb, sdc, and so on.

For the 1st partition on the 1st scsi disk, i.e. /dev/sda1, the major and minor numbers are 8 and 1;
...
For the 16th partition on the 1st scsi disk, i.e. /dev/sda16, the major and minor numbers are 8 and 16;
For the 1st partition on the 2nd scsi disk, i.e. /dev/sdb1, the major and minor numbers are 8 and 17;
...
For the 16th partition on the 2nd scsi disk, i.e. /dev/sdb16, the major and minor numbers are 8 and 32;
...
For the 1st partition on the 3rd scsi disk, i.e. /dev/sdc1, the major and minor numbers are 8 and 33;
...
and so on.

For more information, you can read the manual page and info page of the command mknod, or refer to Linux kernel documentation.

man mknod
info mknod
'q' to quit

OK if I am not mistaken, this moves everything from the SSD storage to the SD card, correct?  Or does this "add" the available storage space of the SD card to the root file system in general?

Very nice.

I did a little more reading about UnionFS after I last posted.  Ideally, for me at least, I would a) keep the "recovery" partition (which I understand to be the "bottom layer" of the UnionFS tree in the EeePC); b) use the rest of the free space on the internal SSD as the "second layer" of the UnionFS tree; and c) when the SSD is full (or near full) start using the space on the SD card.

It seems this would create the scenario that the SD card would need to be kept in at all times.  Also, I don't even know if this kind of set up is possible (it seems perfectly possible, but automatically switching to SD card space rather than SSD card space may not be possible).

In any case, please leave updates on these scripts you're working on.

Last edited by ERamseth (2008-01-10 1:49:33 pm)

Hmm.

I guess what I am concerned about is not using the SSD at all.  I mean really... I paid for the SSD didn't I?  haha

ERamseth wrote:

... and c) when the SSD is full (or near full) start using the space on the SD card.

It seems this would create the scenario that the SD card would need to be kept in at all times.  Also, I don't even know if this kind of set up is possible (it seems perfectly possible, but automatically switching to SD card space rather than SSD card space may not be possible).

you could do something like this with an LVM device spanning the internal ssd and the sdhc devices, though you're right about the card having to be left in at all times. (the 2 devices are logically turned into a single larger device - removing the SD card afterward  would be roughly equivalent to removing half of the hard drive from your normal computer)

albkwan wrote:

Code:

#load USB modules
...
insmod -f /mnt-system/lib/modules/$VERSION/kernel/drivers/usb/storage/usb-storage.ko > /dev/null

#need time to register things
sleep 8

you can replace the hardwired "sleep 8" here with something like -

while ! grep -q $USER /proc/partitions; do sleep 1; done

where $USER is the partition you're waiting for. This looks every second in /proc/partitions (the kernel's list of available block devices) for a device, and waits until it's found. this way you'll continue booting as soon as the kernel has found your device, instead of just saying "it ought to be available within 8 seconds".

albkwan wrote:

For the 1st partition on the 1st scsi disk, i.e. /dev/sda1, the major and minor numbers are 8 and 1;
...
and so on.

also, /proc/partitions will tell you the exact major/minor device id for any detected device. "cat /proc/partitions" to see every block device your kernel is aware of, whether or not a node exists for it under /dev/...