From: tuxic@posteo.de
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Trouble with backup harddisks
Date: Sat, 2 May 2020 10:39:12 +0200 [thread overview]
Message-ID: <20200502083912.yhf6zu3kxoixwcjy@solfire> (raw)
In-Reply-To: <bf503aff-e757-8574-4985-5d9b3216adfd@alyf.net>
On 05/02 09:49, Andrea Conti wrote:
> > 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.
>
Ok, the other way around: Does GPT hurt more than MBT on a external HD
used for backup puporses (no boot), has 1T and 1 partion of that size?
> > 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.
>:
Thanks of the information! :)
> > 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?
Recently a BIOS update deleted all UEFI entries and the system no
longer boots. With rEfind from a USBstick I was able to boot
the sustem nonetheless and the reinstallation of grub solves
the problem.
Task accomplished! :)
> >
> > 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
Thanks for the info, Andrea!
Cheers!
Meino
next prev parent reply other threads:[~2020-05-02 8:39 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-30 9:32 [gentoo-user] Trouble with backup harddisks tuxic
2020-04-30 9:55 ` Wols Lists
2020-04-30 10:36 ` tuxic
2020-04-30 12:17 ` Wols Lists
2020-04-30 13:10 ` Wynn Wolf Arbor
2020-04-30 17:04 ` tuxic
2020-04-30 17:21 ` Wynn Wolf Arbor
2020-04-30 19:32 ` antlists
2020-05-01 1:59 ` tuxic
2020-05-01 8:03 ` tuxic
2020-05-01 20:27 ` antlists
2020-05-02 1:42 ` tuxic
2020-05-02 17:31 ` Wols Lists
2020-05-02 17:49 ` tuxic
2020-05-02 17:55 ` tuxic
2020-04-30 13:44 ` Andrea Conti
2020-04-30 18:08 ` tuxic
2020-04-30 19:27 ` Wynn Wolf Arbor
2020-04-30 19:46 ` tuxic
2020-04-30 19:59 ` Wynn Wolf Arbor
2020-04-30 20:21 ` Andrea Conti
2020-04-30 20:47 ` Wynn Wolf Arbor
2020-05-01 5:07 ` tuxic
2020-05-01 6:52 ` Andrea Conti
2020-05-01 7:18 ` tuxic
2020-05-01 10:27 ` Wynn Wolf Arbor
2020-05-01 16:00 ` Andrea Conti
2020-05-01 16:32 ` Peter Humphrey
2020-05-02 2:03 ` tuxic
2020-05-02 7:49 ` Andrea Conti
2020-05-02 8:39 ` tuxic [this message]
2020-05-02 9:23 ` Michael
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200502083912.yhf6zu3kxoixwcjy@solfire \
--to=tuxic@posteo.de \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox