login
Login
/
Register
Search
Search this site:
Forums
News
Blogs
Features
Site
Home
»
Mailing list archives
»
linux-kernel
»
2010
»
April
»
20
Re: boot device order troubleshooting without an initrd
view
thread
Previous message: [
thread
] [
date
] [
author
]
Next message: [thread] [
date
] [
author
]
[view in full thread]
From: Pavel Machek
Subject:
Re: boot device order troubleshooting without an initrd
Date: Monday, April 19, 2010 - 10:17 pm
On Mon 2010-04-19 22:20:23,
skitching@apache.org
wrote:
quoted text
> As it happens, I've been looking into this issue recently. > [Warning: kernel newbie speaking!] > > Without an initrd, the options for the root= kernel parameters are only those supported in init/do_mount.c: > 1. root=MAJOR:MINOR > 2. root=integer where integer is MAJOR<<n + minor > 3 root=/dev/xxx > (well, apart fron "mtd" and "ubi" options).
And nfs?
quoted text
> Unfortunately, all of these options are sensitive to hardware changes, ie device enumeration order. So I > think that right now the answer to your question is: no, you can't get what you want without an initrd. > > And I doubt that changes to the linux device-enumeration code "to be consistent with the BIOS" would be accepted. >
If it is clean enough... why not? -- (english)
http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
unsubscribe notice
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/
Previous message: [
thread
] [
date
] [
author
]
Next message: [thread] [
date
] [
author
]
Messages in current thread:
Re: boot device order troubleshooting without an initrd
, skitching
, (Mon Apr 19, 3:20 am)
Re: boot device order troubleshooting without an initrd
, Pavel Machek
, (Mon Apr 19, 10:17 pm)
Navigation
Create content
Mailing list archives
Recent posts
Popular discussions
linux-kernel
:
Stephen Smalley
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
FUJITA Tomonori
Re: [Scst-devel] Integration of SCST in the mainstream Linux kernel
Alex Riesen
Re: [PATCH 4/7] lib: Introduce strnstr()
Mathieu Desnoyers
Re: Linux 2.6.25-rc2
Borislav Petkov
drm_vm.c:drm_mmap: possible circular locking dependency detected (was: Re: Linux 2...
git
:
Mike Miller
git message
Wincent Colaiuta
Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
Johannes Schindelin
Re: [PATCH] Fix install-doc-quick target
Kevin Ballard
Re: git check-attr -z and quoting
Marcel Holtmann
Re: Remove unneeded packs
linux-netdev
:
Arnaldo Carvalho de Melo
Re: [PATCH 06/37] dccp: Limit feature negotiation to connection setup phase
Sebastian Andrzej Siewior
[PATCH v2] net/core: use ntohs for skb->protocol
Badalian Vyacheslav
Re: tc filter flow hash question
Parav Pandit
ip6 route output() and ip_route_output_key() by drivers
Jarek Poplawski
Re: tc filter flow hash question
git-commits-head
:
Linux Kernel Mailing List
mm: fix build on non-mmu machines
Linux Kernel Mailing List
ALSA: hda: Use olpc-xo-1_5 quirk for Toshiba Satellite P500-PSPGSC-01800T
Linux Kernel Mailing List
i915: Don't whine when pci_enable_msi() fails.
Linux Kernel Mailing List
powerpc/kexec: Add support for FSL-BookE
Linux Kernel Mailing List
Staging: rt2870: Removal of kernel_thread() API
openbsd-misc
:
Tony Abernethy
Re: The Atheros story in much fewer words
"RALOVICH, Kristóf"
Re: thinkpad windows refund
Kevin
Re: uvm_mapent_alloc: out of static map entries on 4.3 i386
ropers
Re: Real men don't attack straw men
Nick Holland
Re: Install OpenBSD from USB ?
Colocation donated by:
Syndicate