Root fs mount problems nanobsd amd64



  • 2.0-RC2 (amd64)
    built on Mon Jun 13 20:41:11 EDT 2011
    You are on the latest version.
    Platform nanobsd (1g)

    I'm having a couple problems that may be related.

    This is a fresh install using zcat and dd onto an 8GB USB Corsair Voyager flash drive. When I booted it the first time I got the root fs prompt, which is not unexpected on a first boot. I entered "?" once or more and eventually got it to boot with ufs:/dev/ad0s1a.

    Once pfsense was fully booted I edited /etc/fstab, where the first line looked (IIRC) like this:

    
    /dev/ufs/pfsense / ufs ro,sync,noatime 1 1
    
    

    and I changed it to now look like this:

    
    /dev/da0s1a / ufs ro,sync,noatime 1 1
    
    

    I then restored my config from an amd64 generic install that was running the May 1 snapshot and it rebooted. During the shutdown sequence I saw a message on the console similar to "CF removed before data was finished writing. Expect file corruption". After the reboot I saw on the console a message indicating that the filesystem needed checking, and then some repairs were done automatically.

    Then while booting I got the root fs mount prompt again. When I hit "?" the only device listed, IIRC, was da0. I entered "?" a few more times and saw a limited device list, something like ad0 da0. I entered "ufs:/dev/da0" and got the prompt again. I entered "?" again and saw a few more devices this time, including da0 ad0 ad0s1. I entered "ad0s1" and got the prompt again. "?", now I see ad0s1a among the choices. I entered "ufs:/dev/ad0s1a" and finally pfsense finished booting.

    pfsense has been running fine a little over 6 hours now, but between the fs corruption and the failure to boot unattended, I am nervous. What is the best way to troubleshoot this problem?



  • Bump.

    Best guesses welcome ;)


  • Rebel Alliance Developer Netgate

    In order for NanoBSD to work properly it must use the UFS labels to mount the drive, not the device name.

    Why that isn't working for you is a bit of a mystery, but that is pretty low-level FS metadata, so it's possible that the beginning or the end of the USB stick didn't write like it should have.

    Some others have reported issues updating NanoBSD on USB sticks as well, something about the stick mucks with the size of the slices.



  • Could it be because I installed the 1G image on an 8G device?


  • Rebel Alliance Developer Netgate

    Not likely. It's always safe to use the smaller images on larger devices. At least on CF anyhow.



  • I tried a different USB stick with similar result. I hope the console grab is useful. The first 13 lines contain some overwrite due to a caret reset on reboot, but the rest of the mumbo-jumbo is authentic.

    mount_fail.txt


  • Rebel Alliance Developer Netgate

    It really looks like it's just not properly reading all of the filesystem metadata. It's not even seeing the slices on the disk until you sort of force it to read that.

    I can't say I've seen that behavior before. Are there any BIOS options on that system to tweak USB behavior somehow? Do you have a diferent make/model system to try it on? (Even just another PC to plug it into and boot it up to see if it mounts)



  • I hoped that updating the firmware might fix whatever the issue was, but the updatefailed, stating I was 2 MB short or something typical like that, so I just dumped the USB drive for a CF.

    Too bad, USB drives are so cheap and easy these days compared to buying a faster CF and an adapter, then trying to dig up a floppy power adapter for the CF adapter.


Locked