kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?

kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?

[Tomasz Chmielewski]

I have a Linux (ARM) device that normally starts from /dev/sda1.

It is configured to do so via a cmdline in a RedBoot bootloader:

root=/dev/sda1


The device is pretty small and has no keyboard, video card etc., so if 
it ever happens to break (can be a disk failure, but also operator who 
messed with startup scripts), it has to be opened (warranty!).


These all unpleasant tasks could be avoided if it was possible to have a 
"fallback" device. For example, consider this hypothetical command line:

root=/dev/sdb1,/dev/sda1


/dev/sdb1 - USB-stick which can boot the device
/dev/sda1 - HDD which normally starts the device


It would mean, that kernel tries to boot the OS from /dev/sdb1, and if 
there isn't such a device, it tries to boot the OS from /dev/sda1.


In our case, /dev/sdb1 would be an external USB-stick capable to boot 
the device (in that case, we'd have to add rootdelay= option, too).
One would connect it only if he/she wants to service the device.

If /dev/sdb1 is not found by the kernel, the boot would start 
("fallback") from /dev/sda1.


Does this make sense?


As I understand correctly, the needed change would have to be done in 
init/do_mounts.c, around "static int __init do_mount_root" and "void 
__init mount_block_root"? Any clues on that?


-- 
Tomasz Chmielewski
http://wpkg.org

Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?

[Jan Engelhardt]

> The device is pretty small and has no keyboard, video card etc., so if it ever
> happens to break (can be a disk failure, but also operator who messed with
> startup scripts), it has to be opened (warranty!).
>
> These all unpleasant tasks could be avoided if it was possible to have a
> "fallback" device. For example, consider this hypothetical command line:
>
> root=/dev/sdb1,/dev/sda1

You should use initramfs to achieve that.


(Note that SD naming is anyway dynamic - if only one of USB or HDD
is plugged in, it will most likely become sda.)


	-`J'
-- 

Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?

[Alon Bar-Lev]

On 1/17/07, Tomasz Chmielewski <mangoo@wpkg.org> wrote:
> Does this make sense?

Why not add this logic into your initramfs?

Best Regards,
Alon Bar-Lev.

Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?

[Tomasz Chmielewski]

Alon Bar-Lev wrote:
> On 1/17/07, Tomasz Chmielewski <mangoo@wpkg.org> wrote:
>> Does this make sense?
> 
> Why not add this logic into your initramfs?

Because the kernel itself is on a small flash partition (RedBoot 
executes the kernel from /dev/mtd1), which is only 1572864 bytes big.

So it leaves me only about 300 kB left (kernel is about 1.2 MB) for all 
tools needed to script such a logic, and it includes all the tools I 
would need.
Another obstacle would be to place the initramfs image on the same 
partition as the kernel (normally, I dd kernel to /dev/mtd1).

Or perhaps, I don't understand initramfs correctly.


-- 
Tomasz Chmielewski
http://wpkg.org

Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?

[Alon Bar-Lev]

On 1/17/07, Tomasz Chmielewski <mangoo@wpkg.org> wrote:
> Another obstacle would be to place the initramfs image on the same
> partition as the kernel (normally, I dd kernel to /dev/mtd1).

As far as I know you can embed the initramfs into the kernel image using
CONFIG_INITRAMFS_SOURCE.

http://www.timesys.com/timesource/initramfs.htm

Best Regards,
Alon Bar-Lev.

Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?

[Tomasz Chmielewski]

Jan Engelhardt wrote:
>> The device is pretty small and has no keyboard, video card etc., so if it ever
>> happens to break (can be a disk failure, but also operator who messed with
>> startup scripts), it has to be opened (warranty!).
>>
>> These all unpleasant tasks could be avoided if it was possible to have a
>> "fallback" device. For example, consider this hypothetical command line:
>>
>> root=/dev/sdb1,/dev/sda1
> 
> You should use initramfs to achieve that.

All right.
I see that initramfs is attached to the kernel itself.

So it leaves me only a question: will I fit all tools into 300 kB 
(considering I'll use uClibc and busybox)?


-- 
Tomasz Chmielewski
http://wpkg.org

Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?

[Jan Engelhardt]

On Jan 17 2007 16:06, Alon Bar-Lev wrote:
> On 1/17/07, Tomasz Chmielewski <mangoo@wpkg.org> wrote:
>> Another obstacle would be to place the initramfs image on the same
>> partition as the kernel (normally, I dd kernel to /dev/mtd1).
>
> As far as I know you can embed the initramfs into the kernel image using
> CONFIG_INITRAMFS_SOURCE.
>
> http://www.timesys.com/timesource/initramfs.htm

The question was rather if
  (a) kernel code is cheaper than
  (b) userspace

And I say: neither. If things get really tight, write your own
init.c, compile with -static and link against uclibc/klibc, and let
it hopefully be small enough to fit.


	-`J'
-- 

Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?

[H. Peter Anvin]

Tomasz Chmielewski wrote:
> 
> All right.
> I see that initramfs is attached to the kernel itself.
> 
> So it leaves me only a question: will I fit all tools into 300 kB 
> (considering I'll use uClibc and busybox)?
> 

You don't need to use busybox and have a bunch of tools.

The klibc distribution comes with "kinit", which does the equivalent to 
the kernel root-mounting code; it's in the tens of kilobytes, at least 
on x86.  If you're using ARM, you can compile it as Thumb.

	-hpa

Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?

[Tomasz Chmielewski]

H. Peter Anvin wrote:
> Tomasz Chmielewski wrote:
>>
>> All right.
>> I see that initramfs is attached to the kernel itself.
>>
>> So it leaves me only a question: will I fit all tools into 300 kB 
>> (considering I'll use uClibc and busybox)?
>>
> 
> You don't need to use busybox and have a bunch of tools.
> 
> The klibc distribution comes with "kinit", which does the equivalent to 
> the kernel root-mounting code; it's in the tens of kilobytes, at least 
> on x86.  If you're using ARM, you can compile it as Thumb.

Hmm, I'm having problems compiling klibc-1.4 on ARM (using gcc-4.1.1):

# make
   GEN     klcc/klibc.config
   GEN     klcc/klcc
   HOSTCC  scripts/basic/fixdep
   GEN     usr/klibc/syscalls/SYSCALLS.i
   GEN     usr/klibc/syscalls/syscalls.nrs
   GEN     usr/klibc/syscalls/typesize.c
   KLIBCCC usr/klibc/syscalls/typesize.o
In file included from usr/klibc/../include/sys/poll.h:9,
                  from usr/klibc/../include/poll.h:1,
                  from usr/klibc/syscalls/syscommon.h:13,
                  from usr/klibc/syscalls/typesize.c:1:
usr/klibc/../include/sys/time.h:12: warning: 'struct timezone' declared 
inside parameter list
usr/klibc/../include/sys/time.h:12: warning: 'struct timeval' declared 
inside parameter list
usr/klibc/../include/sys/time.h:13: warning: 'struct timezone' declared 
inside parameter list
usr/klibc/../include/sys/time.h:13: warning: 'struct timeval' declared 
inside parameter list
usr/klibc/../include/sys/time.h:14: warning: 'struct itimerval' declared 
inside parameter list
usr/klibc/../include/sys/time.h:15: warning: 'struct itimerval' declared 
inside parameter list
usr/klibc/../include/sys/time.h:16: warning: 'struct timeval' declared 
inside parameter list
In file included from usr/klibc/../include/poll.h:1,
                  from usr/klibc/syscalls/syscommon.h:13,
                  from usr/klibc/syscalls/typesize.c:1:
usr/klibc/../include/sys/poll.h:18: warning: 'struct timespec' declared 
inside parameter list
In file included from usr/klibc/../include/sys/resource.h:10,
                  from usr/klibc/syscalls/syscommon.h:18,
                  from usr/klibc/syscalls/typesize.c:1:
/usr/include/linux/resource.h:24: error: field 'ru_utime' has incomplete 
type
/usr/include/linux/resource.h:25: error: field 'ru_stime' has incomplete 
type
In file included from usr/klibc/syscalls/syscommon.h:19,
                  from usr/klibc/syscalls/typesize.c:1:
usr/klibc/../include/sys/select.h:15: warning: 'struct timespec' 
declared inside parameter list
In file included from usr/klibc/syscalls/syscommon.h:20,
                  from usr/klibc/syscalls/typesize.c:1:
usr/klibc/../include/sys/socket.h:47: warning: 'struct msghdr' declared 
inside parameter list
usr/klibc/../include/sys/socket.h:48: warning: 'struct msghdr' declared 
inside parameter list
In file included from usr/klibc/../include/sys/stat.h:11,
                  from usr/klibc/syscalls/syscommon.h:21,
                  from usr/klibc/syscalls/typesize.c:1:
usr/include/arch/arm/klibc/archstat.h:33: error: field 'st_atim' has 
incomplete type
usr/include/arch/arm/klibc/archstat.h:34: error: field 'st_mtim' has 
incomplete type
usr/include/arch/arm/klibc/archstat.h:35: error: field 'st_ctim' has 
incomplete type
In file included from usr/klibc/syscalls/syscommon.h:21,
                  from usr/klibc/syscalls/typesize.c:1:
usr/klibc/../include/sys/stat.h: In function 'mkfifo':
usr/klibc/../include/sys/stat.h:30: error: 'S_IFMT' undeclared (first 
use in this function)
usr/klibc/../include/sys/stat.h:30: error: (Each undeclared identifier 
is reported only once
usr/klibc/../include/sys/stat.h:30: error: for each function it appears in.)
usr/klibc/../include/sys/stat.h:30: error: 'S_IFIFO' undeclared (first 
use in this function)
   LIST    usr/klibc/syscalls/syscalls.list
   GEN     usr/klibc/socketcalls/SOCKETCALLS.i
   GEN     usr/klibc/socketcalls/socketcalls.mk
   KLIBCCC usr/klibc/socketcalls/socket.o
In file included from usr/klibc/../include/sys/stat.h:10,
                  from usr/klibc/socketcalls/socketcommon.h:12,
                  from usr/klibc/socketcalls/socket.c:1:
usr/klibc/../include/sys/time.h:12: warning: 'struct timezone' declared 
inside parameter list
usr/klibc/../include/sys/time.h:12: warning: 'struct timeval' declared 
inside parameter list
usr/klibc/../include/sys/time.h:13: warning: 'struct timezone' declared 
inside parameter list
usr/klibc/../include/sys/time.h:13: warning: 'struct timeval' declared 
inside parameter list
usr/klibc/../include/sys/time.h:14: warning: 'struct itimerval' declared 
inside parameter list
usr/klibc/../include/sys/time.h:15: warning: 'struct itimerval' declared 
inside parameter list
usr/klibc/../include/sys/time.h:16: warning: 'struct timeval' declared 
inside parameter list
In file included from usr/klibc/../include/sys/stat.h:11,
                  from usr/klibc/socketcalls/socketcommon.h:12,
                  from usr/klibc/socketcalls/socket.c:1:
usr/include/arch/arm/klibc/archstat.h:33: error: field 'st_atim' has 
incomplete type
usr/include/arch/arm/klibc/archstat.h:34: error: field 'st_mtim' has 
incomplete type
usr/include/arch/arm/klibc/archstat.h:35: error: field 'st_ctim' has 
incomplete type
In file included from usr/klibc/socketcalls/socketcommon.h:12,
                  from usr/klibc/socketcalls/socket.c:1:
usr/klibc/../include/sys/stat.h: In function 'mkfifo':
usr/klibc/../include/sys/stat.h:30: error: 'S_IFMT' undeclared (first 
use in this function)
usr/klibc/../include/sys/stat.h:30: error: (Each undeclared identifier 
is reported only once
usr/klibc/../include/sys/stat.h:30: error: for each function it appears in.)
usr/klibc/../include/sys/stat.h:30: error: 'S_IFIFO' undeclared (first 
use in this function)
In file included from usr/klibc/socketcalls/socketcommon.h:14,
                  from usr/klibc/socketcalls/socket.c:1:
usr/klibc/../include/sys/socket.h: At top level:
usr/klibc/../include/sys/socket.h:47: warning: 'struct msghdr' declared 
inside parameter list
usr/klibc/../include/sys/socket.h:48: warning: 'struct msghdr' declared 
inside parameter list
make[3]: *** [usr/klibc/socketcalls/socket.o] Error 1
make[2]: *** [usr/klibc/socketcalls] Error 2
make[1]: *** [all] Error 2
make: *** [klibc] Error 2



-- 
Tomasz Chmielewski

Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?

[H. Peter Anvin]

Tomasz Chmielewski wrote:
> H. Peter Anvin wrote:
>> Tomasz Chmielewski wrote:
>>>
>>> All right.
>>> I see that initramfs is attached to the kernel itself.
>>>
>>> So it leaves me only a question: will I fit all tools into 300 kB 
>>> (considering I'll use uClibc and busybox)?
>>>
>>
>> You don't need to use busybox and have a bunch of tools.
>>
>> The klibc distribution comes with "kinit", which does the equivalent 
>> to the kernel root-mounting code; it's in the tens of kilobytes, at 
>> least on x86.  If you're using ARM, you can compile it as Thumb.
> 
> Hmm, I'm having problems compiling klibc-1.4 on ARM (using gcc-4.1.1):
> 

Could you send me your kernel .config, as well as what version of the 
kernel you're building against?

	-hpa

Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?

[Tomasz Chmielewski]

H. Peter Anvin wrote:
> Tomasz Chmielewski wrote:
>> H. Peter Anvin wrote:
>>> Tomasz Chmielewski wrote:
>>>>
>>>> All right.
>>>> I see that initramfs is attached to the kernel itself.
>>>>
>>>> So it leaves me only a question: will I fit all tools into 300 kB 
>>>> (considering I'll use uClibc and busybox)?
>>>>
>>>
>>> You don't need to use busybox and have a bunch of tools.
>>>
>>> The klibc distribution comes with "kinit", which does the equivalent 
>>> to the kernel root-mounting code; it's in the tens of kilobytes, at 
>>> least on x86.  If you're using ARM, you can compile it as Thumb.
>>
>> Hmm, I'm having problems compiling klibc-1.4 on ARM (using gcc-4.1.1):
>>
> 
> Could you send me your kernel .config, as well as what version of the 
> kernel you're building against?

I managed to compile a "Testing" 1.4.31 version (in fact, version 1.4 
didn't compile because I didn't have a "linux" link pointing to kernel 
sources; version 1.4.31 tells that it's missing - so both versions 
compile fine).

The problem is... I'm not sure how to start with it. The package doesn't 
have much documentation (other than "read the source"), does it?

On the other hand, I see it comes with a couple of useful tools, like sh 
(dash)... They are also pretty small, so everything should fit into 300 
kB (dash=70kB, kinit=70kB, mount=12kB).

As I understand, this is what I have to do:

1. compile a kernel with initramfs, which will include a cpio image with 
some tools

2. tools/scripts in cpio image should do the following:

mount /proc
DISKS=$(cat /proc/diskstats)
for WORD in $DISKS
do
[ $WORD = sdb1 ] && echo "partition found, what next?..."
done

# do a similar logic for sda1


Am I correct? Of course I'd appreciate how to achieve point 2 (where now 
"partition found, what next?..." is).


-- 
Tomasz Chmielewski
http://wpkg.org

Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?

[H. Peter Anvin]

Tomasz Chmielewski wrote:
> 
> I managed to compile a "Testing" 1.4.31 version (in fact, version 1.4 
> didn't compile because I didn't have a "linux" link pointing to kernel 
> sources; version 1.4.31 tells that it's missing - so both versions 
> compile fine).
> 

At this point, 1.4.31 is probably what you should be using.

> The problem is... I'm not sure how to start with it. The package doesn't 
> have much documentation (other than "read the source"), does it?
> 
> On the other hand, I see it comes with a couple of useful tools, like sh 
> (dash)... They are also pretty small, so everything should fit into 300 
> kB (dash=70kB, kinit=70kB, mount=12kB).

With kinit you don't even need dash/mount... kinit is a monolithic 
binary for everything.

In other words, you'd typically use *either* dash+mount, *or* kinit...

	-hpa

Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?

[Al Borchers]

Tomasz Chmielewski wrote:
> Al Borchers wrote:
> 
>> Thomas Chmielewski wrote:
>>
>>> These all unpleasant tasks could be avoided if it was possible to 
>>> have a "fallback" device. For example, consider this hypothetical 
>>> command line:
>>>
>>> root=/dev/sdb1,/dev/sda1
>>
>>
>> Here is a patch to do this, though it sounds like you might have other
>> solutions.
>>
>> This patch is for 2.6.18.1--thanks to Ed Falk for updating my original
>> 2.6.11 patch.  If people are interested I can update and test this on
>> the current kernel.  It was tested on 2.6.11.
> 
> 
> Yes, I'd be interested in a patch against a 2.6.19. It is way simpler to 
> do it this way than to do it with initramfs (although not as flexible).

I will look do it, but I will be out next week so it may take a while.

-- Al

> 
> I tried your patch against 2.6.19, with some minor changes (as it 
> wouldn't apply), but it didn't work for me (perhaps I just screwed 
> something).
> 
> 

Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?

[H. Peter Anvin]

Tomasz Chmielewski wrote:
> Al Borchers wrote:
>> Thomas Chmielewski wrote:
>>> These all unpleasant tasks could be avoided if it was possible to 
>>> have a "fallback" device. For example, consider this hypothetical 
>>> command line:
>>>
>>> root=/dev/sdb1,/dev/sda1
>>
>> Here is a patch to do this, though it sounds like you might have other
>> solutions.
>>
>> This patch is for 2.6.18.1--thanks to Ed Falk for updating my original
>> 2.6.11 patch.  If people are interested I can update and test this on
>> the current kernel.  It was tested on 2.6.11.
> 
> Yes, I'd be interested in a patch against a 2.6.19. It is way simpler to 
> do it this way than to do it with initramfs (although not as flexible).
> 
> I tried your patch against 2.6.19, with some minor changes (as it 
> wouldn't apply), but it didn't work for me (perhaps I just screwed 
> something).
> 

I just might want to point this as an example on the fact that as long 
as the in-kernel mounting code (as opposed to integrated klibc) exists, 
it will want to grow features...

	-hpa

Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?

[Tomasz Chmielewski]

Al Borchers wrote:
> Thomas Chmielewski wrote:
>> These all unpleasant tasks could be avoided if it was possible to have a 
>> "fallback" device. For example, consider this hypothetical command line:
>>
>> root=/dev/sdb1,/dev/sda1
> 
> Here is a patch to do this, though it sounds like you might have other
> solutions.
> 
> This patch is for 2.6.18.1--thanks to Ed Falk for updating my original
> 2.6.11 patch.  If people are interested I can update and test this on
> the current kernel.  It was tested on 2.6.11.

Yes, I'd be interested in a patch against a 2.6.19. It is way simpler to 
do it this way than to do it with initramfs (although not as flexible).

I tried your patch against 2.6.19, with some minor changes (as it 
wouldn't apply), but it didn't work for me (perhaps I just screwed 
something).


-- 
Tomasz Chmielewski
http://wpkg.org

Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?

[Al Borchers]

Thomas Chmielewski wrote:
> These all unpleasant tasks could be avoided if it was possible to have a 
> "fallback" device. For example, consider this hypothetical command line:
> 
> root=/dev/sdb1,/dev/sda1

Here is a patch to do this, though it sounds like you might have other
solutions.

This patch is for 2.6.18.1--thanks to Ed Falk for updating my original
2.6.11 patch.  If people are interested I can update and test this on
the current kernel.  It was tested on 2.6.11.

Please CC me with any comments.

-- Al


diff -uprN linux-2.6.18.1/init/do_mounts.c comma_root/init/do_mounts.c
--- linux-2.6.18.1/init/do_mounts.c	2006-10-13 20:34:03.000000000 -0700
+++ comma_root/init/do_mounts.c	2006-11-17 16:22:14.000000000 -0800
@@ -280,8 +280,9 @@ static int __init do_mount_root(char *na
 	return 0;
 }
 
-void __init mount_block_root(char *name, int flags)
+static int __init mount_block_root_try(char *name, int flags)
 {
+	int err;
 	char *fs_names = __getname();
 	char *p;
 	char b[BDEVNAME_SIZE];
@@ -289,7 +290,7 @@ void __init mount_block_root(char *name,
 	get_fs_names(fs_names);
 retry:
 	for (p = fs_names; *p; p += strlen(p)+1) {
-		int err = do_mount_root(name, p, flags, root_mount_data);
+		err = do_mount_root(name, p, flags, root_mount_data);
 		switch (err) {
 			case 0:
 				goto out;
@@ -307,19 +308,33 @@ retry:
 		printk("VFS: Cannot open root device \"%s\" or %s\n",
 				root_device_name, b);
 		printk("Please append a correct \"root=\" boot option\n");
-
-		panic("VFS: Unable to mount root fs on %s", b);
 	}
 
 	printk("No filesystem could mount root, tried: ");
 	for (p = fs_names; *p; p += strlen(p)+1)
 		printk(" %s", p);
 	printk("\n");
-	panic("VFS: Unable to mount root fs on %s", __bdevname(ROOT_DEV, b));
+
+	err = -1;
 out:
 	putname(fs_names);
+	return err;
 }
- 
+
+static inline void __init mount_block_root_fail(void)
+{
+	char b[BDEVNAME_SIZE];
+
+	panic("VFS: Unable to mount root fs on %s", __bdevname(ROOT_DEV, b));
+}
+
+void __init mount_block_root(char *name, int flags)
+{
+	if (mount_block_root_try(name, flags) != 0)
+		mount_block_root_fail();
+}
+
+
 #ifdef CONFIG_ROOT_NFS
 static int __init mount_nfs_root(void)
 {
@@ -363,12 +378,12 @@ void __init change_floppy(char *fmt, ...
 }
 #endif
 
-void __init mount_root(void)
+static int __init mount_root_try(void)
 {
 #ifdef CONFIG_ROOT_NFS
 	if (MAJOR(ROOT_DEV) == UNNAMED_MAJOR) {
 		if (mount_nfs_root())
-			return;
+			return 0;
 
 		printk(KERN_ERR "VFS: Unable to mount root fs via NFS, trying floppy.\n");
 		ROOT_DEV = Root_FD0;
@@ -387,7 +402,18 @@ void __init mount_root(void)
 	}
 #endif
 	create_dev("/dev/root", ROOT_DEV);
-	mount_block_root("/dev/root", root_mountflags);
+	return mount_block_root_try("/dev/root", root_mountflags);
+}
+
+static inline void __init mount_root_fail(void)
+{
+	mount_block_root_fail();
+}
+
+void __init mount_root(void)
+{
+	if (mount_root_try() != 0)
+		mount_root_fail();
 }
 
 /*
@@ -396,6 +422,7 @@ void __init mount_root(void)
 void __init prepare_namespace(void)
 {
 	int is_floppy;
+	char *p,*pnext;
 
 	if (root_delay) {
 		printk(KERN_INFO "Waiting %dsec before mounting root device...\n",
@@ -405,27 +432,36 @@ void __init prepare_namespace(void)
 
 	md_run_setup();
 
-	if (saved_root_name[0]) {
-		root_device_name = saved_root_name;
+	for (p=saved_root_name; p && *p; p=pnext) {
+		pnext = strchr(p, ',');
+		if (pnext)
+			*pnext++ = '\0';
+		root_device_name = p;
 		if (!strncmp(root_device_name, "mtd", 3)) {
 			mount_block_root(root_device_name, root_mountflags);
 			goto out;
 		}
 		ROOT_DEV = name_to_dev_t(root_device_name);
+		if (ROOT_DEV == (dev_t)0)
+			continue;
 		if (strncmp(root_device_name, "/dev/", 5) == 0)
 			root_device_name += 5;
-	}
 
-	is_floppy = MAJOR(ROOT_DEV) == FLOPPY_MAJOR;
+		is_floppy = MAJOR(ROOT_DEV) == FLOPPY_MAJOR;
 
-	if (initrd_load())
-		goto out;
+		if (initrd_load())
+			goto out;
 
-	if (is_floppy && rd_doload && rd_load_disk(0))
-		ROOT_DEV = Root_RAM0;
+		if (is_floppy && rd_doload && rd_load_disk(0))
+			ROOT_DEV = Root_RAM0;
 
-	mount_root();
+		if (mount_root_try() == 0)
+			goto out;
+
+	}
+	mount_root_fail();
 out:
+	sys_unlink("/initrd.image");
 	sys_mount(".", "/", NULL, MS_MOVE, NULL);
 	sys_chroot(".");
 	security_sb_post_mountroot();
diff -uprN linux-2.6.18.1/init/do_mounts_initrd.c comma_root/init/do_mounts_initrd.c
--- linux-2.6.18.1/init/do_mounts_initrd.c	2006-10-13 20:34:03.000000000 -0700
+++ comma_root/init/do_mounts_initrd.c	2006-11-17 15:45:18.000000000 -0800
@@ -113,11 +113,9 @@ int __init initrd_load(void)
 		 * mounted in the normal path.
 		 */
 		if (rd_load_image("/initrd.image") && ROOT_DEV != Root_RAM0) {
-			sys_unlink("/initrd.image");
 			handle_initrd();
 			return 1;
 		}
 	}
-	sys_unlink("/initrd.image");
 	return 0;
 }