Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.os.linux.misc > #77673 > unrolled thread

Taming The Data Destroyer

Started byLawrence D’Oliveiro <ldo@nz.invalid>
First post2025-11-17 02:31 +0000
Last post2025-11-18 02:07 -0500
Articles 20 on this page of 45 — 12 participants

Back to article view | Back to comp.os.linux.misc


Contents

  Taming The Data Destroyer Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-17 02:31 +0000
    Re: Taming The Data Destroyer rbowman <bowman@montana.com> - 2025-11-17 04:18 +0000
      Re: Taming The Data Destroyer Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-11-17 10:42 +0100
        Re: Taming The Data Destroyer Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-18 01:10 +0000
          Re: Taming The Data Destroyer c186282 <c186282@nnada.net> - 2025-11-17 21:08 -0500
      Re: Taming The Data Destroyer "Carlos E.R." <robin_listas@es.invalid> - 2025-11-17 12:51 +0100
    Re: Taming The Data Destroyer jayjwa <jayjwa@atr2.ath.cx.invalid> - 2025-11-17 12:55 -0500
      Re: Taming The Data Destroyer not@telling.you.invalid (Computer Nerd Kev) - 2025-11-18 07:06 +1000
        Re: Taming The Data Destroyer c186282 <c186282@nnada.net> - 2025-11-17 19:00 -0500
          Re: Taming The Data Destroyer Computer Nerd Kev <not@telling.you.invalid> - 2025-11-18 16:31 +1000
            Re: Taming The Data Destroyer "Carlos E.R." <robin_listas@es.invalid> - 2025-11-18 07:46 +0100
              Re: Taming The Data Destroyer c186282 <c186282@nnada.net> - 2025-11-18 02:12 -0500
                Re: Taming The Data Destroyer rbowman <bowman@montana.com> - 2025-11-18 23:02 +0000
            Re: Taming The Data Destroyer c186282 <c186282@nnada.net> - 2025-11-18 02:01 -0500
              Re: Taming The Data Destroyer Ralf Fassel <ralfixx@gmx.de> - 2025-11-18 16:24 +0100
                Re: Taming The Data Destroyer The Natural Philosopher <tnp@invalid.invalid> - 2025-11-18 15:30 +0000
                  Re: Taming The Data Destroyer Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-18 22:31 +0000
                Re: Taming The Data Destroyer "Carlos E.R." <robin_listas@es.invalid> - 2025-11-18 17:49 +0100
                  Re: Taming The Data Destroyer c186282 <c186282@nnada.net> - 2025-11-19 18:32 -0500
                    Re: Taming The Data Destroyer "Carlos E.R." <robin_listas@es.invalid> - 2025-11-20 12:57 +0100
                      Re: Taming The Data Destroyer Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-20 22:53 +0000
                        Re: Taming The Data Destroyer c186282 <c186282@nnada.net> - 2025-11-20 22:04 -0500
                      Re: Taming The Data Destroyer c186282 <c186282@nnada.net> - 2025-11-20 22:17 -0500
            Re: Taming The Data Destroyer Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-18 07:18 +0000
              Re: Taming The Data Destroyer c186282 <c186282@nnada.net> - 2025-11-18 02:34 -0500
                Re: Taming The Data Destroyer "Carlos E.R." <robin_listas@es.invalid> - 2025-11-18 08:46 +0100
                  Re: Taming The Data Destroyer Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-18 08:09 +0000
                    Re: Taming The Data Destroyer "Carlos E.R." <robin_listas@es.invalid> - 2025-11-18 17:55 +0100
                      Re: Taming The Data Destroyer Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-18 19:35 +0000
                        Re: Taming The Data Destroyer not@telling.you.invalid (Computer Nerd Kev) - 2025-11-19 06:48 +1000
                          Re: Taming The Data Destroyer The Natural Philosopher <tnp@invalid.invalid> - 2025-11-18 21:40 +0000
                            Re: Taming The Data Destroyer Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-18 22:27 +0000
                          Re: Taming The Data Destroyer Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-18 22:26 +0000
                          Re: Taming The Data Destroyer c186282 <c186282@nnada.net> - 2025-11-19 18:23 -0500
                        Re: Taming The Data Destroyer "Carlos E.R." <robin_listas@es.invalid> - 2025-11-19 02:41 +0100
                  Re: Taming The Data Destroyer c186282 <c186282@nnada.net> - 2025-11-18 03:17 -0500
                    Re: Taming The Data Destroyer The Natural Philosopher <tnp@invalid.invalid> - 2025-11-18 12:12 +0000
                      Re: Taming The Data Destroyer "Carlos E.R." <robin_listas@es.invalid> - 2025-11-18 17:53 +0100
                        Re: Taming The Data Destroyer Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-18 19:32 +0000
              Re: Taming The Data Destroyer Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> - 2025-11-18 14:46 +0200
        Re: Taming The Data Destroyer candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-11-20 18:40 +0000
      Re: Taming The Data Destroyer Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-18 00:58 +0000
        Re: Taming The Data Destroyer c186282 <c186282@nnada.net> - 2025-11-17 21:04 -0500
          Re: Taming The Data Destroyer rbowman <bowman@montana.com> - 2025-11-18 06:32 +0000
            Re: Taming The Data Destroyer c186282 <c186282@nnada.net> - 2025-11-18 02:07 -0500

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →


