linux device ordering at boot time

linux device ordering at boot time

[Lars Callenbach]

I have a question concerning the ordering of devices during the boot process and I hope that the kernel mailing list is the right place for this question.
In my computer are two raid controllers with one raid array connected to each of them (/dev/sda, /dev/sdb). In the debian 2.6.18 boot process the ordering is root @ /dev/sda and data are on /dev/sdb. This behaviour has changed in the plain 2.6.23.1 (and 2.6.23.8) kernel. The /dev/sd(a|b) devices have switched so that root @ /dev/sdb. So my standard fstab does not work.
What determines the device ordering during the boot process? What is a workaround for this problem?

Thank you very much for some hints,
   Lars

-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

Re: linux device ordering at boot time

[Oliver Pinter (Pintér Olivér)]

I don't know, what the proble, but the fstab workaround  functioniert:
form:
/dev/sda3       /               xfs     defaults        0       1
to:
UUID=7c167a53-30ff-4d47-a206-ce8caf2397ba       /               xfs
 defaults        0       1

in this fix switched form device name to UUID based fstab.

the uuid-s queried with /lib/udev/vol_id program

/*sorry for bad english*/

On 1/19/08, Lars Callenbach <lars.callenbach@gmx.de> wrote:
> I have a question concerning the ordering of devices during the boot process
> and I hope that the kernel mailing list is the right place for this
> question.
> In my computer are two raid controllers with one raid array connected to
> each of them (/dev/sda, /dev/sdb). In the debian 2.6.18 boot process the
> ordering is root @ /dev/sda and data are on /dev/sdb. This behaviour has
> changed in the plain 2.6.23.1 (and 2.6.23.8) kernel. The /dev/sd(a|b)
> devices have switched so that root @ /dev/sdb. So my standard fstab does not
> work.
> What determines the device ordering during the boot process? What is a
> workaround for this problem?
>
> Thank you very much for some hints,
>    Lars
>
> --
> Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
> Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
> --
> 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/
>


-- 
Thanks,
Oliver

Re: linux device ordering at boot time

[Jan Engelhardt]

On Jan 19 2008 20:14, Oliver Pinter (Pintér Olivér) wrote:
>
>I don't know, what the proble, but the fstab workaround  functioniert:
>form:
>/dev/sda3       /               xfs     defaults        0       1
>to:
>UUID=7c167a53-30ff-4d47-a206-ce8caf2397ba       /               xfs
> defaults        0       1
>
>in this fix switched form device name to UUID based fstab.
>
>the uuid-s queried with /lib/udev/vol_id program

Any distro that uses udev can use /dev/disk/by-.../...
without having to resort to per-program specific implementations
(or lack thereof) of UUID= or LABEL=.

Re: linux device ordering at boot time

[Hans-Peter Jansen]

Am Samstag, 19. Januar 2008 schrieben Sie:
> I have a question concerning the ordering of devices during the boot
> process and I hope that the kernel mailing list is the right place for
> this question. In my computer are two raid controllers with one raid
> array connected to each of them (/dev/sda, /dev/sdb). In the debian
> 2.6.18 boot process the ordering is root @ /dev/sda and data are on
> /dev/sdb. This behaviour has changed in the plain 2.6.23.1 (and 2.6.23.8)
> kernel. The /dev/sd(a|b) devices have switched so that root @ /dev/sdb.
> So my standard fstab does not work. What determines the device ordering
> during the boot process? What is a workaround for this problem?

Well, it's a major pain in the a**. I've no idea, what reversed the order of 
PCI devices, but I had to disable the automatic dvb driver loading in order 
to get the picture back (dedicated vdr system with one FF and one budget 
card). I could have taken the route of exchanging the cards, but that would 
have been even more painful..

Oh well,
Pete

Re: linux device ordering at boot time

[Alan Cox]

> Well, it's a major pain in the a**. I've no idea, what reversed the order of 
> PCI devices, but I had to disable the automatic dvb driver loading in order 

It depends on the order you load the modules

Alan

Re: linux device ordering at boot time

[Hans-Peter Jansen]

Dear Alan, dear kernel & dvb hackers,

Am Sonntag, 20. Januar 2008 schrieb Alan Cox:
> > Well, it's a major pain in the a**. I've no idea, what reversed the
> > order of PCI devices, but I had to disable the automatic dvb driver
> > loading in order
>
> It depends on the order you load the modules

Sure, but given, that userspace didn't changed meanwhile, I relied on some 
hotplug figure before (in openSUSE 10.2 with 2.6.18) to load the modules in 
the correct order which itself surely enumerates the PCI bus in some way.

After switching to 2.6.24-rc this order was reversed. At least, my budget 
card was first now, while the ff dvb card second, which resulted in a 
working vdr, unfortunately without picture and sound (that dropped the WAF 
immensely 8-|). 

I solved this issue by blacklisting both cards in /etc/modprobe.d/blacklist, 
and manually determined the order and which modules to load, only to 
discover, that the system won't wake up on the scheduled times anymore. 
Ahh, /proc/acpi/alarm disappeared and needed adaption 
to /sys/class/rtc/rtc0/wakealarm. That move seems to have (yet to examine, 
but easy to work around) timezone issues. On the bright side, this new 
interface doesn't interfere with setting the c-mos clock on power down 
anymore. One gross hack down. Cool.

The last regressions awaiting to get tackled are:
 - rewind is somewhat broken: after a few seconds rewinding correctly, the
   pictures stutter, and vdr uses cpu like mad.
 - from time to time, the same happens for a few seconds on simple replay.

Both issues _feel_ like locking artefacts, which 2.6.18 (with 
http://linuxtv.org/hg/v4l-dvb drivers) didn't suffer from (my vdr operates 
mostly on nfs3 mounted files). I'm trying to explore these problems in more 
detail and will come back. For the record, these issues happen with the 
factory drivers/media modules and with drivers from v4l-dvb tree.

Please don't get me wrong, I'm not whining about all this, it's just a 
report from user side about what happens, if one tries to follow a strong 
moving target. Take it as a reminder, that some decisions during (kernel) 
development does have an wider impact on us poor users out there, as it 
seems.

The only thing, what makes me really sad, is that current dvb development is 
distracted by political and emotional (ego-logical) reasons, repressing  
the full potential in this area.

Pete

Re: linux device ordering at boot time

[Lars Callenbach]

Hello,

I followed your discussion. I still have a problem. The workaround of Alan works fine from a technical point of view using mkinitramfs. Now the hardware is assigned to the right devices. But I have some commercial software that (somehow) determines the "setup" of the computer. After the mkinitramfs change this setup has changed and the software does not work any more. Unfortunately my previous running image does not work at the moment (same problem, maybe related to "grub"). 

Are there other "simple" workarounds? Are there some simple steps that can be used to change the setup?

>From my point of view the following might be a solution. A policy should define how  information related to kernel functionality and hardware can be determined over a long time period. This can be defined by kernel (and kernel related) developers, software vendors and linux distributors. It can be something similar to "udev should be part of any linux installation and use UUID as id".


Thank you very much for your hints,
   Lars


-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail