Re: getting usb mass storage to finish before running init?

Re: getting usb mass storage to finish before running init?

[der.eremit]

On Fri, 13 Feb 2004 03:00:21 +0100, you wrote in linux.kernel:

> I can put a sleep in there but that is sloppy, and can not really be
> relied apon (since technically there is no way I can know how long the
> detection phase will take), and also I may be waisting time (which I don't
> want to, I want a fast booting router).

Check available devices for root filesystem (in case you're booting
from IDE). If it's not there, wait a moment, then look for additional
devices. If nothing shows up, repeat.

-- 
Ciao,
Pascal

Re: getting usb mass storage to finish before running init?

[Nick Bartos]

well, the root filesystem is an initrd, so I can't do that.

I suppose I could compile in the extra info for /proc/partitions and see
if that gives me anything I can keep looking for (don't know if it puts
file system labels in there, but that is probably what I would have to go
on since that is really the only thing that is constant on all systems).

Is there a quick/clean way to query a device and get the label?  I suppose
I could use tune2fs or something, but I didn't know if there is anything
better/simpler.  I don't know if I like the idea of running tune2fs on
each partition again and again.  I guess I could keep a list in memory and
only check each one once, but that is getting a bit more complicated &
time consuming.


>
> Check available devices for root filesystem (in case you're booting
> from IDE). If it's not there, wait a moment, then look for additional
> devices. If nothing shows up, repeat.
>
> --
> Ciao,
> Pascal
>

Re: getting usb mass storage to finish before running init?

[der.eremit]

On Thu, 12 Feb 2004, Nick Bartos wrote:

> well, the root filesystem is an initrd, so I can't do that.

Then I mean look for the filesystem you want to mount.

> I suppose I could compile in the extra info for /proc/partitions and see
> if that gives me anything I can keep looking for (don't know if it puts
> file system labels in there, but that is probably what I would have to go
> on since that is really the only thing that is constant on all systems).

Well, if you know what filesystem type is wanted you could just attempt
to mount all the partitions from /proc/partitions with that type
(read-only) and look for a unique file - if it's there, keep the fs
mounted, otherwise umount and try next candidate.

That's basically what I do in an initrd I wrote for CD-ROM booting, I'm
just trying to mount iso9660 filesystems and look for /etc/rc.d/rc.cdrom
when it succeeds. Better ways to identifiy a block device exist, I'm
sure, but the approach works for me. I'm narrowing down the search by
scanning the dmesg buffer for ATAPI and SCSI CD-ROM detection messages,
but that approach doesn't work for your problem (and is also fragile
when using it across several kernel versions).

> Is there a quick/clean way to query a device and get the label?

findfs from the e2fsprogs package, maybe.

> I suppose
> I could use tune2fs or something, but I didn't know if there is anything
> better/simpler.  I don't know if I like the idea of running tune2fs on
> each partition again and again.  I guess I could keep a list in memory and
> only check each one once, but that is getting a bit more complicated &
> time consuming.

Well, it's read-only access, so I don't see a problem even with running
it multiple times on the same device. Keeping a list of already tried
devices isn't black magic, though.

-- 
Ciao,
Pascal

Re: getting usb mass storage to finish before running init?

[Nick Bartos]

I realized that in my config only the flash disk has 2 partitions (the
rest will only ever have one), so what I will do is keep looking every
second in /proc/partitions for a disk that has a second partitions, then
if I find any, I will go through and use tune2fs to check the label on it
and make sure it matches the one I am looking for (just in case for some
reason there is another disk in there with a second partition).  If I
don't find a match by a certain timeout period, I will exit with a
critical error.  Since I don't think that any of these systems will have
more than one disk I will need to run tune2fs on, I won't keep track of
scanned devices.  If that changes I can always tweek the code.

This isn't as elegant as I wanted, but it should be reliable since I would
be waiting on something that directly tells me that the flash device is
ready to go, instead of only waiting an arbitrary amount of time.



> On Thu, 12 Feb 2004, Nick Bartos wrote:
>
>> well, the root filesystem is an initrd, so I can't do that.
>
> Then I mean look for the filesystem you want to mount.
>
>> I suppose I could compile in the extra info for /proc/partitions and see
>> if that gives me anything I can keep looking for (don't know if it puts
>> file system labels in there, but that is probably what I would have to
>> go
>> on since that is really the only thing that is constant on all systems).
>
> Well, if you know what filesystem type is wanted you could just attempt
> to mount all the partitions from /proc/partitions with that type
> (read-only) and look for a unique file - if it's there, keep the fs
> mounted, otherwise umount and try next candidate.
>
> That's basically what I do in an initrd I wrote for CD-ROM booting, I'm
> just trying to mount iso9660 filesystems and look for /etc/rc.d/rc.cdrom
> when it succeeds. Better ways to identifiy a block device exist, I'm
> sure, but the approach works for me. I'm narrowing down the search by
> scanning the dmesg buffer for ATAPI and SCSI CD-ROM detection messages,
> but that approach doesn't work for your problem (and is also fragile
> when using it across several kernel versions).
>
>> Is there a quick/clean way to query a device and get the label?
>
> findfs from the e2fsprogs package, maybe.
>
>> I suppose
>> I could use tune2fs or something, but I didn't know if there is anything
>> better/simpler.  I don't know if I like the idea of running tune2fs on
>> each partition again and again.  I guess I could keep a list in memory
>> and
>> only check each one once, but that is getting a bit more complicated &
>> time consuming.
>
> Well, it's read-only access, so I don't see a problem even with running
> it multiple times on the same device. Keeping a list of already tried
> devices isn't black magic, though.
>
> --
> Ciao,
> Pascal
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: getting usb mass storage to finish before running init?

