# FreeBSD-SA-19:10.ufs -> just patching is not enough!



## getopt (Jul 3, 2019)

Do YOU actually read all FreeBSD Security Advisories?

Then you should not only have read this, but acutually did you

*reboot the system and run:* `# fsck -t ufs -f -p -T ufs:-z`

While life experience suggests that most folks got conditioned practicing TL;DR this notice may challenge the habits of those being affected.


----------



## SirDice (Jul 3, 2019)

It's obvious for seasoned FreeBSD users or admins but new users might not know. Filesystems need to be unmounted, or at most mounted read-only, for this command to work. In most cases the simplest way to accomplish this is to boot to single user mode.

If your system uses ZFS you can safely ignore it, it's only for UFS filesystems.


----------



## obsigna (Jul 3, 2019)

SirDice said:


> ... In most cases the simplest way to accomplish this is to boot to single user mode. ...



In cases without physical access to the machine, I stop file, database, web and mail services and force a read-only mount of the root volume:
`# mount -rf /`
`# fsck -t ufs -f -p -T ufs:-z`

Then I mount the volume in normal mode and restart the machine:
`# mount /`
`# shutdown -r now`

This worked out well on a number of AWS-EC2 instances after updating to FreeBSD 12.0-RELEASE-p7 by applying said patches.


----------



## drhowarddrfine (Jul 3, 2019)

I have an old laptop that I never use with 12.0-RELEASE on it. I tried this but didn't mount as read only. Now it only boots into root and the /home directory doesn't contain anything.

Note that I'm not concerned since I don't have anything on it but did not mounting as read-only mess things up?

EDIT: I just had to run fsck again and everything's fine but the question remains.


----------



## obsigna (Jul 3, 2019)

The systems to which I don’t have physical access don’t run a desktop system. Otherwise, I would have stopped the desktop and X as well before mounting the root-fs read-only. That said, for me it is a mystery how something could mess things up to  anything below / once it is read-only.

Anyway, my suggestion worked well for me several times already on remote systems, and specially with AWS-EC2 instances it would be a major fiddling to 1. create another boot volume (in case it does not exist yet), 2. stop the server, 3. detach the production volume from the instance, 4. attach the other boot volume to the instance, 5. attach the production one as the second volume to the instance, 6. launch the instance, 7. login and run fsck, then more 4 steps to reverse everything, 15. login and , let’s have a break.


----------

