From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 0CE391381F4 for ; Sun, 12 Aug 2012 19:31:07 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A6ABAE058A; Sun, 12 Aug 2012 19:30:51 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 144A6E0495 for ; Sun, 12 Aug 2012 19:29:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 79FCF1B4019 for ; Sun, 12 Aug 2012 19:29:55 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.486 X-Spam-Level: X-Spam-Status: No, score=-1.486 tagged_above=-999 required=5.5 tests=[AWL=-1.474, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMJXavafPFY5 for ; Sun, 12 Aug 2012 19:29:50 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id D1DA564204 for ; Sun, 12 Aug 2012 19:29:49 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1T0dr4-00076B-A4 for gentoo-dev@gentoo.org; Sun, 12 Aug 2012 21:29:42 +0200 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 12 Aug 2012 21:29:42 +0200 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 12 Aug 2012 21:29:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: Questions about SystemD and OpenRC Date: Sun, 12 Aug 2012 19:29:21 +0000 (UTC) Message-ID: References: <5026EAE7.4040600@gmail.com> <20120812001239.27781.qmail@stuge.se> <5027B2E6.6070908@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.139 (Sexual Chocolate; GIT 1f91845 /usr/src/portage/src/egit-src/pan2) X-Archives-Salt: f453a0fb-770b-4987-a75f-ec5c74afb210 X-Archives-Hash: d7e6c9e9c0d8312f98cba0ecdc12cea7 Chí-Thanh Christopher Nguyễn posted on Sun, 12 Aug 2012 15:43:02 +0200 as excerpted: > Rich Freeman schrieb: >> So, I could see how many linux users might think that interpreting a >> complex root= parameter is a kernel function, when it is really just >> the fact that they use an initramfs. >> >> If somebody is running with root=LABEL=foo or something like that >> without an initramfs I'll happily stand corrected. > > If your disk is GPT partitioned, then you can use root=PARTUUID=... > without initramfs. > Note that PARTUUID is the partition UUID, not the filesystem UUID. Thanks. Note that the btrfs list discussion was in the context of gpt partlabels (and that I specifically said I don't know if the kernel takes all such assignments in root= or just that in the discussion), so it's quite possible only partlabels and partuuids are accepted, as these are found in the gpt partition table itself, which the kernel must know how to parse in general, so teaching it to parse and honor these probably wasn't /that/ much more work than teaching it to parse the table but ignore them. And the gpt handling code is new enough, it may have simply been added with/for it, without touching the legacy mbr code. Another variable may be bootloader. Grub2 has legacy linux16 loader support, as well as 32-bit "linux" support. Between that and the fact that it was designed to handle both BIOS and EFI systems, it's quite possible that the legacy 16-bit linux loader protocol doesn't support these features, while the 32-bit (and presumably 64-bit EFI) kernel loader protocol does. I've no idea what grub-legacy used, but it wouldn't surprise me if it was the legacy 16-bit loader protocol, and that feeding root=PARTID= won't work for it but will with the 32-bit loader grub2 defaults to. I really should try it one of these days and know from personal experience, but in this case, it really /is/ easier to just talk than to do, since trying it requires rebooting, so I can't simply try it in another window while I keep this post open, waiting on the result... -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman