HowTo: Mounting NTFS partition in write mode on FreeBSD

My brother's old laptop died and I got to keep its hard-drive. Being a Windows machine, it had a bunch of NTFS partitions. So this post explains how to identify a NTFS partition, mount it as read-only and finally learn how to mount it in write mode. I should mention that FreeBSD 7.4 was used but the same steps should apply to latter versions of the OS.

Physically attached the hard-drive (in my case I plugged an USB HDD) and have a look at /var/log/messages to identify the harddrive.

% su

# tail -n 20 /var/log/messages

Jan 26 21:40:03 flumen kernel: da0: Fixed Direct Access SCSI-4 device

Jan 26 21:40:03 flumen kernel: da0: 40.000MB/s transfers

Jan 26 21:40:03 flumen kernel: da0: 114473MB (234441648 512 byte sectors: 255H 63S/T 14593C)

Similar information can be collected from dmesg.

# dmesg

umass0: on uhub4

da0 at umass-sim0 bus 0 target 0 lun 0

da0: Fixed Direct Access SCSI-4 device

da0: 40.000MB/s transfers

da0: 114473MB (234441648 512 byte sectors: 255H 63S/T 14593C)

Let's find out which is the NTFS partition:

# fdisk /dev/da0

******* Working on device /dev/da0 *******

parameters extracted from in-core disklabel are:

cylinders=14593 heads=255 sectors/track=63 (16065 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1

parameters to be used for BIOS calculations are:

cylinders=14593 heads=255 sectors/track=63 (16065 blks/cyl)

Media sector size is 512

Warning: BIOS sector numbering starts with sector 1

Information from DOS bootblock is:

The data for partition 1 is:

sysid 18 (0x12),(Compaq diagnostics)

start 63, size 16611147 (8110 Meg), flag 0

beg: cyl 0/ head 1/ sector 1;

end: cyl 1023/ head 254/ sector 63

The data for partition 2 is:

sysid 7 (0x07),(OS/2 HPFS, NTFS, QNX-2 (16 bit) or Advanced UNIX)

start 16611210, size 117194175 (57223 Meg), flag 80 (active)

beg: cyl 1023/ head 0/ sector 1;

end: cyl 1023/ head 254/ sector 63

The data for partition 3 is:

sysid 15 (0x0f),(Extended DOS (LBA))

start 133805385, size 100631160 (49136 Meg), flag 0

beg: cyl 1023/ head 0/ sector 1;

end: cyl 1023/ head 254/ sector 63

The data for partition 4 is:

Issuing the following command will mount a NTFS partition in read-only mode:

# mount -t ntfs /dev/da0s2 /mnt/

To be able to write into a NTFS partition it is required to install the sysutils/fuse-ntfs port:

# cd /usr/ports/sysutils/fusefs-ntfs/ && make install clean

If you use, as described in the man page, mount -t ntfs-3g an error will occurr:

# mount -t ntfs-3g /dev/da0s2 /mnt/

mount: /dev/da0s2 : Operation not supported by device

To mount the NTFS partition in write mode issue:

# ntfs-3g /dev/da0s2 /mnt/

Let's make sure that the partition is mounted:

#mount

/dev/ad4s1a on / (ufs, local)

devfs on /dev (devfs, local)

/dev/ad4s1e on /tmp (ufs, local, soft-updates)

/dev/ad4s1f on /usr (ufs, local, soft-updates)

/dev/ad4s1d on /var (ufs, local, soft-updates)

/dev/ad5s1d on /mnt/1 (ufs, local, soft-updates)

/dev/fuse0 on /mnt/2 (fusefs, local, synchronous)

man ntfs-3g contains some Linuxisms and as such read the man page with a grain of salt ;)

Tip: Fixing Atheros L2 driver attachment on FreeBSD

My personal server, a low-powered system based on an integrated motherboard ASUS I220GC, is using a D-Link DGE-528 Ethernet PCI card which runs fine on FreeBSD 7.4. However while toying with the system I decided to active the integrated Atheros L2 10/100 Ethernet device that I had disabled a long time ago.

Upon enabling the device on the BIOS and booting the system I came across an odd situation: ae(4) which is Atheros L2 driver wasn't loading properly.

# dmesg | less
Jul 8 22:07:22 flumen kernel: pci2: on pcib2
Jul 8 22:07:22 flumen kernel: pci2: at device 0.0 (no driver attached)

# pciconf -lv
none2@pci0:2:0:0: class=0x020000 card=0x82331043 chip=0x20481969 rev=0xa0 hdr=0x00
vendor = 'Attansic (Now owned by Atheros)'
device = 'Fast Ethernet 10/100 Base-T Controller (Atheros L2)'
class = network
subclass = ethernet

To fix this ae(4) driver has to be loaded and then it will attach himself to the PCI device (pci2 in my system):

