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 11C451381FA for ; Sun, 4 May 2014 18:41:30 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5C474E0AE8; Sun, 4 May 2014 18:41:24 +0000 (UTC) Received: from smtpq2.tb.mail.iss.as9143.net (smtpq2.tb.mail.iss.as9143.net [212.54.42.165]) by pigeon.gentoo.org (Postfix) with ESMTP id 42741E0AE3 for ; Sun, 4 May 2014 18:41:23 +0000 (UTC) Received: from [212.54.42.136] (helo=smtp5.tb.mail.iss.as9143.net) by smtpq2.tb.mail.iss.as9143.net with esmtp (Exim 4.71) (envelope-from ) id 1Wh1Lm-0004Fd-8f for gentoo-user@lists.gentoo.org; Sun, 04 May 2014 20:41:22 +0200 Received: from 53579160.cm-6-8c.dynamic.ziggo.nl ([83.87.145.96] helo=data.antarean.org) by smtp5.tb.mail.iss.as9143.net with esmtp (Exim 4.71) (envelope-from ) id 1Wh1Lk-0007aB-Iv for gentoo-user@lists.gentoo.org; Sun, 04 May 2014 20:41:22 +0200 Received: from andromeda.localnet (unknown [10.20.13.150]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by data.antarean.org (Postfix) with ESMTPSA id 671A54C for ; Sun, 4 May 2014 20:40:47 +0200 (CEST) From: "J. Roeleveld" To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] boot problems Date: Sun, 04 May 2014 20:40:29 +0200 Message-ID: <1453433.qRkdsgn7FL@andromeda> User-Agent: KMail/4.11.5 (Linux/3.10.25-gentoo; KDE/4.11.5; x86_64; ; ) In-Reply-To: <53663B90.6050600@xunil.at> References: <5364C0F9.3000906@xunil.at> <3349320.Vv5J0h2UtC@andromeda> <53663B90.6050600@xunil.at> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Ziggo-spambar: ---- X-Ziggo-spamscore: -4.8 X-Ziggo-spamreport: ALL_TRUSTED=-1,BAYES_00=-1.9,PROLO_TRUST_RDNS=-3,RDNS_DYNAMIC=0.982,WORDPRESS_PLUS=0.12 X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No X-Archives-Salt: b76434bc-ddd1-4307-9ce3-d8cae9abe9ea X-Archives-Hash: a1b445e16f584d0a6a392ec1a986c7b6 On Sunday, May 04, 2014 03:07:28 PM Stefan G. Weichinger wrote: > Am 04.05.2014 12:49, schrieb J. Roeleveld: > > I wouldn't use the stripe/mirror support in LVM as I don't think it is > > used > > often and I feel that functionality doesn't belong in LVM. > > If you want to move it all into a single layer, I would suggest ZFS > > instead. > Oh, yes, I like ZFS and its features and used it in some cases already. > But I didn't yet take the step to set up ZFS-root on my work machines. I haven't yet, but it's on the list of items to look into at some point. I'd like to know if, with ZFS, it is possible to create block-devices like LVs which I can then attach to VMs. Or if I have to use files instead. > >> And then you get into issues with block sizes and stuff, where I always > >> wonder why *I* have to type all these parameters ... why doesn't modern > >> software just come with this knowledge inside? > >> > >> .... you know > >> > >> *sigh* ;-) > > > > I agree, and I feel that has actually improved over time with modern tools > > defaulting to 4k sectors. > > Yes, but it always feels like "I missed something" when you look at the > various layers: partitioning at correct sectors, RAIDs with their > parameters, creating PVs with PEs aligned ... and then the filesystems. > I never get the feeling that I really did it right from the base to the > top. True, but if all the tools are working correctly, it all should cascade down when getting the "sector" sizes from the previous layer. Not sure if this actually works. I think it does as I get the following on my server: *** # gdisk -l /dev/sda GPT fdisk (gdisk) version 0.8.8 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk /dev/sda: 11718749184 sectors, 5.5 TiB Logical sector size: 512 bytes Disk identifier (GUID): 936FDBE4-A736-41CF-B9A5-51069940D3DB Partition table holds up to 128 entries First usable sector is 34, last usable sector is 11718749150 Partitions will be aligned on 2048-sector boundaries Total free space is 2014 sectors (1007.0 KiB) Number Start (sector) End (sector) Size Code Name 1 2048 411647 200.0 MiB EF00 EFI System 2 411648 2101247 825.0 MiB 8300 Linux filesystem 3 2101248 11718749150 5.5 TiB 8E00 Linux LVM *** That's a hardware raid device with 4 * 3TB disks with raid-6. I don't like the fact that a 2nd disk-failure can kill a raid-10 when both disks are in the same mirror-set. gdisk automatically aligns on 2048 sector boundaries, that is more then enough for the 4k-sectors and the block/stripe sizes employed by the raid-controller. > > Then it should work, provided you have all the required drivers inside > > your > > kernel and not as modules. > > I also believe an initramfs is needed when using LABELs for the root-fs. > > Interesting. I don't really care if I have an initramfs or not, as long > as things work ... The feature with LABELs is nice for preparing > installations in VMs and then move it to physical hardware (eg. > /dev/vda1 then becomes /dev/sda1 or /dev/md0 and booting fails). UUIDs, I believe, do work natively. And those are stored inside the partition itself. Which means they should also work. But are not as easy to locate. (eg. you don't specify them yourself) > > At the moment, I don't see, from a simple user perspective, any real > > difference between booting using UEFI and BIOS/MBR. > > UEFI is one thing, GPT partitioning another. Being able to have more > than the 4 primary partitions of MBR looks good to me ... > > I will see where my motivation leads to ;-) See the partitioning on my server above. It boots using BIOS as I haven't been able to boot Xen using UEFI yet. Support should be there now, but not been able to test that yet. GPT is supported by grub-1 (and grub2) and with the MBR-support inside GPT, booting works from BIOS/MBR. -- Joost