XPost: aus.computers   
   From: nospam@needed.invalid   
      
   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   
   I can't think of an easy way (without a lot of bother), of figuring it out.   
      
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)