#77762

FromLawrence D’Oliveiro <ldo@nz.invalid>
Date2025-11-20 22:53 +0000
Message-ID<10fo64q$39kk9$1@dont-email.me>
In reply to#77754
On Thu, 20 Nov 2025 12:57:07 +0100, Carlos E.R. wrote:

> ChatGpt will happily try to get you a CLI that produces what you work. 
> But it also fails, and after several cycles you get mad.

And maybe you stop depending on AI for an easy way out?

[toc] | [prev] | [next] | [standalone]


#77769

Fromc186282 <c186282@nnada.net>
Date2025-11-20 22:04 -0500
Message-ID<Z3KdnVdzjOhcS4L0nZ2dnZfqnPednZ2d@giganews.com>
In reply to#77762
On 11/20/25 17:53, Lawrence D’Oliveiro wrote:
> On Thu, 20 Nov 2025 12:57:07 +0100, Carlos E.R. wrote:
> 
>> ChatGpt will happily try to get you a CLI that produces what you work.
>> But it also fails, and after several cycles you get mad.
> 
> And maybe you stop depending on AI for an easy way out?

   I don't think that's going to happen soon, if ever.
   "AI" means Less Thinking Required and that's GREAT
   with 99.9999% of the pop. Wrong answers ? Who Cares -
   it's the AIs fault !

[toc] | [prev] | [next] | [standalone]


#77770

Fromc186282 <c186282@nnada.net>
Date2025-11-20 22:17 -0500
Message-ID<Z3KdnVZzjOgwRIL0nZ2dnZfqnPednZ2d@giganews.com>
In reply to#77754
On 11/20/25 06:57, Carlos E.R. wrote:
> On 2025-11-20 00:32, c186282 wrote:
>> On 11/18/25 11:49, Carlos E.R. wrote:
>>> On 2025-11-18 16:24, Ralf Fassel wrote:
>>>> * c186282 <c186282@nnada.net>
>>>> |   In any case, newbies need to be CAREFUL - don't
>>>> |   just cut-n-paste anything you find. If you're
>>>> |   not sure - DON'T !
>>>>
>>>> But... but... the AI said it was ok to use that command! ;-)
>>>>
>>>> Your advice holds not only for newbies.  When I search for the solution
>>>> on some "non-trivial" problem, sometimes I wonder what the magic
>>>> incantation on some search result is - a new clever way to achieve the
>>>> result, monkey-see-monkey-do copied from somewhere else, or simply
>>>> nonsense (possibly in combination with #2).  More often than not it
>>>> turns out to be the latter...
>>>>
>>>> R'
>>>
>>> I have found ChatGpt very useful to help me with solving problems 
>>> with my 8 disk software raid 6 array. It does diagnose the problem 
>>> correctly and generates the correct command line concoctions. Of 
>>> course I check the lines, but they look correct, and do work.
>>
>>    Until one melts your drive  :-)
>>
>>    Of late I'd been doing a lot of stuff with 'ffmpeg'.
>>    It's an all-purpose tool BUT to get what YOU want
>>    often involves ten or fifteen CL flags and such
>>    AND in a particular order. Plenty of 'examples' to
>>    be found online - not all agree with each other.
>>
>>    Basically you need the skills to put the evil eye on
>>    such 'free' code BEFORE you run it, looking for that
>>    little 'gotcha'. Look up those commands, their params,
>>    the 'why', before you go too far. Being a computer jock,
>>    even in the AI age, is a learned skill ... not something
>>    Granny can just jump into.
> 
> And if you read the entire man page and study it, for version 3, say, 
> then comes another version which has changes and some of the 
> combinations you used now do not work or have changed. They are now at 
> version 8.

   Yep, they tend to change things ... "backwards
   compatibility" isn't always the first thing
   in mind ......

   Hate to say it, but M$ is actually better that way.

