Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1461701 > unrolled thread

Who reordered my disks (probably v4.8-rc1 problem)

Back to article view | Back to linux.kernel

Contents

  Who reordered my disks (probably v4.8-rc1 problem) Pavel Machek <pavel@ucw.cz> - 2016-08-14 10:40 +0200
    Re: Who reordered my disks (probably v4.8-rc1 problem) james harvey <jamespharvey20@gmail.com> - 2016-08-14 11:10 +0200
      Re: Who reordered my disks (probably v4.8-rc1 problem) Pavel Machek <pavel@ucw.cz> - 2016-08-14 11:10 +0200
        Re: Who reordered my disks (probably v4.8-rc1 problem) james harvey <jamespharvey20@gmail.com> - 2016-08-14 23:50 +0200
      Re: Who reordered my disks (probably v4.8-rc1 problem) Bob Tracy <rct@gherkin.frus.com> - 2016-08-14 15:40 +0200
    Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot.  [Re: Who reordered my disks (probably v4.8-rc1 problem)] Pavel Machek <pavel@ucw.cz> - 2016-08-14 11:30 +0200
      Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking  boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)] Tom Yan <tom.ty89@gmail.com> - 2016-08-14 11:40 +0200
        Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking  boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)] Tom Yan <tom.ty89@gmail.com> - 2016-08-14 12:10 +0200
          Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking  boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)] Tom Yan <tom.ty89@gmail.com> - 2016-08-14 12:20 +0200
            Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking  boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)] David Lang <david@lang.hm> - 2016-08-14 12:40 +0200
              Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking  boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)] Tom Yan <tom.ty89@gmail.com> - 2016-08-14 13:00 +0200
                Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking  boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)] Oliver Neukum <oneukum@suse.com> - 2016-08-14 16:20 +0200
              Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking  boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)] Greg KH <gregkh@linuxfoundation.org> - 2016-08-14 14:00 +0200
                Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking  boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)] Pavel Machek <pavel@ucw.cz> - 2016-08-14 14:10 +0200
                  Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking  boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)] Greg KH <gregkh@linuxfoundation.org> - 2016-08-14 16:20 +0200
                  Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking  boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)] Alan Stern <stern@rowland.harvard.edu> - 2016-08-14 17:00 +0200
                    Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking  boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)] Pavel Machek <pavel@ucw.cz> - 2016-08-14 18:20 +0200
            Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking  boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)] Pavel Machek <pavel@ucw.cz> - 2016-08-14 13:20 +0200
              Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking  boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)] Tom Yan <tom.ty89@gmail.com> - 2016-08-14 13:50 +0200
        Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking  boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)] Pavel Machek <pavel@ucw.cz> - 2016-08-14 12:10 +0200
        Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking  boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)] One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-14 18:10 +0200
      Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking  boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)] Pavel Machek <pavel@ucw.cz> - 2016-08-14 12:20 +0200
        Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking  boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)] Pavel Machek <pavel@ucw.cz> - 2016-08-14 18:10 +0200
          Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking  boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)] Pavel Machek <pavel@ucw.cz> - 2016-08-14 20:00 +0200
            Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking  boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)] Hans de Goede <hdegoede@redhat.com> - 2016-08-14 20:30 +0200
    Re: Who reordered my disks (probably v4.8-rc1 problem) "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-08-15 17:10 +0200

Page 1 of 2  [1] 2  Next page →

#1461701 — Who reordered my disks (probably v4.8-rc1 problem)

Hi!

It seems that in v4.8-rc0, /dev/sdX got reordered, and now USB devices
are probed before SATA drivers. That is pretty anti-social. It
broke my boot on my primary machine, and unfortunately due to BIOS
problems (keyboard does not work when connected through a hub) it is
less fun than it should be.

Best regards,

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [next] | [standalone]

#1461733

Use static (persistent) naming instead, /dev/disk/by-label,
/dev/disk/by-id, /dev/disk/by-uuid, and if gpt /dev/disk/by-partlabel
and /dev/disk/by-partuuid

As you found, /dev/sdX bus names are assigned in the order they are
added, which for some time has not been guaranteed to remain
consistent between kernel versions or even subsequent boots on the
same kernel.

