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
On 1/17/07, Tomasz Chmielewski <[email protected]> wrote:
> Does this make sense?
Why not add this logic into your initramfs?
Best Regards,
Alon Bar-Lev.
> 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'
--
Alon Bar-Lev wrote:
> On 1/17/07, Tomasz Chmielewski <[email protected]> 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
On 1/17/07, Tomasz Chmielewski <[email protected]> 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.
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
On Jan 17 2007 16:06, Alon Bar-Lev wrote:
> On 1/17/07, Tomasz Chmielewski <[email protected]> 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'
--
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
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
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
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;
}
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
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
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
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
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).
>
>