ext3 filesystem changed to jmicron_raid_member on its own


A Linode server I have with Virtualmin/Webmin has its main filesystem automatically and on its own change from ext3 to jmicron_raid_member. Because of this, the backups with Linode wont work. The server still works fine (although Webmin is slow as per another thread).

Does anyone know why this could have happened, and more importantly how to change it back?

See this command

[root@mail ~]# blkid
/dev/xvda: TYPE="jmicron_raid_member" 
/dev/xvdb: UUID="b3fda3b3-028c-433b-acc3-9c62cb315036" TYPE="swap"  

ext3 showing up OK with the following:

[root@mail ~]# mount
/dev/xvda on / type ext3 (rw,noatime,grpquota,errors=remount-ro,usrquota)
/proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw,noexec,nodev)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
[root@mail ~]# df -T
Filesystem     Type  1K-blocks     Used Available Use% Mounted on
/dev/xvda      ext3   98760300 32138736  65618104  33% /
tmpfs          tmpfs   2047076      112   2046964   1% /dev/shm
[root@mail ~]# sudo file -sL /dev/xvda
/dev/xvda: Linux rev 1.0 ext3 filesystem data (needs journal recovery) (large files)

The thread is here:


Well, I’m not sure how that may have happened… that certainly sounds odd.

However, with Linode saying that you could fix it by restoring an old backup – perhaps we could use that, along with the Virtualmin backups, to resolve that?

For example, what if you generated a set of Virtualmin backups, and copied them to another server.

Then, restore from an older Linode backup, in order to restore your filesystem.

Finally, copy your Virtualmin backups back, and restore them, in order to get the new data you had on there.

This link was also mentioned in the Linode Forums, but another option is to try this here:


Its an email server, with email coming in all the time, would be a nightmare to migrate to a new server, change IP, then I’d have to manually copy all the new emails since the migration started that are on the old server, if any.

There was no downtime for this to happen, its just happened on its own 5 days ago. Didn’t do anything on the server. So I was really hoping it could be switched back with no downtime.

The other commands show ext3, so cant TYPE output by blkid just be changed, see if it works?

The command on the Ubuntu site I ran is the following, but I get an arror, see below:

[code]sudo dd if=/dev/zero of=/dev/xvda bs=512 seek=$((sudo blockdev --getsz /dev/xvda - 1))[code]

dd: writing `/dev/xvda': No space left on device 2+0 records in 1+0 records out 512 bytes (512 B) copied, 0.000307286 s, 1.7 MB/s

But there is space on the device:

[root@mail ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/xvda 95G 31G 63G 33% / tmpfs 2.0G 112K 2.0G 1% /dev/shm

Just wondered if anyone has any idea about this at all. I cant take backups of my server with this filesystem, and I really dont want to move everything to a new one. My hunch is it cant really be a different filesystem, there was no downtime, I understand you cant just change filesystems like this with no downtime. So I wondered if the issue on the Ubuntu forum is the same, like wrong signature on it, or some sort of wrong label or something somewhere, but I get the above errors when running the commands on the Ubuntu forum thread.

This issue seems to have resolved itself, just like how it appeared. blkid is showing ext3, and backups are working again. I did nothing.