> I suppose that's the reason that openSUSE ships all versions from 3 
> onwards.

   Maybe.

> ChatGpt will happily try to get you a CLI that produces what you work. 
> But it also fails, and after several cycles you get mad.

   AIs aren't really "smart" yet - they'll find
   lots of solutions from 1997 and decide to give
   you those. Hey, "lots" = "correct", right ?

[toc] | [prev] | [next] | [standalone]


#77709

FromLawrence D’Oliveiro <ldo@nz.invalid>
Date2025-11-18 07:18 +0000
Message-ID<10fh6jl$1cvaf$1@dont-email.me>
In reply to#77703
On 18 Nov 2025 16:31:19 +1000, Computer Nerd Kev wrote:

> No fdisk won't do damage instantly when you just run one command from
> the command line, modifying partitions is done in its interactive mode.
> You can't stuff things up just by attempting an "fdisk -l".

I think it was parted I found that made its changes to the disk instantly, 
without requiring an explicit save.

I discovered that the hard way. Avoided it after that.

sfdisk was a handy one for saving/restoring the entire partition table in 
a single command -- particularly in the days before fdisk acquired GPT 
support.

[toc] | [prev] | [next] | [standalone]


#77711

Fromc186282 <c186282@nnada.net>
Date2025-11-18 02:34 -0500
Message-ID<FN6dnd-S1YvkvIH0nZ2dnZfqnPSdnZ2d@giganews.com>
In reply to#77709
On 11/18/25 02:18, Lawrence D’Oliveiro wrote:
> On 18 Nov 2025 16:31:19 +1000, Computer Nerd Kev wrote:
> 
>> No fdisk won't do damage instantly when you just run one command from
>> the command line, modifying partitions is done in its interactive mode.
>> You can't stuff things up just by attempting an "fdisk -l".
> 
> I think it was parted I found that made its changes to the disk instantly,
> without requiring an explicit save.
> 
> I discovered that the hard way. Avoided it after that.
> 
> sfdisk was a handy one for saving/restoring the entire partition table in
> a single command -- particularly in the days before fdisk acquired GPT
> support.

   Umm ... rec ... if possible use 'gparted' instead.
   Takes care of the little stuff.

[toc] | [prev] | [next] | [standalone]


#77712

From"Carlos E.R." <robin_listas@es.invalid>
Date2025-11-18 08:46 +0100
Message-ID<pqktulxh6u.ln2@Telcontar.valinor>
In reply to#77711
On 2025-11-18 08:34, c186282 wrote:
> On 11/18/25 02:18, Lawrence D’Oliveiro wrote:
>> On 18 Nov 2025 16:31:19 +1000, Computer Nerd Kev wrote:
>>
>>> No fdisk won't do damage instantly when you just run one command from
>>> the command line, modifying partitions is done in its interactive mode.
>>> You can't stuff things up just by attempting an "fdisk -l".
>>
>> I think it was parted I found that made its changes to the disk 
>> instantly,
>> without requiring an explicit save.
>>
>> I discovered that the hard way. Avoided it after that.
>>
>> sfdisk was a handy one for saving/restoring the entire partition table in
>> a single command -- particularly in the days before fdisk acquired GPT
>> support.
> 
>    Umm ... rec ... if possible use 'gparted' instead.
>    Takes care of the little stuff.

That's the tool I use.

But we also need, for backups, something that can save and reconstruct 
the partition table, even GPT.

-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]


#77715

FromLawrence D’Oliveiro <ldo@nz.invalid>
Date2025-11-18 08:09 +0000
Message-ID<10fh9it$1dmda$1@dont-email.me>
In reply to#77712
On Tue, 18 Nov 2025 08:46:01 +0100, Carlos E.R. wrote:

> But we also need, for backups, something that can save and reconstruct
> the partition table, even GPT.

“sfdisk -d” dumps out the partition table in a format that it can read 
back in and set up again.