[Randy Dunlap]

> On Fri, 13 Feb 2004 03:00:21 +0100, you wrote in linux.kernel:
>
>> I can put a sleep in there but that is sloppy, and can not really be
>> relied apon (since technically there is no way I can know how long the
>> detection phase will take), and also I may be waisting time (which I
>> don't want to, I want a fast booting router).
>
> Check available devices for root filesystem (in case you're booting from
> IDE). If it's not there, wait a moment, then look for additional
> devices. If nothing shows up, repeat.

That's basically what my usb-boot patch for 2.4.22 does:
  http://www.xenotime.net/linux/usb/usbboot-2422.patch

I haven't tried to port it to 2.6.x.
---
~Randy

Re: getting usb mass storage to finish before running init?

[der.eremit]

On Thu, 12 Feb 2004, Randy Dunlap wrote:

> > Check available devices for root filesystem (in case you're booting from
> > IDE). If it's not there, wait a moment, then look for additional
> > devices. If nothing shows up, repeat.
>
> That's basically what my usb-boot patch for 2.4.22 does:
>   http://www.xenotime.net/linux/usb/usbboot-2422.patch
>
> I haven't tried to port it to 2.6.x.

I don't think this requires in-kernel code once an initrd or
initramfs is going.

Here's what I use for CD-ROM booting (compiles to 370k statically
linked code using glibc):

#include <sys/klog.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <sys/mount.h>

#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

int pivot_root(const char *new_root, const char *put_old);

#define KLOG_GET_MESSAGES	3
#define KLOG_SET_LOGLEVEL	8

#define BUFSIZE		65536
#define DEVNAMEMAX	16
#define UNIQUEFILE	"/mnt/etc/rc.d/rc.cdrom"

void halt_system(void)
{
	while (1)
		;
}

void check_okay(int res, const char *errmsg)
{
	if (res < 0) {
		printf("Error: %s\n", errmsg);
		halt_system();
	}
}

int correct_medium(const char *devname)
{
	int res;
	struct stat buf;

	res = mount(devname, "/mnt", "iso9660", (0xC0ED << 16) | MS_RDONLY, 0);
	if (res == -1) {
		printf("No suitable medium on %s\n", devname);
		return 0;
	}

	res = stat(UNIQUEFILE, &buf);
	if (res == -1) {
		umount("/mnt");
		printf("Unrelated filesystem on %s\n", devname);
		return 0;
	}

	printf("Root filesystem found on %s\n", devname);
	return 1;
}

void change_root(void)
{
	int res;

	res = chdir("/mnt");
	check_okay(res, "could not cd into CD-ROM root filesystem");

	res = pivot_root("/mnt", "/mnt/initrd");
	check_okay(res, "could not change / to CD-ROM root filesystem");

	execl("/sbin/init", "/sbin/init");

	check_okay(-1, "could not execute /sbin/init");
}

int main(int argc, char **argv)
{
	char buf[BUFSIZE];
	char devname[DEVNAMEMAX];
	char *work, *line, *sub;
	int res, found = 0;

	puts("Attempting to locate CD-ROM device");

	klogctl(KLOG_SET_LOGLEVEL, NULL, 1);

	memset(buf, 0, BUFSIZE);

	res = klogctl(KLOG_GET_MESSAGES, buf, BUFSIZE);
	check_okay(res, "could not read kernel messages");

	work = buf;
	while (work) {
		line = strsep(&work, "\n");

		sub = strstr(line, "ATAPI CD/DVD-ROM drive");
		if (sub) {
			memset(devname, 0, DEVNAMEMAX);
			strcpy(devname, "/dev/");
			memcpy(devname+5, line+3, 3);

			printf("ATAPI CD-ROM at: %s\n", devname);

			if (correct_medium(devname))
				change_root();

			found = 1;
		}

		sub = strstr(line, "Attached scsi CD-ROM sr");
		if (sub) {
			memset(devname, 0, DEVNAMEMAX);
			strcpy(devname, "/dev/scd");
			memcpy(devname+8, line+26, 1);

			printf("SCSI CD-ROM at: %s\n", devname);

			if (correct_medium(devname))
				change_root();

			found = 1;
		}
	}

	if (!found)
		puts("No CD-ROM device found");
	else
		puts("Root filesystem not found on CD-ROM device(s)");

	halt_system();

	/* NOT REACHED */
	return 0;
}

-- 
Ciao,
Pascal

getting usb mass storage to finish before running init?

[Nick Bartos]

Is there any way to get the kernel to finish initializing usb mass storage
devices before running init?

I have a problem where I am trying to boot off usb, but the storage device
is not detected when I am trying to do fsck and mount the flash device
from my init scripts.

I can put a sleep in there but that is sloppy, and can not really be
relied apon (since technically there is no way I can know how long the
detection phase will take), and also I may be waisting time (which I don't
want to, I want a fast booting router).

I cannot poll to wait for the device to exist in /proc/partitions or in
/dev, since some routers will boot off ide and may not even have usb
devices.

I would like to hack the kernel to wait to run init until after the usb
stuff is done (although I don't really know where to start, I don't know
where the usb or init stuff is ran from), or find some clean & reliable
way of detecting when it is done (even if it doesn't need to load usb).

I was sort of hoping there was some little-known kernel option that may
help me...

Ideas?