0

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!

  • what does df -h say? – Rui F Ribeiro Feb 13 '18 at 21:36
  • 2
    if it is very small drive, you better mount /dev/sdb, backup your files, then create mbr and paftition, format it and copy files back. You will save your time – Serge Feb 13 '18 at 21:36
  • otherwise, you need to resize fs on /dev/sdb to make a room for the mbr and reserve space, then copy the data forward chunk by chunk starting from the end of device, then create mbr and partition. – Serge Feb 13 '18 at 21:39
  • If you're in a VM, you only need to copy the data once (assuming you have space on your host). Create a new virtual disk, partition and mkfs, copy the data, then reconfigure your VM so the new disk is in the same position as the old disk (second drive on first controller or whatever). – Mark Plotnick Feb 13 '18 at 21:40
  • @RuiFRibeiro Thanks, I've updated my question with df. – bitsmack Feb 13 '18 at 21:40
3

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!

  • This is just the type of info I was looking for. Thank you! – bitsmack Feb 13 '18 at 21:58
  • 2
    In case I forgot to mention it, the whole procedure is dangerous. Also, it is dangerous. I wouldn't be comfortable doing it, and I'm not completely comfortable in enabling you doing it. I would feel much better if you told me you have backups :-) – LSerni Feb 13 '18 at 22:07
  • Hah! LSerni, you are awesome! Yes, I have a backup. I appreciate your info, and your concern :) I will likely simply rebuild the drive and restore the data, but I'm using this as a learning experience. – bitsmack Feb 13 '18 at 22:13
  • +1. but some notes: 1. any block device can be formatted as ext4 (or other filesystem). "block device" is a generic term that includes both whole disks and partitions (and loopback files. and zfs zvols. and ...) 2. i wouldn't bother figuring out the cylinder size, I'd just move the data 2048 sectors...that will cause the partition to be correctly aligned no matter whether the sector size is 512 bytes or 4 Kbytes. 3. and to re-emphasise what you've already said: this is dangerous - backup, partition, format and restore is better. – cas Feb 13 '18 at 23:40
1

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/
  • 2
    +1. A tar backup might be more appropriate than rsync here. tar.gz (or .bzip2 or .xz) will be faster and take less disk space than rsync. OTOH, rsync can be interrupted and restarted as re-needed, which can be very useful. Also, unless all files/dirs are owned by & readable by the user (and if it's OK that they will all end up owned by the user after restore), this should all be done as root (including the rsync or tar backup & restore). – cas Feb 13 '18 at 23:47
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.