On Sat, Aug 13, 2016 at 3:30 PM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
> It seems that in v4.8-rc0, /dev/sdX got reordered, and now USB devices
> are probed before SATA drivers. That is pretty anti-social. It
> broke my boot on my primary machine, and unfortunately due to BIOS
> problems (keyboard does not work when connected through a hub) it is
> less fun than it should be.
>
> Best regards,
>
>                                                                         Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1461740

Hi!

> Use static (persistent) naming instead, /dev/disk/by-label,
> /dev/disk/by-id, /dev/disk/by-uuid, and if gpt /dev/disk/by-partlabel
> and /dev/disk/by-partuuid

Explain that to my bootloader. Kernel needs root= on a command line.

> As you found, /dev/sdX bus names are assigned in the order they are
> added, which for some time has not been guaranteed to remain
> consistent between kernel versions or even subsequent boots on the
> same kernel.

Well, for usb, order is not guaranteed, for SATA, it worked. So that's
a regression in v4.8-rc1.

Yes, /dev/disk/by-* is good idea, but this broke my boot, probably
broke some scripts that used for a long time... and kernel may not
break working systems.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1462493

On Sun, Aug 14, 2016 at 5:09 AM, Pavel Machek <pavel@ucw.cz> wrote:
>> Use static (persistent) naming instead, /dev/disk/by-label,
>> /dev/disk/by-id, /dev/disk/by-uuid, and if gpt /dev/disk/by-partlabel
>> and /dev/disk/by-partuuid
>
> Explain that to my bootloader. Kernel needs root= on a command line.

It does need a root parameter.  Use root=PARTUUID=<partition UUID>.
Note the UUID is the PARTUUID from "blkid" which is for the partition,
not the UUID field which is for the filesystem.


>> As you found, /dev/sdX bus names are assigned in the order they are
>> added, which for some time has not been guaranteed to remain
>> consistent between kernel versions or even subsequent boots on the
>> same kernel.
>
> Well, for usb, order is not guaranteed, for SATA, it worked. So that's
> a regression in v4.8-rc1.
>
> Yes, /dev/disk/by-* is good idea, but this broke my boot, probably
> broke some scripts that used for a long time... and kernel may not
> break working systems.

It's always possible others may disagree, but I don't think something
is a regression when what breaks has long been said to not be expected
to work.

[toc] | [prev] | [next] | [standalone]

#1462125

On Sun, Aug 14, 2016 at 05:03:33AM -0400, james harvey wrote:
> Use static (persistent) naming instead, /dev/disk/by-label,
> /dev/disk/by-id, /dev/disk/by-uuid, and if gpt /dev/disk/by-partlabel
> and /dev/disk/by-partuuid

The key takeaway from the above is, for the non-GPT case, userspace
support (blkid and friends) is required to take advantage of static
(persistent) naming, i.e., an initial ramdisk of some kind is no
longer optional (boo! hiss!).

There's an implied requirement for udev as well, but that's not nearly
as distasteful.  I had to make my peace with udev on an otherwise
primitive (simple) Slackware system a few years ago when I upgraded my
system hardware: included was a sound device with an HDMI interface,
and the associated ALSA driver only supported dynamic minor devices.

--Bob

[toc] | [prev] | [next] | [standalone]

#1461749 — Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

Hi!

> It seems that in v4.8-rc0, /dev/sdX got reordered, and now USB devices
> are probed before SATA drivers. That is pretty anti-social. It
> broke my boot on my primary machine, and unfortunately due to BIOS
> problems (keyboard does not work when connected through a hub) it is
> less fun than it should be.

If you know which commit caused	the reordering, that would be helpful.

v4.1 seems to be ok: SATA disk is sda, as expected.

v4.4 seems to be ok: SATA disk is sda, as expected.

I'll test v4.6 next.

v4.8-rc1: SATA disk is sde, behind USB card readers. Not helpful.

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1461753 — Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

