# Manually mounting .gz UFS images in RW mode



## Seeker (Aug 29, 2011)

*mdoc* is an image containing UFS. Tested via attaching to md0 and then mounting.
Now after being compressed with *gzip*, I attach it:

```
# mdconfig -f /usr/mdoc.gz
md0
```
Now when I try to mount it ...

```
# mount /dev/md0 /tmp/testzone
mount: /dev/md0 : Invalid argument
```

How come kernel and sys during boot, can deal with .gz compressed images (RW mode) and how do they do it?
So I could apply same method, in my _manual mode_?

PS: Don't mention RO compressed images .uzip, as I successfully deal with them in all cases.

Thx in advance_!_


----------



## SirDice (Aug 29, 2011)

As far as I know they can only be mounted read-only.


----------



## Seeker (Aug 29, 2011)

```
# mount -r /dev/md0 /tmp/testzone
mount: /dev/md0 : Invalid argument
```

How does sys at boot does it?


----------



## wblock@ (Aug 29, 2011)

Seeker said:
			
		

> How come kernel and sys during boot, can deal with .gz compressed images (RW mode) and how do they do it?



Where do you see this working?  AFAIK, there are things like mdmfs(8), but it's just unpacking the compressed image to a memory disk.


----------



## Seeker (Aug 29, 2011)

```
# mdmfs -LPF /usr/mdoc.gz md /tmp/testzone
mount: /dev/md0 : Invalid argument
mdmfs: mount exited with error code 1
```
It also successfully attaches image, but mounting to target MP fails, too.

Here I've added -X flag:

```
# mdmfs -XLPF /usr/mdoc.gz md /tmp/testzone
DEBUG: running: /sbin/mdconfig -a -t vnode -f /usr/mdoc.gz
DEBUG: running: /sbin/mount /dev/md0 /tmp/testzone
mount: /dev/md0 : Invalid argument
mdmfs: mount exited with error code 1
```

I see absolutely NO REASON, to use mdmsf for file backed (vnode) md!


----------



## wblock@ (Aug 29, 2011)

Looks like mdmfs(8) doesn't unpack it to an MFS.  Maybe I'm thinking of /etc/rc.d/mdconfig*?  But I'm not aware of there being a RW option for gzip images.


----------



## Seeker (Aug 30, 2011)

Well ..., ok, after having a thought ...
Talking within a context of gzip-ed ...
Loader is doing it!

Loader (stage 3 boot) can decompress kernel from disc and spit it in memory, so it continues to boot!
But NOT if boot2 skips loader, as boot 2 can't decompress, it can only load a 'raw' kernel.

Loader can also decompress md images, which are then RW md.
But writing to md, is writing to memory, so data isn't stored back to gzip-ed image.
So after each reboot, they are RW from initial compressed state.


----------