# kldload -v if_ae
ae0: mem 0xdffc0000-0xdfffffff irq 17 at device 0.0 on pci2
ae0: Using MSI messages.
miibus1: on ae0
atphy0: PHY 0 on miibus1
atphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ae0: Ethernet address: 00:1f:c6:dd:15:72
ae0: [FILTER]
Loaded if_ae, id=5

By running pciconf(8) we can confirm that the driver is now successfully attached:

# pciconf -lv
ae0@pci0:2:0:0: class=0x020000 card=0x82331043 chip=0x20481969 rev=0xa0 hdr=0x00
vendor = 'Attansic (Now owned by Atheros)'
device = 'Fast Ethernet 10/100 Base-T Controller (Atheros L2)'
class = network
subclass = ethernet

To load the driver as a module at boot time loader.conf(5) needs to be edited.

# echo 'if_ae_load="YES"' >> /boot/loader.conf

Now that the driver attachment at boot is solved rc.conf(5) needs to be edited so that FreeBSD assigns an interface to Atheros L2 device at boot:

# vim /etc/rc.conf
ifconfig_ae0="inet 192.168.1.1 netmask 255.255.255.0"

The next time the system is booted the next settings are applied and Atheros L2 is properly working (make sure you use your own network settings namely netmask and inet).

Sources:
man ae
man ifconfig
man loader.conf
man pciconf
man rc.conf

Tip: Fixing xorg-server 1.7.6 keyboard and mouse issues on Gentoo

I came across a weird issue on my Gentoo box: both keyboard and mouse weren't working. I immediately though of hal and X11...

A quick stroll to the Gentoo Forums pointed to x11-drivers/xf86-input-keyboard, x11-drivers/xf86-input-mouse and x11-drivers/xf86-input-evdev has the culprits!

Here's how to fix the issue:

1. $ su
2. # eix-sync
3. # emerge -1 $(qlist -IC x11-drivers)

This will rebuild X11 drivers in you system and have you using your keyboard and mouse again. If you don't have qlist installed in your system just emerge app-portage/portage-utils.

Now wasn't that fun?

;)

HowTo: Upgrade FreeBSD 7.2 to 7.3

Disclaimer: this post is for those that instead of using FreeBSD's excellent documentation maintain the bad habit of googling for things already covered in the project's official documentation. This is more or less a copy-paste of the FreeBSD 7.3-RELEASE Announcement instructions for upgrading 7.2 to 7.3.

These are needed steps to upgrade, through the binary upgrade method, the kernel and userland utilities to 7.3-RELEASE:

1. % su
2. # freebsd-update upgrade -r 7.3-RELEASE
3. # freebsd-update install
4. # shutdown -r now
   
5. % su
6. # freebsd-update install
7. # shutdown -r now
   

On step 1 we've started of by becoming the superuser. Step 2 initiates the freebsd-update utility pointing the upgrade to 7.3-RELEASE, after that we proceed with the installation of the kernel on step 3.

Upon rebooting the new kernel is enabled and we move into step 6. Here we end the upgrade process by updating the userland utilities.

That's it!

If you found this post useful that's actually a bad news: you aren't reading the project's official documentation! So please point to http://www.freebsd.org and educate yourself on FreeBSD ;)

Tip: Dealing with virtualbox-ose PUEL license on Gentoo

I came across a peculiar message from portage when trying to install virtualbox-ose in Gentoo:

1. $ su
2. # eix-sync
3. # emerge --tree --ask --verbose virtualbox-ose

These are the packages that would be merged, in reverse order:

Calculating dependencies... done!

!!! All ebuilds that could satisfy "~app-emulation/virtualbox-ose-additions-3.1.4" have been masked.
!!! One of the following masked packages is required to complete your request:
- app-emulation/virtualbox-ose-additions-3.1.4 (masked by: PUEL license(s))
A copy of the 'PUEL' license is located at '/usr/portage/licenses/PUEL'.


(dependency required by "app-emulation/virtualbox-ose-3.1.4" [ebuild])
(dependency required by "virtualbox-ose" [argument])

For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.

The solution is to add the PUEL license to the /etc/portage/package.license file:

1. # echo "app-emulation/virtualbox-ose-additions PUEL" >> /etc/portage/package.license
2. # echo "app-emulation/virtualbox-ose PUEL" >> /etc/portage/package.license

Now can finally get to emerge VirtualBox.

As a side note you can also use /etc/make.conf and make use of the ACCEPT_LICENSE variable. For instances adding ACCEPT_LICENSE="*" to /etc/make.conf unmasks all licenses. Alternatively you can unmask licenses one by one.

More information can be obtained reading make.conf and portage's man pages.

Tip: Dealing with nvidia-driver-195.22 on FreeBSD 7.2-RELEASE

