Hi,
Is it possible to force a usb drive to be /dev/sda? I put an entire
linux system to a usb drive and want it boot a system with variable
sata disks. However the usb drive is always scanned as a last scsi
drive.
TIA.
-Shawn.
> Is it possible to force a usb drive to be /dev/sda? I put an entire
> linux system to a usb drive and want it boot a system with variable
> sata disks. However the usb drive is always scanned as a last scsi
> drive.
Is there a reason why you can't use filesystem labels or UUIDs?
--
Tomasz Chmielewski
http://wpkg.org
Tomasz Chmielewski wrote:
>> Is it possible to force a usb drive to be /dev/sda? I put an entire
>> linux system to a usb drive and want it boot a system with variable
>> sata disks. However the usb drive is always scanned as a last scsi
>> drive.
>
> 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.
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.
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.
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.
--
Stefan Richter
-=====-==--- -==- -==--
http://arcgraph.de/sr/
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.
Shawn Jin wrote:
>> 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.
Ah I forgot that... Looks like this requires an initrd too, though
without special scripts of your own.
>> 2. Refer to devices by device ID or by device path.
...
> 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?
That's right, hence a filesystem ID is preferable over a drive ID.
--
Stefan Richter
-=====-==--- -==- -==-=
http://arcgraph.de/sr/
Hi Stefan,
>>> 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.
>
> Ah I forgot that... Looks like this requires an initrd too, though without
> special scripts of your own.
Forgive my slowness to understand your suggestion. The kernel I built
has all the sata drivers, usb drivers, and scsi layer built in. So
during the kernel bootup before the root is mounted, all drives (sata
and usb) are scanned and detected. How does an initrd plus mounting
the root filesystem by UUID or label help here? Or how can I set the
"root" in the lilo.conf?
If an initrd is used, I would rather go with option 3. That is, build
SATA drivers as loadable modules and load them in the initrd. Then
before initrd loads sata drivers, there is only one usb drive as
/dev/sda.
Also I'm lost by this comment: "though without special scripts of your
own". Could you explain it in another way? Were you saying that I need
my own special scripts to mount the root filesystem by UUID or label?
I think this is quite obvious since I need to build an initrd, which
is always customized. :-P
Thanks,
-Shawn.
Shawn Jin wrote:
>>> 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.
>> Ah I forgot that... Looks like this requires an initrd too, though without
>> special scripts of your own.
>
> Forgive my slowness to understand your suggestion. The kernel I built
> has all the sata drivers, usb drivers, and scsi layer built in. So
> during the kernel bootup before the root is mounted, all drives (sata
> and usb) are scanned and detected. How does an initrd plus mounting
> the root filesystem by UUID or label help here? Or how can I set the
> "root" in the lilo.conf?
I haven't used lilo for a while, nor initrd, hence I can't give you a
detailed recipe. You specify the initrd as device with root filesystem
to the boot manager. In the initrd you have e.g. an fstab by which you
mount the later root filesystem based on the filesystem ID. Then the
initrd chroots to that fs.
> If an initrd is used, I would rather go with option 3. That is, build
> SATA drivers as loadable modules and load them in the initrd. Then
> before initrd loads sata drivers, there is only one usb drive as
> /dev/sda.
In that case you don't need an initrd at all.
> Also I'm lost by this comment: "though without special scripts of your
> own". Could you explain it in another way? Were you saying that I need
> my own special scripts to mount the root filesystem by UUID or label?
> I think this is quite obvious since I need to build an initrd, which
> is always customized. :-P
A little bit more would be necessary if the initrd had to pick up device
IDs. If you just use the initrd to load some modules and to mount the
subsequent root fs, it won't really look different from most distributor
initrds AFAICS.
--
Stefan Richter
-=====-==--- -==- -==-=
http://arcgraph.de/sr/