Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?
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). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?
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.0 -0700
+++ comma_root/init/do_mounts.c 2006-11-17 16:22:14.0 -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;
+
+ }
+ mou
Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?
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) LISTusr/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.
Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?
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' -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?
> 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' -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