I haven't migrated to FreeBSD 8.0 as I came across visual artefacts while running 8.0, nvidia-driver-195.22 and Enemy Territory on a test install.

To update my installed ports I use for the most part csup to update the ports collection and sysutils/portmaster to actually update the ports with new versions.

Recently nvidia-driver-195.22 hit the Ports tree and upon running portmaster -a I found out that Nvidia's latest driver version requires FreeBSD-STABLE or FreeBSD-CURRENT. Guess who's running RELEASE?

Symptoms:

• % su
• # csup -L 2 -h cvsup2.uk.freebsd.org /usr/share/examples/cvsup/ports-supfile
• # portmaster -L

===>>> nvidia-driver-185.18.36
===>>> New version available: nvidia-driver-195.22
===>>> This port is marked IGNORE
===>>> requires fairly recent FreeBSD-STABLE, or FreeBSD-CURRENT

• # portmaster -a

===>>> Launching child to update nvidia-driver-185.18.36 to nvidia-driver-195.22

===>>> Port directory: /usr/ports/x11/nvidia-driver
===>>> This port is marked IGNORE
===>>> requires fairly recent FreeBSD-STABLE, or FreeBSD-CURRENT

===>>> If you are sure you can build it, remove the
IGNORE line in the Makefile and try again.

===>>> Update for nvidia-driver-185.18.36 failed
===>>> Aborting update

Solution:

• # cd /var/db/pkg/nvidia-driver-185.18.36/
• # touch +IGNOREME
• # portmaster -a

===>>> Launching child to update nvidia-driver-185.18.36 to nvidia-driver-195.22

===>>> nvidia-driver-185.18.36 has an +IGNOREME file

===>>> Update anyway? [n]

• answer "n"
  

Now portmaster -a ignores updates to the nvidia-driver port until the issue is fixed or I move to 8.0 ;)

HowTo: Mount EXT2FS partitions with inode 256 on FreeBSD

Mounting ext2/ext3 slices (or "partitions" in the Linux world) is easy on FreeBSD... if the filesystem was NOT created with inode 256 that is!

If you are one of those unlucky bastards this post presents the required steps on how to patch the FreeBSD 7.2 kernel module that mounts ext2/ext3 filesystems.

First let's begin by installing the sysutils/e2fsprogs application that provides tune2fs which will allow us to confirm that the ext2/ext3 filesystem was in fact created with inode 256. Assuming that the target slice is in the /dev/ad4 disk:

• % su
• # cd /usr/ports/sysutils/e2fsprogs
• # make install clean
• # rehash
• # fdisk /dev/ad4

******* Working on device /dev/ad4 *******
parameters extracted from in-core disklabel are:
cylinders=395136 heads=16 sectors/track=63 (1008 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=395136 heads=16 sectors/track=63 (1008 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 131 (0x83),(Linux native)
start 63, size 80262 (39 Meg), flag 80 (active)
beg: cyl 0/ head 1/ sector 1;
end: cyl 4/ head 254/ sector 63
The data for partition 2 is:
sysid 130 (0x82),(Linux swap or Solaris x86)
start 80325, size 1012095 (494 Meg), flag 0
beg: cyl 5/ head 0/ sector 1;
end: cyl 67/ head 254/ sector 63
The data for partition 3 is:
sysid 131 (0x83),(Linux native)
start 1092420, size 10008495 (4886 Meg), flag 0
beg: cyl 68/ head 0/ sector 1;
end: cyl 690/ head 254/ sector 63
The data for partition 4 is:
sysid 15 (0x0f),(Extended DOS (LBA))
start 11100915, size 350907795 (171341 Meg), flag 0
beg: cyl 691/ head 0/ sector 1;
end: cyl 1023/ head 254/ sector 63

• # tune2fs -l /dev/ad4s1 | grep -i 'inode size'

fdisk is used to list the slices that exist on the disk. Sysid 131 means that a ext2/ext3 slice exists and this is target for tune2fs.

Next let's fetch the patch:

• % wget http://pflog.net/~floyd/ext2fs.diff

In alternative, get the patch from here:

• % wget http://pastebin.ca/raw/1280738

Now that we have the patch, let's proceed by applying it and build the patched module:

• # cd /usr/src/sys/gnu/fs
• # patch < /path/to/patch
• # cd /usr/src/sys/modules/ext2fs
• # make depend ; make obj ; make ; make ; make install ; make unload ; make load ; make clean

This way you'll build all dependencies for the module, build the module itself, install it, unload the current loaded module and finally load the new one.

Having the new module loaded you can now successfully mount your ext2/ext3 filesystem:

• # mount -t ext2fs /dev/ad6s1 /mnt

That's it!

References:
kern/124621: [ext3] [patch] Cannot mount ext2fs partition
man mount
sysutils/e2fsprogs