Sstrhsrtj

Somehow I have an ext4 filesystem in /dev/sdb. I expected it to be /dev/sdb1.

I can mount it manually; I can access the data; I can reference it in /etc/fstab; etc, but I want it in a standard partition.

I don't want to lose the data, and there isn't enough room on the drive to duplicate it into another partition. It's not a lot of data: I can always move it to an external device, fix the fs, then move it back, but now I'm curious :)

Is there a method to either remap or move the data into /dev/sdb1 (which, as of now, doesn't exist)?

fdisk gives the following:

$ sudo fdisk /dev/sdb1

fdisk: cannot open /dev/sdb1: No such file or directory



$ sudo fdisk /dev/sdb

Device /dev/sdb already contains a ext4 signature.

The signature will be removed by a write command.



Device does not contain a recognized partition table.

Created a new DOS disklabel with disk identifier 0x4096cdf8.



Command (m for help): p

Disk /dev/sdb: 200GiB, 214748364800 bytes, 419430400 sectors

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disklabel type: dos

Disk identifier: 0x4096cdf8

Yes, this is a very small drive! I'm using Debian Stretch in a VirtualBox vm.

The response to df:

$ df -h

Filesystem Size  Used  Avail  Use%  Mounted on

/dev/sdb   196G  116G   71G    63%  /media/mymountdir

I understand that, as @MarkPlotnick states, I can do this fairly painlessly since I'm in a vm. But I would like to know if there is a cli-based method. Thanks!

You can write an ext4 (or any other) filesystem on a whole disk (instead of a partition), but of course doing so means that there is no partition table; you are using the whole, raw device.

This is possible if you start with a disk with a partition table, and then mistakenly (with the disk info still in memory) format it as ext4, overwriting the partition table (i.e. use mkfs.ext4 /dev/sdb instead of mkfs.ext4 /dev/sdb1). The result is a disk with no valid partition table (it has an ext4 begin block now instead), but the filesystem stores its size independently, so it will still work (this is also done on some external disks). You can mount the device the same as a partition - just use sdb where you would have used sdb1.

What follows is risky as all hell, as you may well imagine. You should already have a backup, and if you don't, get one now. On the other hand if you didn't have a backup, it means that you're not very interested in that data (which was at risk of a hardware failure, a software glitch or, depending on the scenario, spilled coffee, burst pipe, burglary and disasters both natural and unnatural), so if the worst should happen, still it would be no great mischief.

UPDATE: if you have the space somewhere, do the backup, reformat and reinstall. Same exact time as the shifting method, but one hundred percent more data safety. And if you then do not delete the backup copy, you have an update backup image thrown in for free.

First step: resize the ext4 file system so that it's one whole disk cylinder shorter. Get the cylinder size from hdparm since the partition table, well, just isn't there (fdisk will tell you the total number of sectors, not how they're organised). On some external USB drivers, you might need to try reading the disk make and model, and use this to search for information on the Internet. SATA drivers should be OK.

Now that you know by how much, you can resize the file system and shift your whole partition "to the right", towards the end of the disk, thus freeing one cylinder at the beginning, which is where the partition table and start blank space go (I don't exactly know why on LBA disks sdX1 should start one cylinder - or one track - after the partition table, but I never found worthwhile experimenting).

To shift the partition, you can use an exceedingly dangerous buffering strategy or the reverse option to dd_rescue (I seem to have seen some bug report in which this option was said not to work).

You may want to experiment with a largish file - say one gigabyte - to see whether the two options work; shift the content so that it moves data sixteen megabytes from the beginning inside the file, leaving the file size the same; then inspect the contents to verify this is what happened. Afterwards, repeat with /dev/sdb and the appropriate offsets.

After that, use fdisk to re-create the partition table.

Good luck!

If you created the filesystem on the actual block device, as it appears you have, fdisk will not be your friend until your data have been moved elsewhere. You will have to mount the filesystem, copy out the data, and then unmount it. You can then use fdisk to properly partition the block device, use mkfs on the partition, mount it, and move your data back:

$ sudo -s

# mkdir -p /mnt/export

# mount /dev/sdb /mnt/export

# exit

$ rsync -a /mnt/export/ /path/to/backup/

$ sudo -s

# umount /mnt/export

# fdisk /dev/sdb  # create your partitions

# mount /dev/sdb1 /mnt/export

# exit

$ rsync -za /path/to/backup/ /mnt/export/

For a virtual machine what you have already is not an unreasonable configuration. It allows for more disk to be added very easily to your system.

Consider the method if you have a partition table:

• Administrator grows the disk allocation for your VM


• You rescan the virtual disk or reboot your VM


• You delete the partition entry and recreate it at the new larger size


• You resize your filesystem

The third step - the fiddly one - can be omitted if your filesystem is directly in the disk without a partition table.