[toc] | [prev] | [next] | [standalone]


#77725

From"Carlos E.R." <robin_listas@es.invalid>
Date2025-11-18 17:55 +0100
Message-ID<61luulxffm.ln2@Telcontar.valinor>
In reply to#77715
On 2025-11-18 09:09, Lawrence D’Oliveiro wrote:
> On Tue, 18 Nov 2025 08:46:01 +0100, Carlos E.R. wrote:
> 
>> But we also need, for backups, something that can save and reconstruct
>> the partition table, even GPT.
> 
> “sfdisk -d” dumps out the partition table in a format that it can read
> back in and set up again.

Right. I just located a copy of the backup script (the working copy is stored on the external HD), and that is what I do.

     sfdisk -d /dev/disk/by-id/$DISKID > $DISKNAME-partition_table_sfdisk.out

     fdisk -l /dev/disk/by-id/$DISKID  > $DISKNAME-partition_table_fdisk.out

     dd if=/dev/disk/by-id/$DISKID of=$DISKNAME-mbr count=1


-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]


#77729

FromLawrence D’Oliveiro <ldo@nz.invalid>
Date2025-11-18 19:35 +0000
Message-ID<10fihq5$1p41c$6@dont-email.me>
In reply to#77725
On Tue, 18 Nov 2025 17:55:34 +0100, Carlos E.R. wrote:

> On 2025-11-18 09:09, Lawrence D’Oliveiro wrote:
>>
>> On Tue, 18 Nov 2025 08:46:01 +0100, Carlos E.R. wrote:
>>
>>> But we also need, for backups, something that can save and
>>> reconstruct the partition table, even GPT.
>>
>> “sfdisk -d” dumps out the partition table in a format that it can
>> read back in and set up again.
>
> Right. I just located a copy of the backup script (the working copy
> is stored on the external HD), and that is what I do.
>
>      sfdisk -d /dev/disk/by-id/$DISKID > $DISKNAME-partition_table_sfdisk.out

Good idea.

>      fdisk -l /dev/disk/by-id/$DISKID  > $DISKNAME-partition_table_fdisk.out

This does display actual sector numbers (along with rounded total
sizes), but I don’t think this is a useful format for restoration.

>      dd if=/dev/disk/by-id/$DISKID of=$DISKNAME-mbr count=1

This I wouldn’t bother with. Why? Because restoring it will wipe out
your bootloader.

[toc] | [prev] | [next] | [standalone]


#77731

Fromnot@telling.you.invalid (Computer Nerd Kev)
Date2025-11-19 06:48 +1000
Message-ID<691cdb96@news.ausics.net>
In reply to#77729
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Tue, 18 Nov 2025 17:55:34 +0100, Carlos E.R. wrote:
>>      fdisk -l /dev/disk/by-id/$DISKID  > $DISKNAME-partition_table_fdisk.out
> 
> This does display actual sector numbers (along with rounded total
> sizes), but I don't think this is a useful format for restoration.

In the real world the replacement drive after one has died often
isn't exactly the same size as the last one so I want to read the
former partition layout manually then manually create something
like it on the new drive, but with sizes adjusted to suit.

>>      dd if=/dev/disk/by-id/$DISKID of=$DISKNAME-mbr count=1
> 
> This I wouldn't bother with. Why? Because restoring it will wipe out
> your bootloader.

It should restore your bootloader, although if you've fiddled with
the partitions on the new drive then that bootloader might not
work anymore.

-- 
__          __
#_ < |\| |< _#

[toc] | [prev] | [next] | [standalone]


#77732

FromThe Natural Philosopher <tnp@invalid.invalid>
Date2025-11-18 21:40 +0000
Message-ID<10fip3o$1rgr7$2@dont-email.me>
In reply to#77731
On 18/11/2025 20:48, Computer Nerd Kev wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Tue, 18 Nov 2025 17:55:34 +0100, Carlos E.R. wrote:
>>>       fdisk -l /dev/disk/by-id/$DISKID  > $DISKNAME-partition_table_fdisk.out
>>
>> This does display actual sector numbers (along with rounded total
>> sizes), but I don't think this is a useful format for restoration.
> 
> In the real world the replacement drive after one has died often
> isn't exactly the same size as the last one so I want to read the
> former partition layout manually then manually create something
> like it on the new drive, but with sizes adjusted to suit.
> 
Restore and then use a partition editor to upscale the partitions


