All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: David Lang <david@lang.hm>, Tom Yan <tom.ty89@gmail.com>,
	kernel list <linux-kernel@vger.kernel.org>,
	james harvey <jamespharvey20@gmail.com>,
	regressions@leemhuis.info, hdegoede@redhat.com,
	Tejun Heo <tj@kernel.org>,
	linux-ide@vger.kernel.org, linux-usb@vger.kernel.org,
	Oliver Neukum <oliver@neukum.org>,
	Alan Stern <stern@rowland.harvard.edu>
Subject: Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]
Date: Sun, 14 Aug 2016 14:03:27 +0200	[thread overview]
Message-ID: <20160814120327.GA8292@amd> (raw)
In-Reply-To: <20160814112958.GA20778@kroah.com>

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

  reply	other threads:[~2016-08-14 12:03 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-13 19:30 Who reordered my disks (probably v4.8-rc1 problem) Pavel Machek
2016-08-14  9:03 ` james harvey
2016-08-14  9:09   ` Pavel Machek
2016-08-14 21:40     ` james harvey
2016-08-14 12:38   ` Bob Tracy
2016-08-14  9:20 ` Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)] Pavel Machek
2016-08-14  9:34   ` Tom Yan
2016-08-14 10:01     ` Pavel Machek
2016-08-14 10:07       ` Tom Yan
2016-08-14 10:17         ` Tom Yan
2016-08-14 10:26           ` David Lang
2016-08-14 10:53             ` Tom Yan
2016-08-14 14:14               ` Oliver Neukum
     [not found]             ` <alpine.DEB.2.02.1608140322400.9045-UEhY+ZBZOcqqLGM74eQ/YA@public.gmane.org>
2016-08-14 11:29               ` Greg KH
2016-08-14 11:29                 ` Greg KH
2016-08-14 12:03                 ` Pavel Machek [this message]
2016-08-14 14:15                   ` Greg KH
2016-08-14 14:56                   ` Alan Stern
2016-08-14 14:56                     ` Alan Stern
2016-08-14 16:13                     ` Pavel Machek
2016-08-14 11:10           ` Pavel Machek
2016-08-14 11:41             ` Tom Yan
2016-08-14 16:09     ` One Thousand Gnomes
2016-08-14 10:14   ` Pavel Machek
2016-08-14 16:06     ` Pavel Machek
2016-08-14 17:55       ` Pavel Machek
2016-08-14 18:22         ` Hans de Goede
2016-08-15 15:05 ` Who reordered my disks (probably v4.8-rc1 problem) Austin S. Hemmelgarn

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=20160814120327.GA8292@amd \
    --to=pavel@ucw.cz \
    --cc=david@lang.hm \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=jamespharvey20@gmail.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=oliver@neukum.org \
    --cc=regressions@leemhuis.info \
    --cc=stern@rowland.harvard.edu \
    --cc=tj@kernel.org \
    --cc=tom.ty89@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.