From: "Shawn Jin" <shawnxjin@gmail.com>
To: "Stefan Richter" <stefanr@s5r6.in-berlin.de>
Cc: "Tomasz Chmielewski" <mangoo@wpkg.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: Force a usb drive to be /dev/sda?
Date: Thu, 12 Jun 2008 22:32:48 -0700 [thread overview]
Message-ID: <c3d0340b0806122232s72d37509wd976217d336b83e7@mail.gmail.com> (raw)
In-Reply-To: <4851046E.907@s5r6.in-berlin.de>
First, thanks a lot for the responses, especially to Stefan for the
various options. I have further questions on these options to fully
understand them.
>> Is there a reason why you can't use filesystem labels or UUIDs?
>
> Indeed. Shawn, I see these options:
>
> 1. Mount filesystems by UUID or by label.
> Doesn't work with some filesystems.
The bootloader I'm using is LILO. So I have to specify the boot device
and the root device in lilo.conf. For example, boot=/dev/sda,
root=/dev/sda1. I'm not sure how mounting filesystem by UUID or by
label can help. A little bit elaboration will be more helpful.
> 2. Refer to devices by device ID or by device path.
> Requires a minimal udev environment which gives you
> /dev/disk/by-id or /dev/disk/by-path, or something
> similar to udev. People had things like this already
> working under Linux 2.4, using programs like devlabel
> IIRC. Requires you to set up an initrd with respective
> scripts in it.
> By-path only works if you never alter the USB topology
> and PCI topology. I.e. prefer by-id.
Every USB thumb drive has a unique ID. So will I have to have a
different root filesystem image if it's install in a different usb
drive if the by-id way is adopted?
> 3. Influence the order of disk probing so that your USB
> disk is the first one. Works only if there is at most
> one disk on the USB bus and requires you to wait with
> insertion or probing of the SATA controller driver (PCI
> driver) until after the USB disk was probed by sd_mod.
>
> There may or may not be very simple ways to do this.
> Simplest would be to configure the SATA controller driver
> as module and load that module in an rc script after the
> root filesystem was mounted. That would actually be much
> simpler than option 2, so maybe you want to try this
> before 2.
I think I understand this option. Of course this requires an initrd or
initramfs, which I need to build.
> 4. Last resort: Hack sd_mod to defer any probes until after
> the first probe of an USB attached disk. Requires some
> experience in kernel driver programming.
As you said, this is the last resort, which I also try to avoid. ;-)
-Shawn.
next prev parent reply other threads:[~2008-06-13 5:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-12 8:35 Tomasz Chmielewski
2008-06-12 11:11 ` Stefan Richter
2008-06-13 5:32 ` Shawn Jin [this message]
2008-06-13 6:35 ` Stefan Richter
2008-06-13 20:29 ` Shawn Jin
2008-06-13 21:54 ` Stefan Richter
-- strict thread matches above, loose matches on Subject: below --
2008-06-12 6:05 Shawn Jin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c3d0340b0806122232s72d37509wd976217d336b83e7@mail.gmail.com \
--to=shawnxjin@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mangoo@wpkg.org \
--cc=stefanr@s5r6.in-berlin.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®