>>>       dd if=/dev/disk/by-id/$DISKID of=$DISKNAME-mbr count=1
>>
>> This I wouldn't bother with. Why? Because restoring it will wipe out
>> your bootloader.
> 
> It should restore your bootloader, although if you've fiddled with
> the partitions on the new drive then that bootloader might not
> work anymore.
> 
I usually have  restricted size root partition and sometimes a /home and 
/var

But those last can be backed up, unmounted, deleted and recreated and 
the data restored from the backup...


-- 
"First, find out who are the people you can not criticise. They are your 
oppressors."
      - George Orwell

[toc] | [prev] | [next] | [standalone]


#77734

FromLawrence D’Oliveiro <ldo@nz.invalid>
Date2025-11-18 22:27 +0000
Message-ID<10firt8$1s3s6$4@dont-email.me>
In reply to#77732
On Tue, 18 Nov 2025 21:40:08 +0000, The Natural Philosopher wrote:

> I usually have restricted size root partition and sometimes a /home
> and /var

Having too many partitions can reduce your flexibility in adapting to
changed needs.

Did you know Linux doesn’t even need a partition table? You can format
the entire device as a filesystem volume.

[toc] | [prev] | [next] | [standalone]


#77733

FromLawrence D’Oliveiro <ldo@nz.invalid>
Date2025-11-18 22:26 +0000
Message-ID<10firpt$1s3s6$3@dont-email.me>
In reply to#77731
On 19 Nov 2025 06:48:22 +1000, Computer Nerd Kev wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>> On Tue, 18 Nov 2025 17:55:34 +0100, Carlos E.R. wrote:
>>>
>>>      dd if=/dev/disk/by-id/$DISKID of=$DISKNAME-mbr count=1
>>
>> This I wouldn't bother with. Why? Because restoring it will wipe out
>> your bootloader.
>
> It should restore your bootloader ...

It will restore the state of your bootloader as of the time you took
the backup, which is not necessarily what you want.

[toc] | [prev] | [next] | [standalone]


#77747

Fromc186282 <c186282@nnada.net>
Date2025-11-19 18:23 -0500
Message-ID<8OWdnVtgGpwazIP0nZ2dnZfqnPWdnZ2d@giganews.com>
In reply to#77731
On 11/18/25 15:48, Computer Nerd Kev wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Tue, 18 Nov 2025 17:55:34 +0100, Carlos E.R. wrote:
>>>       fdisk -l /dev/disk/by-id/$DISKID  > $DISKNAME-partition_table_fdisk.out
>>
>> This does display actual sector numbers (along with rounded total
>> sizes), but I don't think this is a useful format for restoration.
> 
> In the real world the replacement drive after one has died often
> isn't exactly the same size as the last one so I want to read the
> former partition layout manually then manually create something
> like it on the new drive, but with sizes adjusted to suit.
> 
>>>       dd if=/dev/disk/by-id/$DISKID of=$DISKNAME-mbr count=1
>>
>> This I wouldn't bother with. Why? Because restoring it will wipe out
>> your bootloader.
> 
> It should restore your bootloader, although if you've fiddled with
> the partitions on the new drive then that bootloader might not
> work anymore.

   Trick I learned the hard way ... when initially
   setting up disk partitions do NOT use the ENTIRE
   drive ... but leave maybe 100mb or so free space
   at the end. You won't miss that on a 4/8+ tb drive
   in the least but it will sometimes get you around
   the slight size differences between even supposedly
   identical drive models. Then you can use 'dd' to
   easily restore a full-sized partition backup.

   Some utilities (more of them for Win) make 'sparse'
   partition backups and CAN do your abovementioned
   math to re-size to fit.

[toc] | [prev] | [next] | [standalone]


#77738

