XPost: aus.computers   
   From: none@not.here   
      
   Paul wrote:   
   > On Wed, 12/31/2025 12:37 AM, Axel wrote:   
   >> Paul wrote:   
   >>> On Tue, 12/30/2025 2:31 AM, Axel wrote:   
   >>>> I wanted to clone my 500 Gb LM nvme disk to a 500 Gb mechanical drive,   
   but Rescuezilla reports that the target disk is too small. ??   
   >>>>   
   >>>> https://auslink.info/linux/rz.jpg   
   >>>>   
   >>>> I also get that message when trying to create an image.   
   >>>>   
   >>>> Foxclone also reports that the disk is too small.   
   >>>>   
   >>>> https://auslink.info/linux/foxclone.jpg   
   >>>>   
   >>>> How come? thanks,   
   >>>>   
   >>> First, I will post some of Pauls Demo Hardware, and put the numbers close   
   to yours.   
   >>> These are total disk sizes. I only own one NVMe, just for demos like this.   
   >>>   
   >>> WD5003ABYZ-011FA0                500,107,862,016  contains   
   /dev/sdb? partitions   
   >>> Samsung 970 EVO Plus 500GB       500,107,862,016  contains   
   /dev/nvme0n1p? partitions   
   >>>   
   >>> ******* Begin Felix details   
   >>>   
   >>> Final partition  /dev/nvme0n1p2  500,106,788,864    <<=== a partition   
   "envelope" problem???   
   >>> Destination drive                500,106,780,160  <<===   
   too small ? Need to show me the details...   
   >> does a disks byte capacity depend on what brand/type it is? I had just   
   assumed all 500 Gb drives are the same size   
   > Normally they are the same size. That's why my "spider sense" has been set   
   off.   
   > Reasons for the drive to not be the right size include:   
   >   
   > 1) HPA (Host Protected Area) or DCO. While Host Protected Area could be the   
   issue,   
   >     it is unlikely to be the case. It's hard work to set an HPA. I had to   
   use a   
   >     JMicron controller and firmware, just to have a firmware that was "sloppy   
   >     enough to allow it to happen". I clipped down two SATA drives, to only   
   6GB and 4GB   
   >     capacity, for some RAID testing, then un-clipped them when finished.   
   >   
   > 2) RAID-ready driver has RAID metadata at the end of the drive and the   
   "claimed"   
   >     capacity is lowered by the driver so that there is no possibility of the   
   user   
   >     overwriting the drive. For example, if right now, you're on an Intel   
   SATA port,   
   >     you could connect the drive to an Asmedia port, the driver situation   
   would be   
   >     different and the "whole" drive capacity would show up at that point.   
   >   
   > 3) Other kinds of metadata on a disk might be Veritas "Dynamic Disk", a   
   Windows feature.   
   >     I don't know whether other softwares will readily stomp on Veritas DD.   
   They should.   
   >     Linux may not read Veritas, but I don't see a reason it cannot be   
   stomped.   
   >>> *******   
   >>>   
   >>> This just shows you how you can get a text printout of   
   >>> your storage devices and precise byte values for the items.   
   >>>   
   >>>      sudo apt install disktype   
   >>>   
   >>>      sudo disktype /dev/sda       # dumps some info for my SATA   
   drive   
   >>>      sudo disktype /dev/nvme0n1   # dumps some info for my NVMe drive   
   >>>   
   >>> bullwinkle@FLOTILLA:~$ sudo disktype /dev/nvme0n1   
   >>>   
   >>> --- /dev/nvme0n1   
   >>> Block device, size 465.8 GiB (500107862016 bytes)        
   Â Â Â Â Â Â Â  <=== total drive size here   
   >>>   
   >>> bullwinkle@FLOTILLA:~$ sudo disktype /dev/sdb   
   >>>   
   >>> --- /dev/sdb   
   >>> Block device, size 465.8 GiB (500107862016 bytes)        
   Â Â Â Â Â Â Â  <=== total drive size here   
   >>> bullwinkle@FLOTILLA:~$   
   >>>   
   >>> *******   
   >>>   
   >>> Try and dump your storage info that way.   
   >>>   
   >>> And without making changes right away, you can do   
   >>>   
   >>>      gparted                    # See if you got one   
   >>>   
   >>>      sudo apt install gparted   # If it needs to be installed   
   >>>   
   >>>      sudo gparted               # Menu driven, select   
   drive, check for notations   
   >>>                                 # or little   
   pimples off to the side with respect to   
   >>>                                 # something.   
   Hold your mouse-over for details.   
   >>>   
   >>> You don't need to do anything with the tool right away, but just   
   >>> check to see if gparted is unhappy with the kibble you feed it.   
   >> https://auslink.info/linux/gparted.png   
   > Nothing there looks out of place.   
   >   
   >>> You should still post your "disktype" output so we can   
   >>> see what's going on. If you don't want to display the partition   
   >>> names, just type something meaningful over them with a name that   
   >>> indicates an OS or a name that indicates DATA.   
   >> Ok, here tis..   
   >>   
   >> --- /dev/nvme0n1   
   >> Block device, size 465.8 GiB (500107862016 bytes)               <=== Good   
   so far   
   >> DOS/MBR partition map   
   >> Partition 1: 465.8 GiB (500107861504 bytes, 976773167 sectors from 1)   
   >>    Type 0xEE (EFI GPT protective)   
   >> GPT partition map, 128 entries   
   >>    Disk size 465.8 GiB (500107862016 bytes, 976773168 sectors)   
   >>    Disk GUID 022A380C-20EF-3F45-90AC-B2BF6F79825A   
   >> Partition 1: 512 MiB (536870912 bytes, 1048576 sectors from 2048)   
   >>    Type EFI System (FAT) (GUID 28732AC1-1FF8-D211-BA4B-00A0C93EC93B)   
   >>    Partition Name "EFI System Partition"   
   >>    Partition GUID B0519F73-B580-B74D-B9B0-3D02E3EB44F8   
   >>    FAT32 file system (hints score 5 of 5)   
   >>      Volume size 511.0 MiB (535805952 bytes, 130812 clusters of 4 KiB)   
   >>      Volume name "TEAM GROUP"   
   >> Partition 2: 465.3 GiB (499568869376 bytes, 975720448 sectors from 1050624)   
   >>    Type Unknown (GUID AF3DC60F-8384-7247-8E79-3D69D8477DE4)   
   >>    Partition Name ""   
   >>    Partition GUID 30CA674A-C9EF-4448-868E-9A60A263EA11   
   >>    Ext4 file system   
   >>      UUID 250D0C59-575A-4D9B-A411-74900FD591EF (DCE, v4)   
   >>      Last mounted at "/"   
   >>      Volume size 465.3 GiB (499568869376 bytes, 121965056 blocks of 4   
   KiB)   
   >> Partition 3: unused   
   >>   
   >> The 500Gb drive is unformatted.   
   >> --- /dev/sdh   
   >> Block device, size 465.8 GiB (500106780160 bytes)   
   >>   
   >> did you need it formatted?   
   > No, it's not a "formatting" problem. A Secure erase (marginal probability)   
   > might fix it, but it is a bitch to get one of those to run at the best of   
   times.   
   >   
   > The difference in byte count is 1,081,856 bytes or 2113 sectors.   
   > 2048 + 65 sectors. There is no 3 or 7 factor in there, so it is unlikely   
   > to be a CHS-induced problem.   
   >   
   > $ factor 1081856   
   > 1081856: 2 2 2 2 2 2 2 2 2 2113   
   >           \----- 512 -----/   
   >   
   > $ factor 500107862016   
   > 500107862016: 2 2 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3 7 67 1607   Disk capacity is   
   "faked" at the factory.   
   >                                              \---/           CHS artifact,   
   is to be expected. Divisible by 63.   
   > $ factor 500106780160   
   > 500106780160: 2 2 2 2 2 2 2 2 2 5 13 15027247  This is NOT a factory pattern,   
   >                                                 we are a hostage of   
   something...   
   >   
   > I checked with CoPilot llm-AI and this is the instructions I got   
   > for illuminating the destination drive characteristic. Mainly because   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)