From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 140CC138350 for ; Sat, 2 May 2020 07:49:44 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9621FE0AA6; Sat, 2 May 2020 07:49:37 +0000 (UTC) Received: from smtpcmd12131.aruba.it (smtpcmd12131.aruba.it [62.149.156.131]) by pigeon.gentoo.org (Postfix) with ESMTP id EA78EE0A94 for ; Sat, 2 May 2020 07:49:36 +0000 (UTC) Received: from mail.agr.fm ([151.48.153.140]) by smtpcmd12.ad.aruba.it with bizsmtp id Zjpb22009320c1T01jpbuk; Sat, 02 May 2020 09:49:35 +0200 Received: from [192.168.64.1] (fire.agr.fm [192.168.64.1]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.agr.fm (Postfix) with ESMTPS id 659BA36001B for ; Sat, 2 May 2020 09:49:33 +0200 (CEST) Subject: Re: [gentoo-user] Trouble with backup harddisks To: gentoo-user@lists.gentoo.org References: <20200430093217.efprkpt4kbvir7nr@solfire> <20200501071810.h6qs7kgewwtbytqd@solfire> <2530524.mvXUDI8C0e@peak> <20200502020305.bvnxxt2egw6evx6d@solfire> From: Andrea Conti Message-ID: Date: Sat, 2 May 2020 09:49:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 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 X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 In-Reply-To: <20200502020305.bvnxxt2egw6evx6d@solfire> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aruba.it; s=a1; t=1588405775; bh=q0fto37a2J5XOtXNSHDFrSV5nlJ7Tmsi7rEmiUWE2e0=; h=Subject:To:From:Date:MIME-Version:Content-Type; b=kbNeNKJ88eQsAd7b1KtqmHrTX2iBGiWsT2288C/hATgjtFXP+S3wn/yBbQqBxi/2h PL25tK+0w9jDuZvVtxswDNg3Np+dmQtipBxfJWSn++SEf/gACzwo8gdOAtImpaf3kk +pI3e8vc9ghCh/zDZoB50OK9MHOwVegxQ84duLdBWboHoJtDd1gxQ/HccvXf/NRadN rnOyM9yB4hXYvWYgdIuYaWfXDc2zwwxLQJ5e2uXD8WTWMP3fWWMNe8Ep6lxTaDXrsc QDjrhjPtMo7cgqTAO0vLHvFIZANia+IWB/CvPfAalXFxE6TpHcdfsCIT65/Qft2qV0 FwZZgzT8m+B8w== X-Archives-Salt: 8ceb2d70-0c9d-4380-abc1-553a7b7cf7b5 X-Archives-Hash: 9aba3fd7832197589c1500f9563452a6 > I think, I feel better if I repartitioning/reformat both drives, > though. It's not necessary, but if it makes you feel better by all means do so. > *GPT/MBR > From a discussion based on a "GPT or MBR for my system drive" in > conjunction with UEFI it was said, that GPT is more modern and > save. More modern I concur. For the rest it's mainly about features: >2TB partitions and way more metadata, plus not having to bother with CHS values which make no sense in today's drives. And being able to define >4 partitions without littering the disk with extended boot records, which is probably the only thing I'd call "safer". My point was that none of this is relevant in an external drive which is under 1TB and will only hold a single partition starting at sector 1 and spanning the rest of the disk. A system drive, especially if booting from UEFI is a different case for which GPT absolutely makes sense. > My question was meant not so much as "MBR or GPT?" > but more whether there are some variants of GPT (with > protected MBR for example -- which was completly new to me), > which I should use or avoid. There are really no "variants" of GPT. The protective MBR is only there to make all space in the disk look allocated to MBR partitioning tools that are not GPT-aware, and is automatically written for you by all GPT partitioning tools. In addition to the opaque entry of type 0xee, this MBR can also contain entries pointing to at least some of the actual partitions; this is called a 'hybrid' MBR and allows MBR-only access to partitions that are within the limits of MBR addressing (start and end sector <2TB). These are only useful in very specific cases an I would consider them a hack more than a solution; while gpt-fdisk has some support for creating hybrid MBRs (don't know about fdisk), you won't get one unless you specifically ask for it. > But: Are rescue systems for USB-stick more UEFI/GPT aware nowadays > or "traditionally" based on MBR/BIOS-boot? I think that anything that's not ancient will have tools and kernel support for both MBR and GPT, and will boot fine in both BIOS and UEFI modes. > One thing I found is really handy: An USB-stick with an rEfind > installation. As long as your PC supports UEFI (or can switched to it) > rEfind is able to boot "everything" without prior configuration. You can probably do the same with GRUB2, albeit in a way less user-friendly fashion :) But why do you consider the ability to boot anything but the rescue system itself important in a rescue system? > > Some rescue-system which really shines and with which you have made good > experiences? My usual go-to is SystemRescueCD (the old 5.x gentoo-based one). andrea