Mount /dev/ad6s1a /mnt/a : operation not permitted

Hi all,

I'm still getting to grips with FreeBSD and this time rather than just reinstalling the OS after a botched upgrade, I'm trying to restore from dumps. I'm following @wblock's guide on his site, but Ubuntu (where my dumps lie) doesn't have gzcat installed. I figured I could just restore locally though, so after copying the dumps to my home dir I put in the livefs cd and attempted to mount the filesystems. However, as the thread title describes, I'm unable to mount the root partition.

Please could somebody help me troubleshoot?
 
Last edited by a moderator:
SirDice said:
I'm guessing the filesystem is "dirty". Run fsck(8) on it first.

Thanks for the swift response!

I couldn't run it in the livefs as it checks the fstab so I had to run it in my broken system. It seemed to run through fine, no errors. However, restarting the laptop the screen output goes crazy. Apparently, it is syncing buffers. There were a stream of 1's which timed out, then the screen started to spit a load of numbers out, which end in a dump failed message. The laptop then reboots, and after I try mounting root again, the same operation not permitted message appears again.

fsck /dev/ad6s1a

This is how I run fsck, am I running it correctly?
 
andyzammy said:
# fsck /dev/ad6s1a

This is how i run fsck, am I running it correctly?
That should be good, but the filesystem doesn't have to be in /etc/fstab for this to work. You can do this on any filesystem.

The reason it's still dirty is probably because your machine appears to crash when it shuts down. It probably crashes before it had a chance to mark the filesystems "clean".
 
wblock@ said:
If given a /dev[/file path, fsck(8) doesn't care about /etc/fstab.
# fsck -y /dev/ad0s1f

The second part of your post describes a panic.


Excuse the lack of format to my posts in this thread, on my ipad. Will correct when I can.

This is the output after running: fsck -y /dev/ad6s1a on the livefs

Code:
fstab: /etc/fstab:0: No such file or directory
fstab: /etc/fstab:0: No such file or directory
fsck: Could not determine filesystem type

So running fsck doesn't work on livefs or on the system.

Thanks for the help so far.
 
SirDice said:
That should be good, but the filesystem doesn't have to be in /etc/fstab for this to work. You can do this on any filesystem.

The reason it's still dirty is probably because your machine appears to crash when it shuts down. It probably crashes before it had a chance to mark the filesystems "clean".

I see. I guess that it's a reinstall job after all then.
 
andyzammy said:
This is the output after running: fsck -y /dev/ad6s1a on the livefs

Code:
fstab: /etc/fstab:0: No such file or directory
fstab: /etc/fstab:0: No such file or directory
fsck: Could not determine filesystem type

So running fsck doesnt work on livefs or on the system.
Nah, the "No such file or directory" messages are mostly warnings. The real error is the last one, fsck(8) doesn't seem to recognize the filesystem. The a partition usually isn't that important, it normally only contains /.

If you're looking for your data, that's probably in the f partition, which usually contains /usr/.
 
SirDice said:
Nah, the "No such file or directory" messages are mostly warnings. The real error is the last one, fsck(8) doesn't seem to recognize the filesystem. The a partition usually isn't that important, it normally only contains /.

If you're looking for your data, that's probably in the f partition, which usually contains /usr/.

My usr file system is in e.

A /
B swap
C (whole of ad6s1 according to handbook but not listed)
D /var
E /usr

What I'm actually trying to do is mount everything so I can restore FreeBSD to its last working state. I guess the only things in / I have to recreate are rc.conf, loader.conf and wpa_supplicant. But this current "dirty" / is part of a stable image, while the dump is of a release image. Is it still possible for me to restore my release dumps (at least /var and /usr) and recreate /?
 
andyzammy said:
What I'm actually trying to do is mount everything so I can restore freebsd to it's last working state. I guess the only things in / i have to recreate are rc.conf, loader.conf and wpa_supplicant... But this current "dirty" / is part of a stable image, while the dump is of a release image. Is it still possible for me to restore my release dumps (at least var and usr) and recreate /?
I'd probably just do a clean install and use a scratch disk to dump the backups. From that scratch disk you can copy what you need. But I'd only copy the data, no binaries.
 
When fsck can't figure out the filesystem type automatically, just tell it the type:
# fsck -t ufs /dev/ad6s1a

Remember, when in doubt, always check the man page: fsck(8)
 
I don't understand this, but after about an hour of trying to mount it, root finally mounted. From what SirDice is saying I guess the file system successfully had the clean flag written to it.

During the restoring I got some "not permitted" type errors on certain files or folders. I didn't understand this as I thought dump and restore worked below the file level. Attempting to restore /var failed at extracting the gz because / was full even though it wasn't. Instead of trying to work it out I lost patience and reinstalled. An afterthought guess is that it (at least root partition restore) was a chflags thing?

Thanks for all the help, always learning!
 
phoenix said:
When fsck can't figure out the filesystem type automatically, just tell it the type:
# fsck -t ufs /dev/ad6s1a

Remember, when in doubt, always check the man page: fsck(8)

I did indeed wonder whether you could pass the file system like that, and of course I consulted the man page. I must say every time I read a man page I'm left wondering about my own competence with the English language and common sense. I got the impression from the fstype description that passing the type wouldn't just make fsck assume that the file system is whatever argument is passed by -t, but that it would still check that it is. Since that particular error stated clearly that it couldn't check, I didn't bother. I guess I should've at least tried it though.
 
andyzammy said:
During the restoring i got some "not permitted" type errors on certain files or folders. I didn't understand this as i thought dump and restore worked below the file level. Attempting to restore var failed at extracting the gz because / was full even though it wasnt. Instead of trying to work it out I lost patience and reinstalled. An afterthought guess is that it (at least root partition restore) was a chflags thing?

dump(8)/restore(8) deal specifically with filesystems. restore creates directories and writes files. If there are already files in the target directory, they can interfere. As you noticed, the schg flag can prevent writing the new files over the old ones.
 
Back
Top