From"Carlos E.R." <robin_listas@es.invalid>
Date2025-11-19 02:41 +0100
Message-ID<irjvulxcnk.ln2@Telcontar.valinor>
In reply to#77729
On 2025-11-18 20:35, Lawrence D’Oliveiro wrote:
> On Tue, 18 Nov 2025 17:55:34 +0100, Carlos E.R. wrote:
> 
>> On 2025-11-18 09:09, Lawrence D’Oliveiro wrote:
>>>
>>> On Tue, 18 Nov 2025 08:46:01 +0100, Carlos E.R. wrote:
>>>
>>>> But we also need, for backups, something that can save and
>>>> reconstruct the partition table, even GPT.
>>>
>>> “sfdisk -d” dumps out the partition table in a format that it can
>>> read back in and set up again.
>>
>> Right. I just located a copy of the backup script (the working copy
>> is stored on the external HD), and that is what I do.
>>
>>       sfdisk -d /dev/disk/by-id/$DISKID > $DISKNAME-partition_table_sfdisk.out
> 
> Good idea.
> 
>>       fdisk -l /dev/disk/by-id/$DISKID  > $DISKNAME-partition_table_fdisk.out
> 
> This does display actual sector numbers (along with rounded total
> sizes), but I don’t think this is a useful format for restoration.

Humans can read it, and to recreate a partition at a different location 
you need the actual sector count.

> 
>>       dd if=/dev/disk/by-id/$DISKID of=$DISKNAME-mbr count=1
> 
> This I wouldn’t bother with. Why? Because restoring it will wipe out
> your bootloader.

Or recreate it on an empty disk :-)



-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]


#77717

Fromc186282 <c186282@nnada.net>
Date2025-11-18 03:17 -0500
Message-ID<cYScnSnPtegGtoH0nZ2dnZfqnPudnZ2d@giganews.com>
In reply to#77712
On 11/18/25 02:46, Carlos E.R. wrote:
> On 2025-11-18 08:34, c186282 wrote:
>> On 11/18/25 02:18, Lawrence D’Oliveiro wrote:
>>> On 18 Nov 2025 16:31:19 +1000, Computer Nerd Kev wrote:
>>>
>>>> No fdisk won't do damage instantly when you just run one command from
>>>> the command line, modifying partitions is done in its interactive mode.
>>>> You can't stuff things up just by attempting an "fdisk -l".
>>>
>>> I think it was parted I found that made its changes to the disk 
>>> instantly,
>>> without requiring an explicit save.
>>>
>>> I discovered that the hard way. Avoided it after that.
>>>
>>> sfdisk was a handy one for saving/restoring the entire partition 
>>> table in
>>> a single command -- particularly in the days before fdisk acquired GPT
>>> support.
>>
>>    Umm ... rec ... if possible use 'gparted' instead.
>>    Takes care of the little stuff.
> 
> That's the tool I use.
> 
> But we also need, for backups, something that can save and reconstruct 
> the partition table, even GPT.

   Not 101% sure gparted can do that perfectly. It CAN
   copy an entire partition somewhere, but never tried
   to have it re-create an entire (gpt or not) partition
   from scratch, there may be 'issues' there. Normally
   had to make a big enough unformatted space and then
   copy the data into it. Then run the needed grub stuff
   to find and index it all so it can boot.

[toc] | [prev] | [next] | [standalone]


#77719

FromThe Natural Philosopher <tnp@invalid.invalid>
Date2025-11-18 12:12 +0000
Message-ID<10fhnqm$1gvnc$7@dont-email.me>
In reply to#77717
On 18/11/2025 08:17, c186282 wrote:
> On 11/18/25 02:46, Carlos E.R. wrote:
>> On 2025-11-18 08:34, c186282 wrote:
>>> On 11/18/25 02:18, Lawrence D’Oliveiro wrote:
>>>> On 18 Nov 2025 16:31:19 +1000, Computer Nerd Kev wrote:
>>>>
>>>>> No fdisk won't do damage instantly when you just run one command from
>>>>> the command line, modifying partitions is done in its interactive 
>>>>> mode.
>>>>> You can't stuff things up just by attempting an "fdisk -l".
>>>>
>>>> I think it was parted I found that made its changes to the disk 
>>>> instantly,
>>>> without requiring an explicit save.
>>>>
>>>> I discovered that the hard way. Avoided it after that.
>>>>
>>>> sfdisk was a handy one for saving/restoring the entire partition 
>>>> table in
>>>> a single command -- particularly in the days before fdisk acquired GPT
>>>> support.
>>>
>>>    Umm ... rec ... if possible use 'gparted' instead.
>>>    Takes care of the little stuff.
>>
>> That's the tool I use.
>>
>> But we also need, for backups, something that can save and reconstruct 
>> the partition table, even GPT.
> 
>    Not 101% sure gparted can do that perfectly. It CAN
>    copy an entire partition somewhere, but never tried
>    to have it re-create an entire (gpt or not) partition
>    from scratch, there may be 'issues' there. Normally
>    had to make a big enough unformatted space and then
>    copy the data into it. Then run the needed grub stuff
>    to find and index it all so it can boot.
> 

