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 A733E1381F3 for ; Fri, 28 Jun 2013 00:15:21 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 20566E09AA; Fri, 28 Jun 2013 00:15:20 +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 pigeon.gentoo.org (Postfix) with ESMTPS id 2B40EE0973 for ; Fri, 28 Jun 2013 00:15:19 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UsMLM-0003ys-Tg for gentoo-amd64@lists.gentoo.org; Fri, 28 Jun 2013 02:15:16 +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 ; Fri, 28 Jun 2013 02:15:16 +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 ; Fri, 28 Jun 2013 02:15:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: Can initrd and/or RAID be disabled at boot? Date: Fri, 28 Jun 2013 00:14:59 +0000 (UTC) Message-ID: References: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@lists.gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT 368aae4 /usr/src/portage/src/egit-src/pan2) X-Archives-Salt: 38bd3409-0b0c-4bcc-a467-bcd8db388eca X-Archives-Hash: c0d81a8996a779df94ce0852d66fb716 Mark Knecht posted on Thu, 27 Jun 2013 13:52:18 -0700 as excerpted: > Looking at caps, xattr & filecaps I don't appear to have them selected > on any packages. (equery hasuse ..., emerge -pv ...) > > Similar results as yours for the zgrep: > With that in mind I may well have needed the -X on the rsync. Since you don't have any packages with caps/xattr/filecaps set in USE, you're probably fine in that regard -- you were correct that you didn't need it. However, as I said, the -X won't hurt. > However as > I didn't get a quick response I decided this was a background issue for > me in a sense. Makes sense. > However, I think your comments about gpt & grub2 are VERY good points > and might work out in my favor long term. I only used 2 partitions on > the SDD - one for a new boot partition and one for /, my thought being > that if I installed grub on the SDD then in BIOS I could point at > /dev/sda to boot off the SDD instead of /dev/sdb. As I think about your > comments, I could consider backing up the SDD install using rsync -aAvx, > converting to gpt & grub2 on that device, do my learning and it doesn't > have to impact my current setup at all. That can all stay on the hard > drives until I'm ready to get rid of it. It's just a flip of a switch in > BIOS as to which one I'm using. That's a good idea. Two other comments/suggestions regarding grub1 -> grub2 conversion. 1) I found it *EXTREMELY* useful when I was learning grub2, to have two bootable devices setup, with just a BIOS selector switch to switch between them, keeping my normal boot setup grub1 until I was pretty much done experimenting with grub2 on the other one and had it setup the way I wanted. After I could boot to grub2 and from it to my normal Linux setup, then and only then did I blow away the grub1 setup that I had been using for backup while I experimented with grub2. Of course now I have all three of my current bootable devices (the pair of SSDs and the spinning rust as backup) configured with separate grub2 instances, so I can boot to grub2 from any of the three, and from the grub2, load the kernel and boot to any of my five root filesystems (the primary and backup btrfs raid1 mode roots on the pair of ssds, and any of the three roots, primary and first and second backup of the rootfs on the spinning rust, which I've yet to repartition now that I have the ssds up and running, tho I intend to at some point, but there's no hurry). That's FAR less nerve-racking than trying to be sure that you got it correct enough to at least boot far enough to correct any remaining issues, on the single working bootable device available, that can be either grub1 or grub2, but can't have both installed and working at the same time! Of course for those without a second installed primary boot device, it's possible to do the same thing with a USB stick, which is what I probably would have done if I didn't have the extra installed boot devices around to try. But either way, leave the existing grub1 alone while you experiment with grub2 on a different device, only blowing away grub1 once you have grub2 configured and booting to your satisfaction. 2) There's two methods available for configuring grub2, the automated/ scripted method, and the direct grub.cfg edit method. Certainly YMMV, but here, the automated/scripted method just didn't cut it. I did use it for the initial automated conversion from grub1 and the initial bare- bones grub2 functionality test, to see that it was working at all, but after that, I quickly switched to the far more powerful direct edit method, as all I was getting from the automated/scripted method was frustrated. Of course most of the documentation and howtos out there are based on the scripted method. There's certainly info available for the direct edit method, including the grub info pages installed with the package itself and the manual on the grub web site if you prefer that to trying to navigate info pages, but as they're designed more for experts and distro maintainers than ordinary users (who are expected to use the scripted interface), the documentation does tend to be a bit vague at various points. Which is why I ended up doing a lot of experimentation, because I knew that there was a command to do basically what I wanted, but finding either nice examples or command specifics wasn't always easy, so I had to look stuff up, then reboot to grub to try it, then boot thru grub to the main system to be able to either look more stuff up or write out to permanent config the bit I'd just figured out in grub by trying it. So I don't claim that my grub2 config is the be all and end all of grub configs, but if/when it comes time for someone to upgrade, just ask, and I can post it, to give people some nice real-world working grub config code examples to follow, the same ones I had such a hard time finding and that I often had to simply try it out until I figured out the bits that the info pages didn't really describe in what I'd call a useful way. Similarly, if you have grub2 config command questions, post them, as it's reasonably likely I've asked myself the same sorts of questions, and ultimately gave up googling for the answer and just tried it until I got it working. Finally, my initial "final" grub2 config was powerful, but brittle and inflexible in some aspects. What I ended up with on the second go round (well, we'll call it config version 2.1 now, as I just today modified it just a bit further after my initr* experiments, which revealed a weakness with version 2.0) is far more flexible, with far less brainlessly duplicated menu option boilerplate for a dozen different menu options doing very small variants of what's otherwise the exact same thing. Basically, I originally had it setup in a menu tree like this: current kernel primary root fallback kernel primary root backups menu primary root current kernel fallback kernel stable kernel backup root current kernel fallback kernel stable kernel backup2 root current kernel fallback kernel stable kernel init=/bin/bash primary root current kernel fallback kernel stable kernel backup root current kernel fallback kernel stable kernel backup2 root current kernel fallback kernel stable kernel single mode primary root current kernel fallback kernel stable kernel backup root current kernel fallback kernel stable kernel backup2 root current kernel fallback kernel stable kernel utils menu reboot halt boothints cat boothints1 cat boothints2 cat boothints3 Now instead of that I have something more like this, much shorter but also much more flexible!: current kernel primary root backups menu boot set kernel.current set kernel.fallback set kernel.stable set root.ssd.primary set root.ssd.secondary set root.rust.1 set root.rust.2 set root.rust.3 set opts.initbash set opts.single set opts.other reset opts utils menu reboot halt boothints browse So now the initial menu only has three items on it, current boot, backups, and utils. There's a timeout on the default current boot, so if I do nothing, it'll boot that without interference. The backups menu allows me to set different options for kernel, root, and general options, or clear the existing general options so defaults are used. When I'm satisfied with the changes I've selected, I choose the boot option, which echoes the kernel command line it'll execute and prompts for confirmation, then executes if I give it. The kernel and root options overwrite any value previously set, while the general options don't overwrite each other, so there's a reset option for that. Note that this way, I have far more flexibility with far less duplicated config, just by selecting the options I want, then hitting the boot option to actually prompt for confirmation and then boot. Before, I couldn't select BOTH single mode AND init=/bin/bash; now I can (tho why one might want both remains an open question, since single mode with bash as init does nothing). And now I have five root options instead of three, with less code duplication to do it. For the general options, initbash simply sets init=/bin/bash, and single simply sets s, to boot into single user mode. Other options simply prompts for manual entry of additional options, as desired. (opts.other is the option I just added today, thus my call it config version 2.1 comment above. Now I don't need to switch to commandline mode just to add another option to my kernel commandline, as I can simply select that menu option and type it in there, before selecting the boot option, confirming that I typed it correctly with the echoed to-be-run kernel comandline, and booting.) On the utils menu, reboot and halt allow me to do that directly from grub. That makes it possible to simply hit the three-finger salute (aka ctrl-alt-del) from in linux to reboot, then select halt in grub, if I'm lazy and would rather do that than reach up to the power button to trigger a system shutdown that way. I initially setup grub2 before grub2's final release, while it was still in beta. One of the betas screwed up the pager functionality, so I had to split my boothints (kernel commandline options I might find useful) notes into several pages, each of which could fit a single screen. Of course that bug was fixed in the general grub2 release, so a single boothints option allows me to page thru a combined longer boothints file, now. And the browse option... uses grub2's search by label command to automatically set some variables appropriately, so instead of manually figuring out which (gpt0,X) value to use to get say the first backup home partition on spinning rust, I can simply use the browse option to set all the vars, then switch to the grub2 commandline and do something like this: set (shows me a list of set vars, so I can pick the one to use) cat $hmr1/user/.bashrc (Prints out the selected file, automatically stopping at each screenfull if the pager var is set, as mine is by default. If that partition/volume happens to be on raid or lvm or whatever, or some exotic filesystem like btrfs or zfs as long as there's a grub2 module for it (as there is for those two), or if it's a compressed file, grub has modules for some types of compression too, a load of the appropriate grub2 modules will let the grub search by label and cat functions work just as they would on a partition directly on the hardware itself, so the file can still be catted. =:^) Like I said it's not necessarily the be-all and end-all of fancy bash configurations, but it should give you a much more concrete idea of just the sort of flexibility and power that grub2 has, and the type of setup one can configure if desired. -- 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