Since when it is expected that SATA disks will always be probed before
USB disks? We can't guarantee that even if we make sure all ata
drivers are loaded before usb-storage/uas. That's why we need
consistent namings (e.g. /dev/disk/by-id/*).

On 14 August 2016 at 17:20, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
>> It seems that in v4.8-rc0, /dev/sdX got reordered, and now USB devices
>> are probed before SATA drivers. That is pretty anti-social. It
>> broke my boot on my primary machine, and unfortunately due to BIOS
>> problems (keyboard does not work when connected through a hub) it is
>> less fun than it should be.
>
> If you know which commit caused the reordering, that would be helpful.
>
> v4.1 seems to be ok: SATA disk is sda, as expected.
>
> v4.4 seems to be ok: SATA disk is sda, as expected.
>
> I'll test v4.6 next.
>
> v4.8-rc1: SATA disk is sde, behind USB card readers. Not helpful.
>
> Best regards,
>                                                                         Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[toc] | [prev] | [next] | [standalone]

#1461761 — Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

On 14 August 2016 at 18:01, Pavel Machek <pavel@ucw.cz> wrote:
>
> Since SATA support was merged, certainly since v2.4, and from way
> before /dev/disk/by-id existed.

I have no idea how "SATA before USB" had been done in the past (if it
was ever a thing in the kernel), but that has not been the case since
at least v3.0 AFAIR.

>
> People may not run udev, and you can't use /dev/disk/by-id on kernel
> command line.
>

No, but you can always use root=PARTUUID=, that's built into the
kernel. (root=UUID= requires udev or so though).

[toc] | [prev] | [next] | [standalone]

#1461768 — Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

On 14 August 2016 at 18:07, Tom Yan <tom.ty89@gmail.com> wrote:
> On 14 August 2016 at 18:01, Pavel Machek <pavel@ucw.cz> wrote:
>>
>> Since SATA support was merged, certainly since v2.4, and from way
>> before /dev/disk/by-id existed.
>
> I have no idea how "SATA before USB" had been done in the past (if it
> was ever a thing in the kernel), but that has not been the case since
> at least v3.0 AFAIR.
>
>>
>> People may not run udev, and you can't use /dev/disk/by-id on kernel
>> command line.
>>
>
> No, but you can always use root=PARTUUID=, that's built into the
> kernel. (root=UUID= requires udev or so though).

Silly me. root=UUID= has nothing to do with udev, but `blkid` in
util-linux. At least that's how it's done in Arch/mkinitcpio.

[toc] | [prev] | [next] | [standalone]

#1461787 — Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

On Sun, 14 Aug 2016, Tom Yan wrote:

> On 14 August 2016 at 18:07, Tom Yan <tom.ty89@gmail.com> wrote:
>> On 14 August 2016 at 18:01, Pavel Machek <pavel@ucw.cz> wrote:
>>>
>>> Since SATA support was merged, certainly since v2.4, and from way
>>> before /dev/disk/by-id existed.
>>
>> I have no idea how "SATA before USB" had been done in the past (if it
>> was ever a thing in the kernel), but that has not been the case since
>> at least v3.0 AFAIR.
>>
>>>
>>> People may not run udev, and you can't use /dev/disk/by-id on kernel
>>> command line.
>>>
>>
>> No, but you can always use root=PARTUUID=, that's built into the
>> kernel. (root=UUID= requires udev or so though).
>
> Silly me. root=UUID= has nothing to do with udev, but `blkid` in
> util-linux. At least that's how it's done in Arch/mkinitcpio.
>

The rule is "don't break working systems", not "but we are allowed to break 
systems, see it says here not to depend on this"

Drive ordering has been stable since the 0.1 kernel [1]

It takes a lot longer to detect USB drives, why in the world would they be 
detected before hard-wired drives?

I expect that Linus' response is going to be very quotable.

David Lang


[1] given stable hardware and no new drivers becoming involved

[toc] | [prev] | [next] | [standalone]

#1461793 — Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

Btw, why hasn't this been CC'd to linux-scsi at the very least? The
SCSI disk (sd) driver is obviously the sociopath here. It should
really differentiate disks from libata and usb-storage/uas, and wait
for at least a minute to see if there's gonna be an ATA drive popping
up before enumerating disks from the latter. Sociopaths like me that
put the root filesystem on an UAS drive should really be ignored.
Wait, there's NVMe! Problem solved.

On 14 August 2016 at 10:26, David Lang <david@lang.hm> wrote:
> On Sun, 14 Aug 2016, Tom Yan wrote:
>
>> On 14 August 2016 at 18:07, Tom Yan <tom.ty89@gmail.com> wrote:
>>>
>>> On 14 August 2016 at 18:01, Pavel Machek <pavel@ucw.cz> wrote:
>>>>
>>>>
>>>> Since SATA support was merged, certainly since v2.4, and from way
>>>> before /dev/disk/by-id existed.
>>>
>>>
>>> I have no idea how "SATA before USB" had been done in the past (if it
>>> was ever a thing in the kernel), but that has not been the case since
>>> at least v3.0 AFAIR.
>>>
>>>>
>>>> People may not run udev, and you can't use /dev/disk/by-id on kernel
>>>> command line.
>>>>
>>>
>>> No, but you can always use root=PARTUUID=, that's built into the
>>> kernel. (root=UUID= requires udev or so though).
>>
>>
>> Silly me. root=UUID= has nothing to do with udev, but `blkid` in
>> util-linux. At least that's how it's done in Arch/mkinitcpio.
>>
>
> The rule is "don't break working systems", not "but we are allowed to break
> systems, see it says here not to depend on this"
>
> Drive ordering has been stable since the 0.1 kernel [1]
>
> It takes a lot longer to detect USB drives, why in the world would they be
> detected before hard-wired drives?
>
> I expect that Linus' response is going to be very quotable.
>
> David Lang
>
>
> [1] given stable hardware and no new drivers becoming involved

[toc] | [prev] | [next] | [standalone]

#1462131 — Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

On Sun, 2016-08-14 at 10:53 +0000, Tom Yan wrote:
> Btw, why hasn't this been CC'd to linux-scsi at the very least? The
> SCSI disk (sd) driver is obviously the sociopath here. It should
> really differentiate disks from libata and usb-storage/uas, and wait
> for at least a minute to see if there's gonna be an ATA drive popping
> up before enumerating disks from the latter. Sociopaths like me that
> put the root filesystem on an UAS drive should really be ignored.
> Wait, there's NVMe! Problem solved.

We most certainly cannot introduce such a delay. If this really
must be done, we need synchronisation primitives between the
subsystemes, or we need stable names in kernel space.

	Regards
		Oliver

[toc] | [prev] | [next] | [standalone]

#1462067 — Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

On Sun, Aug 14, 2016 at 03:26:45AM -0700, David Lang wrote:
> On Sun, 14 Aug 2016, Tom Yan wrote:
> 
> > On 14 August 2016 at 18:07, Tom Yan <tom.ty89@gmail.com> wrote:
> > > On 14 August 2016 at 18:01, Pavel Machek <pavel@ucw.cz> wrote:
> > > > 
> > > > Since SATA support was merged, certainly since v2.4, and from way
> > > > before /dev/disk/by-id existed.
> > > 
> > > I have no idea how "SATA before USB" had been done in the past (if it
> > > was ever a thing in the kernel), but that has not been the case since
> > > at least v3.0 AFAIR.
> > > 
> > > > 
> > > > People may not run udev, and you can't use /dev/disk/by-id on kernel
> > > > command line.
> > > > 
> > > 
> > > No, but you can always use root=PARTUUID=, that's built into the
> > > kernel. (root=UUID= requires udev or so though).
> > 
> > Silly me. root=UUID= has nothing to do with udev, but `blkid` in
> > util-linux. At least that's how it's done in Arch/mkinitcpio.
> > 
> 
> The rule is "don't break working systems", not "but we are allowed to break
> systems, see it says here not to depend on this"
> 
> Drive ordering has been stable since the 0.1 kernel [1]

Drive probing order of USB has always been non-deterministic, so while I
agree that it is not good to break existing systems at all, perhaps this
is on the edge of what works vs. doesn't work?

I know my USB drives always seem to come up in random order, which is
why tools like udev were invented :)

> It takes a lot longer to detect USB drives, why in the world would they be
> detected before hard-wired drives?

Depends, some hard-wired drives take much longer to find than USB ones.

That being said, it would be great if the original reporter could use
'git bisect' and let the linux-usb and linux-scsi mailing list know what
the offending patch is, and we can take it from there.

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1462089 — Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

Hi!

> > > > I have no idea how "SATA before USB" had been done in the past (if it
> > > > was ever a thing in the kernel), but that has not been the case since
> > > > at least v3.0 AFAIR.
> > > > 
> > > > > 
> > > > > People may not run udev, and you can't use /dev/disk/by-id on kernel
> > > > > command line.
> > > > > 
> > > > 
> > > > No, but you can always use root=PARTUUID=, that's built into the
> > > > kernel. (root=UUID= requires udev or so though).
> > > 
> > > Silly me. root=UUID= has nothing to do with udev, but `blkid` in
> > > util-linux. At least that's how it's done in Arch/mkinitcpio.
> > 
> > The rule is "don't break working systems", not "but we are allowed to break
> > systems, see it says here not to depend on this"
> > 
> > Drive ordering has been stable since the 0.1 kernel [1]
> 
> Drive probing order of USB has always been non-deterministic, so while I
> agree that it is not good to break existing systems at all, perhaps this
> is on the edge of what works vs. doesn't work?

Yeah, USB order is known to be random. But root=/dev/sda (when sda is
on SATA) is very old, and it would be good to keep it.

> I know my USB drives always seem to come up in random order, which is
> why tools like udev were invented :)
> 
> > It takes a lot longer to detect USB drives, why in the world would they be
> > detected before hard-wired drives?
> 
> Depends, some hard-wired drives take much longer to find than USB ones.
> 
> That being said, it would be great if the original reporter could use
> 'git bisect' and let the linux-usb and linux-scsi mailing list know what
> the offending patch is, and we can take it from there.

Original reporter is me :-(.

Yes, I can do bisect, if required. I'd like some kind of confirmation
that it happens on other systems...

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1462133 — Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

On Sun, Aug 14, 2016 at 02:03:27PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > > > I have no idea how "SATA before USB" had been done in the past (if it
> > > > > was ever a thing in the kernel), but that has not been the case since
> > > > > at least v3.0 AFAIR.
> > > > > 
> > > > > > 
> > > > > > People may not run udev, and you can't use /dev/disk/by-id on kernel
> > > > > > command line.
> > > > > > 
> > > > > 
> > > > > No, but you can always use root=PARTUUID=, that's built into the
> > > > > kernel. (root=UUID= requires udev or so though).
> > > > 
> > > > Silly me. root=UUID= has nothing to do with udev, but `blkid` in
> > > > util-linux. At least that's how it's done in Arch/mkinitcpio.
> > > 
> > > The rule is "don't break working systems", not "but we are allowed to break
> > > systems, see it says here not to depend on this"
> > > 
> > > Drive ordering has been stable since the 0.1 kernel [1]
> > 
> > Drive probing order of USB has always been non-deterministic, so while I
> > agree that it is not good to break existing systems at all, perhaps this
> > is on the edge of what works vs. doesn't work?
> 
> Yeah, USB order is known to be random. But root=/dev/sda (when sda is
> on SATA) is very old, and it would be good to keep it.
> 
> > I know my USB drives always seem to come up in random order, which is
> > why tools like udev were invented :)
> > 
> > > It takes a lot longer to detect USB drives, why in the world would they be
> > > detected before hard-wired drives?
> > 
> > Depends, some hard-wired drives take much longer to find than USB ones.
> > 
> > That being said, it would be great if the original reporter could use
> > 'git bisect' and let the linux-usb and linux-scsi mailing list know what
> > the offending patch is, and we can take it from there.
> 
> Original reporter is me :-(.
> 
> Yes, I can do bisect, if required. I'd like some kind of confirmation
> that it happens on other systems...

Please use git-bisect, you are the first one reporting this.

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1462143 — Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

On Sun, 14 Aug 2016, Pavel Machek wrote:

> > That being said, it would be great if the original reporter could use
> > 'git bisect' and let the linux-usb and linux-scsi mailing list know what
> > the offending patch is, and we can take it from there.
> 
> Original reporter is me :-(.
> 
> Yes, I can do bisect, if required. I'd like some kind of confirmation
> that it happens on other systems...

Can you post a kernel log from one of those unsuccessful boots
(netconsole or something or the sort)?

Alan Stern

[toc] | [prev] | [next] | [standalone]

#1462167 — Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

On Sun 2016-08-14 10:56:54, Alan Stern wrote:
> On Sun, 14 Aug 2016, Pavel Machek wrote:
> 
> > > That being said, it would be great if the original reporter could use
> > > 'git bisect' and let the linux-usb and linux-scsi mailing list know what
> > > the offending patch is, and we can take it from there.
> > 
> > Original reporter is me :-(.
> > 
> > Yes, I can do bisect, if required. I'd like some kind of confirmation
> > that it happens on other systems...
> 
> Can you post a kernel log from one of those unsuccessful boots
> (netconsole or something or the sort)?

Even scrollback does not seem to work well on modern kernels. So
sorry, no easy way to get a kernel log :-(.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1461898 — Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

Hi!

On Sun 2016-08-14 18:17:39, Tom Yan wrote:
> On 14 August 2016 at 18:07, Tom Yan <tom.ty89@gmail.com> wrote:
> > On 14 August 2016 at 18:01, Pavel Machek <pavel@ucw.cz> wrote:
> >>
> >> Since SATA support was merged, certainly since v2.4, and from way
> >> before /dev/disk/by-id existed.
> >
> > I have no idea how "SATA before USB" had been done in the past (if it
> > was ever a thing in the kernel), but that has not been the case since
> > at least v3.0 AFAIR.

It is the case in v4.6. We had change hda->sda for SATA drives long
time ago, it was stable since that.

> > No, but you can always use root=PARTUUID=, that's built into the
> > kernel. (root=UUID= requires udev or so though).
> 
> Silly me. root=UUID= has nothing to do with udev, but `blkid` in
> util-linux. At least that's how it's done in Arch/mkinitcpio.

I'd rather not mess with initrd, and initrd was not required in the
past.

kernel-parameters.txt only mentions UUID= in connection with
resume. Is the documentation correct?
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1462032 — Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

On 14 August 2016 at 11:10, Pavel Machek <pavel@ucw.cz> wrote:
>
> It is the case in v4.6. We had change hda->sda for SATA drives long
> time ago, it was stable since that.

Not for me. It has been like forever (even if it wasn't the fact) that
the disk order is not consistent among boots. Only that would
logically make sense anyway. How do you think we can sanely make sure
that the SCSI disk driver starts enumerating "SCSI disks" from
usb-storage/uas only when all of those from libata probed? Wait for 1
second? 1 minute? or 1 hour? It's an irrational thing to do no matter
how long or how short it is.

>
> I'd rather not mess with initrd, and initrd was not required in the
> past.

Well, that's your choice, use PARTUUID then.

>
> kernel-parameters.txt only mentions UUID= in connection with
> resume. Is the documentation correct?

That's `PARTUUID=`. See what PARTUUID is referring to in the linked
comment below. (Note that when we say UUID instead of PARTUUID, we are
usually referring to the filesystem UUID.)

...

resume= [SWSUSP]
Specify the partition device for software suspend
Format:
{/dev/<dev> | PARTUUID=<uuid> | <int>:<int> | <hex>}

...

root= [KNL] Root filesystem
See name_to_dev_t comment in init/do_mounts.c.

...

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/init/do_mounts.c?h=v4.8-rc1#n182

[toc] | [prev] | [next] | [standalone]

#1461764 — Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

On Sun 2016-08-14 17:34:18, Tom Yan wrote:
> Since when it is expected that SATA disks will always be probed before
> USB disks? We can't guarantee that even if we make sure all ata
> drivers are loaded before usb-storage/uas. That's why we need
> consistent namings (e.g. /dev/disk/by-id/*).

Since SATA support was merged, certainly since v2.4, and from way
before /dev/disk/by-id existed.

People may not run udev, and you can't use /dev/disk/by-id on kernel
command line.

								Pavel

> On 14 August 2016 at 17:20, Pavel Machek <pavel@ucw.cz> wrote:
> > Hi!
> >
> >> It seems that in v4.8-rc0, /dev/sdX got reordered, and now USB devices
> >> are probed before SATA drivers. That is pretty anti-social. It
> >> broke my boot on my primary machine, and unfortunately due to BIOS
> >> problems (keyboard does not work when connected through a hub) it is
> >> less fun than it should be.
> >
> > If you know which commit caused the reordering, that would be helpful.
> >
> > v4.1 seems to be ok: SATA disk is sda, as expected.
> >
> > v4.4 seems to be ok: SATA disk is sda, as expected.
> >
> > I'll test v4.6 next.
> >
> > v4.8-rc1: SATA disk is sde, behind USB card readers. Not helpful.
> >
> > Best regards,
> >                                                                         Pavel
> > --
> > (english) http://www.livejournal.com/~pavelmachek
> > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web