dd will dump the entire raw disk structure including partitions and all 
data.

Just feed it to a .iso file to remind you it's an image

-- 
Truth welcomes investigation because truth knows investigation will lead 
to converts. It is deception that uses all the other techniques.

[toc] | [prev] | [next] | [standalone]


#77726

From"Carlos E.R." <robin_listas@es.invalid>
Date2025-11-18 17:53 +0100
Message-ID<vskuulxffm.ln2@Telcontar.valinor>
In reply to#77719
On 2025-11-18 13:12, The Natural Philosopher wrote:
> On 18/11/2025 08:17, c186282 wrote:
>> On 11/18/25 02:46, Carlos E.R. wrote:
>>> On 2025-11-18 08:34, c186282 wrote:
>>>> On 11/18/25 02:18, Lawrence D’Oliveiro wrote:
>>>>> On 18 Nov 2025 16:31:19 +1000, Computer Nerd Kev wrote:
>>>>>
>>>>>> No fdisk won't do damage instantly when you just run one command from
>>>>>> the command line, modifying partitions is done in its interactive 
>>>>>> mode.
>>>>>> You can't stuff things up just by attempting an "fdisk -l".
>>>>>
>>>>> I think it was parted I found that made its changes to the disk 
>>>>> instantly,
>>>>> without requiring an explicit save.
>>>>>
>>>>> I discovered that the hard way. Avoided it after that.
>>>>>
>>>>> sfdisk was a handy one for saving/restoring the entire partition 
>>>>> table in
>>>>> a single command -- particularly in the days before fdisk acquired GPT
>>>>> support.
>>>>
>>>>    Umm ... rec ... if possible use 'gparted' instead.
>>>>    Takes care of the little stuff.
>>>
>>> That's the tool I use.
>>>
>>> But we also need, for backups, something that can save and 
>>> reconstruct the partition table, even GPT.
>>
>>    Not 101% sure gparted can do that perfectly. It CAN
>>    copy an entire partition somewhere, but never tried
>>    to have it re-create an entire (gpt or not) partition
>>    from scratch, there may be 'issues' there. Normally
>>    had to make a big enough unformatted space and then
>>    copy the data into it. Then run the needed grub stuff
>>    to find and index it all so it can boot.
>>
> 
> dd will dump the entire raw disk structure including partitions and all 
> data.

Certainly. But I image each partition separately, and not all, some I do 
rsync the files.

> 
> Just feed it to a .iso file to remind you it's an image

But it is not an iso image. I name them .image or .img


-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]


#77728

FromLawrence D’Oliveiro <ldo@nz.invalid>
Date2025-11-18 19:32 +0000
Message-ID<10fihl2$1p41c$5@dont-email.me>
In reply to#77726
On Tue, 18 Nov 2025 17:53:19 +0100, Carlos E.R. wrote:

> On 2025-11-18 13:12, The Natural Philosopher wrote:
>>
>> Just feed it to a .iso file to remind you it's an image
>
> But it is not an iso image. I name them .image or .img

Same here. ;)

“.iso” was supposed to stand for “ISO-9660”, the standard for the
CD-ROM format. Using it for non-CD-ROM-format images seems ... odd.

Imagine if Microsoft used “.iso” for Office documents. Because, after
all, they are supposed to conform to the “ISO-29500” spec, are they
not?

[toc] | [prev] | [next] | [standalone]


#77720

FromAnssi Saari <anssi.saari@usenet.mail.kapsi.fi>
Date2025-11-18 14:46 +0200
Message-ID<sm0h5ur7bkx.fsf@lakka.kapsi.fi>
In reply to#77709
Lawrence D’Oliveiro <ldo@nz.invalid> writes:

> sfdisk was a handy one for saving/restoring the entire partition table in 
> a single command -- particularly in the days before fdisk acquired GPT 
> support.

Yep. sfdisk save of the partition tables is part of my backup
scripts. Not that I've ever really needed that but a lesson learned from
a friend whose raid-5 array went and part of his nasty recovery included
figuring out what his partition tables had been.

[toc] | [prev] | [next] | [standalone]


Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.os.linux.misc


csiph-web