From: "João Miguel" <jmcf125@openmailbox.org>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Root device as UUID not properly detected
Date: Wed, 7 Oct 2015 22:00:01 +0100 [thread overview]
Message-ID: <20151007210001.GA4785@jmcf125-Acer-Arch.home> (raw)
In-Reply-To: <4419537.08q3Ys9htG@andromeda>
On Wed, Oct 07, 2015 at 12:17:51PM +0200, J. Roeleveld wrote:
> > > > > 2. USB port is not supported by kernel
> > > > I'm not sure what you mean. Is there any option I should enable for
> > > > genkernel? I read on the Wiki page that
> > > It works with Arch, are you using the same kernel options now with Gentoo?
> > Yeah, I tried many more here actually, with Arch I only need APPEND root=...
> > (no rootfstype, ro, rw, rootdelay, etc.).
> What about kernel config?
I was not sure about this, but
https://wiki.archlinux.org/index.php/Kernel_parameters says:
There are three ways to pass options to the kernel and thus control its
behaviour:
1. When building the kernel. See Kernel Compilation for details.
2. When starting the kernel (usually, when invoked from a boot loader).
3. At runtime (through the files in /proc and /sys). See sysctl for details.
So I'm using 2.
> > > > > 3. You don't use root_delay as boot option
> > > > If that's what I think it is, I tell syslinux to wait 5 seconds.
> > (turns out it's not what I thought it was, though I did try root_delay, it
> > is actually rootdelay...)
> > > How do you tell it that?
> > Here's my syslinux.cfg with more comments:
> > PROMPT 1
> > TIMEOUT 50 # <-- here
> That timeout is for the prompt, eg. how long the bootloader waits.
Yes, but I do tell it to wait (and as I said, I didn't know what rootdelay
was).
> It will not have any effect for the drivers in the kernel to finish detecting
> the USB devices.
> > APPEND rootdelay=5 root=UUID="6fc386ff-8342-42a2-be02-51a6eccf8430" rootfstype=ext4
No, but this ------^^^^^^^^^^^-- should.
> Did you test with the PARTUUID value ("9c...") instead of the other one?
>
> Also, I always ended up setting the rootdelay to 10 or higher. (It's in
> seconds, not minutes)
New append line:
APPEND rootdelay=15 root=PARTUUID="9c4f6479-9dd7-4a8f-86f2-f1320cc15aa5" rootfstype=ext4
Again, I see no difference using rootdelay. With PARTUUID though, I get "Could
not find the root device in ." right away, rather than "Could not find the root
device in UUID=...". With PARTUUID, I can't boot it anywhere without manually
writing the UUID (not PARTUUID) or device file. Though on my system, the
following works:
# mount PARTUUID="9c4f6479-9dd7-4a8f-86f2-f1320cc15aa5" /mnt/pen
So now I'm even more confused. Everything about this pen works, as does
everything in the PCs I tried. Syslinux also works. It's somewhere after
loading the modules, in the initrd.
Thinking of it now, I remember the PC that never finds the root device
requires intel microcode early, which is loaded along with the initrd.
Because of this problem I need to turn many PCs on and off a few times
in a row, and I noticed that the pendrive blinks at least on BIOS, when
syslinux is finding initrd and the kernel, and when the machine finds
the root device. Now, what I noticed is that in the VM, it blinks right
away (as it finds root right away); in many PCs it takes a while to
blink, only blinking after the 1st attempt on mounting to newroot has
been done; and in some others it never blinks.
> > > I never used an initrd when building my own USB sticks.
> > I don't know, I always used an initrd. Though I must say, that is the
> > phase of starting the PC I understand the worst.
> On the machines where I use an initrd, I write my own scripts as I find the
> creators (genkernel, dracut) to not be intelligent enough.
The thing is, I'm less intelligent than those creators. I'm not very
familiar with the way that early boot phase works, much less with
writing scripts to make it work. Unless you have an idea of how I can
use the scripts to solve this problem. In Arch I use mkinitcpio. I'm
aware it is available for Gentoo as well, nonetheless using genkernel is
killing two birds with one stone, it should be a simpler solution, so
I'd like to go with that one. If it works for a Gentoo recovery drive,
why shouldn't it work for this one?
> > > I was talking about:
> > > rootdelay= [KNL] Delay (in seconds) to pause before
> > > attempting to
> > > mount the root filesystem
> > > (See the file "kernel-parameters.txt" in the kernel Documentation)
> > (I'm guessing I'm not supposed to include this in the boot loader config...)
> The "rootdelay=..." part needs to be added to the boot loader config.
Ah, then I'm glad I did. Although it seems to do nothing really...
Sorry for the large response. I probably forgot something, took a while
amidst writing and testing.
João Miguel
next prev parent reply other threads:[~2015-10-07 21:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-06 15:59 [gentoo-user] Root device as UUID not properly detected João Miguel
2015-10-06 16:17 ` Philip Webb
2015-10-06 16:55 ` João Miguel
2015-10-06 17:06 ` J. Roeleveld
2015-10-06 18:19 ` João Miguel
2015-10-06 21:15 ` J. Roeleveld
2015-10-06 22:03 ` João Miguel
2015-10-07 10:17 ` J. Roeleveld
2015-10-07 21:00 ` João Miguel [this message]
2015-10-08 21:23 ` João Miguel
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=20151007210001.GA4785@jmcf125-Acer-Arch.home \
--to=jmcf125@openmailbox.org \
--cc=gentoo-user@lists.gentoo.org \
/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