On Thu, May 9, 2024 at 12:27 PM Gregory Galperin <g...@csail.mit.edu> wrote:
> ... > if you run [g]parted and it still shows no partitions, are you sure you > ever had a partition on this drive, rather than having created the > filesystem on the whole drive in the first place? e.g. do you have fstab > entries from this disks's normal system setup that shows it's mounted under > a partition number? > The drive was never in fstab; my usb drives are automounted under /run/media/jabr/ . Yes, I'm sure it had a partition table; when I first set up each of my usb drives, I reformatted the pre-existing NTFS partition with an XFS filesystem. > other indicators: does the filesys start at the very beginning of the > drive, or is it offset (leaving space for a partition table (gpt))? > I just ran od -c on the recovered drive, and again on three of the other drives for comparison. The other three show the text "EFI PART" at 0001000 and "XFSB" at 4000000, whereas the recovered drive shows "XFSB" at 0000000, Looks like xfs_repair, when run on /dev/sdf instead of /dev/sdf1, rebuilt the filesystem over the partition space. So it's too late now to rebuild the partition table. I guess I'll just have to live with it as-is. > it makes me a little suspicious that the tools recognize a valid xfs > filesystem on /dev/sdf -- I'm wondering if that means the filesys > is starting right at the beginning of the disk, no space for a gpt, so > it never had any partitions. > Nothing suspicious about it. By running xfs_repair on the raw disk, it scanned the raw disk to find the xfs metadata with no regard for partitioning. The other three drives show "Disklabel type: gpt", "Units: sectors of 1 * 512 = 512 bytes", and a single partition beginning at 2048. With a block size of 512 bytes, 2048 blocks == 1048576 bytes, and 1048576 in decimal == 4000000 in octal. So that checks. I imagine the drive must have originally shipped with the first partition beginning at 2048, and the earlier EFI stuff was part of some Windows-related cruft from the factory image the drives are initially seeded with. On Thu, May 09, 2024 at 11:11:03AM -0400, John Abreau wrote: > > I just checked with "journalctl -xe" after another unsuccessful attempt > to > > mount the drive, and found a duplicate UUID error. > > > > A quick google search of the error message yielded the solution: I ran > > "sudo xfs_admin -U generate /dev/sdf" > > and was then able to mount /dev/sdf successfully. > > > > I'm not thrilled about mounting sdf instead of sdf1. Is there any way to > > safely reconstruct the partition table based on the info returned by > > xfs_info? > > > > On Wed, May 8, 2024 at 8:40 PM John Abreau <abre...@gmail.com> wrote: > > > > > I have an 18TB external hard drive that recently suffered a loss. When > I > > > first set it up, I formatted it as a single partition with an xfs > > > filesystem. > > > > > > Yesterday I was trying to figure out how to export it via nfs, and > during > > > one of my attempts I used "mount --bind" to mount it under /export. > > > > > > Later, when I was backing out my tests, I found I was unable to unmount > > > the drive because it was apparently still in use by a bash process > that no > > > longer existed. I clicked the "unmount anyway" button, and afterward > > > discovered that the partition was missing from the drive. /dev/sdf > exists, > > > but /dev/sdf1 does not. > > > > > > When I ran fdisk to examine the drive, it gave the following error: > > > > > > Welcome to fdisk (util-linux 2.39.4). > > >> Changes will remain in memory only, until you decide to write them. > > >> Be careful before using the write command. > > > > > > > > > > > >> The device contains 'xfs' signature and it will be removed by a write > > >> command. See fdisk(8) man page and --wipe option for more details. > > > > > > > > > > > >> Device does not contain a recognized partition table. > > >> The size of this disk is 16.4 TiB (18000174383104 bytes). DOS > partition > > >> table format cannot be used on drives for volumes larger than > 2199023255040 > > >> bytes for 512-byte sectors. Use GUID partition table format (GPT). > > > > > > > > > Created a new DOS (MBR) disklabel with disk identifier 0xb9e277e5. > > > > > > > > > I immediately exited fdisk without writing it out. > > > > > > I tried running "xfs_repair -L /dev/sdf", which appears to > > > have successfully repaired the xfs filesystem, but the partition table > > > still has no partitions showing, and the disk still won't mount. > > > > > > "xfs_info /dev/sdf" shows the following: > > > > > > meta-data=/dev/sdf isize=512 agcount=17, > agsize=268435455 > > > blks > > > = sectsz=4096 attr=2, projid32bit=1 > > > = crc=1 finobt=1, sparse=1, > rmapbt=0 > > > = reflink=1 bigtime=0 inobtcount=0 > > > nrext64=0 > > > data = bsize=4096 blocks=4394573824, > imaxpct=5 > > > = sunit=0 swidth=0 blks > > > naming =version 2 bsize=4096 ascii-ci=0, ftype=1 > > > log =internal log bsize=4096 blocks=521728, version=2 > > > = sectsz=4096 sunit=1 blks, > lazy-count=1 > > > realtime =none extsz=4096 blocks=0, rtextents=0 > > > > > > As far as I can tell, the filesystem itself is in good shape, and I > just > > > need to fix the partition table. But I don't know how to do that > without > > > risk of destroying the filesystem. I've had no luck googling a useful > > > answer. > > > > > > How do I fix this? > > > > > > > > > > > > -- > > > John Abreau / Executive Director, Boston Linux & Unix > > > Email: abre...@gmail.com / WWW http://www.abreau.net / PGP-Key-ID > > > 0x920063C6 > > > PGP-Key-Fingerprint A5AD 6BE1 FEFE 8E4F 5C23 C2D0 E885 E17C 9200 63C6 > > > > > > > > > > -- > > John Abreau / Executive Director, Boston Linux & Unix > > Email: abre...@gmail.com / WWW http://www.abreau.net / PGP-Key-ID > 0x920063C6 > > PGP-Key-Fingerprint A5AD 6BE1 FEFE 8E4F 5C23 C2D0 E885 E17C 9200 63C6 > > _______________________________________________ > > Discuss mailing list > > Discuss@driftwood.blu.org > > https://driftwood.blu.org/mailman/listinfo/discuss > -- John Abreau / Executive Director, Boston Linux & Unix Email: abre...@gmail.com / WWW http://www.abreau.net / PGP-Key-ID 0x920063C6 PGP-Key-Fingerprint A5AD 6BE1 FEFE 8E4F 5C23 C2D0 E885 E17C 9200 63C6 _______________________________________________ Discuss mailing list Discuss@driftwood.blu.org https://driftwood.blu.org/mailman/listinfo/discuss
