aoetools mount problem during boot after upgrade to server 10.04

Bug #575053 reported by mysteron
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
mountall (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: mountall

After upgrade from server 9.10 to server 10.04, previously working mount of Coraid SR1521 Etherdrive is causing server wait for user input (press S to skip, or M ...). The message shown is that the drive is not ready and not possible to mount to its mount point /mnt/coraid.

Pressing S skips mounting, but after loging into system the etherdrive is active and mounted.

/etc/fstab setting for mount:

/dev/etherd/e1.1 /mnt/coraid ext4 rw 0 0

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in mountall (Ubuntu):
status: New → Confirmed
Revision history for this message
Stephan Fabel (sfabel) wrote :

I have the same issue except that the coraid device isn't being mounted after pressing 'S'.

Revision history for this message
mysteron (pro-green-european) wrote : Re: [Bug 575053] Re: aoetools mount problem during boot after upgrade to server 10.04

I put an option _netdev in /etc/fstab, then the problems of mounting the coraid system was solved.

On Wed Sep 21st, 2011 1:53 AM EEST Stephan Fabel wrote:

>I have the same issue except that the coraid device isn't being mounted
>after pressing 'S'.
>
>--
>You received this bug notification because you are subscribed to the bug
>report.
>https://bugs.launchpad.net/bugs/575053
>
>Title:
> aoetools mount problem during boot after upgrade to server 10.04
>
>Status in “mountall” package in Ubuntu:
> Confirmed
>
>Bug description:
> Binary package hint: mountall
>
> After upgrade from server 9.10 to server 10.04, previously working
> mount of Coraid SR1521 Etherdrive is causing server wait for user
> input (press S to skip, or M ...). The message shown is that the drive
> is not ready and not possible to mount to its mount point /mnt/coraid.
>
> Pressing S skips mounting, but after loging into system the etherdrive
> is active and mounted.
>
> /etc/fstab setting for mount:
>
> /dev/etherd/e1.1 /mnt/coraid ext4 rw 0 0
>
>To manage notifications about this bug go to:
>https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/575053/+subscriptions

Revision history for this message
Steve Langasek (vorlon) wrote :

> I put an option _netdev in /etc/fstab, then the problems of mounting the coraid system was solved.

That's the correct solution here. Since the filesystem type doesn't identify this as a network device, you need to pass this option explicitly to let mountall know to retry the mount when the network comes up.

Changed in mountall (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
Stephan Fabel (sfabel) wrote :

Unfortunately, that does NOT work with 10.04. I have the _netdev set in /etc/fstab, and it will still present me with the options to skip or manually mount.

Changed in mountall (Ubuntu):
status: Invalid → Confirmed
Revision history for this message
Steve Langasek (vorlon) wrote :

> I have the _netdev set in /etc/fstab, and it will still present me
> with the options to skip or manually mount.

And how is your network configured, and what is the mount point for your aoetools device?

If your network is configured correctly (i.e., without a dependency loop), and your filesystem is marked _netdev, mountall will retry the mount as soon as the network comes up. But it's possible this is too early, and aoetools itself needs to give mountall a second push.

Changed in mountall (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Stephan Fabel (sfabel) wrote :

From /etc/fstab:

# CORAID STORAGE
/dev/etherd/e64.1 /mnt/storage ext4 defaults,_netdev,nobarrier 0 0
/dev/etherd/e64.2 /srv/backup xfs defaults,_netdev,nobarrier 0 0
/dev/etherd/e64.3 /srv/coefiles xfs defaults,_netdev,nobarrier 0 0

/etc/defaults/aoetools only specifies eth1 as the interface, nothing else.

/etc/network/interfaces looks like this for eth1:

auto eth1
iface eth1 inet manual
      pre-up ifconfig $IFACE up
      post-down ifconfig $IFACE down

Revision history for this message
Steve Langasek (vorlon) wrote :

> auto eth1
> iface eth1 inet manual
> pre-up ifconfig $IFACE up
> post-down ifconfig $IFACE down

It's possible there's an issue here with manual interfaces not correctly triggering the upstart events. Could you try booting with --verbose, and check whether you see a record of 'net-device-up (eth1)' and 'mountall-net' events in your syslog?

Revision history for this message
Stephan Fabel (sfabel) wrote :

We're in the middle of a long copy process right now. I will get back to you as soon as we've completed this and I can reboot.

Thanks for your help.

Revision history for this message
Stephan Fabel (sfabel) wrote :

Steve,

thanks for your patience. I rebooted and found the following error in our boot.log:

mount: unknown filesystem type 'xfs'

I've attached the boot.log file for your reference.

Thanks

Revision history for this message
Steve Langasek (vorlon) wrote :

Stephan, thanks for following up.

> mount: unknown filesystem type 'xfs'

Ok, certainly not a bug in mountall or aoetools then! Sounds like you just need to add xfs support to your kernel...

Changed in mountall (Ubuntu):
status: Incomplete → Invalid
Revision history for this message
Stephan Fabel (sfabel) wrote :

well, I have XFS support in my initram:

 gunzip -c /boot/initrd.img-$(uname -r) | cpio -t | grep xfs

gives a result. Do I need to add it to /etc/modules as well?

Changed in mountall (Ubuntu):
status: Invalid → Incomplete
Revision history for this message
Steve Langasek (vorlon) wrote :

> well, I have XFS support in my initram:
> gunzip -c /boot/initrd.img-$(uname -r) | cpio -t | grep xfs
> gives a result. Do I need to add it to /etc/modules as well?

It shouldn't need to be added to /etc/modules. The module, if present, should be loaded automatically when the mount command runs after switching to the rootfs (so having it in the initramfs also doesn't matter). So I don't know why this isn't working for you.

Regardless, however, the issue you describe is not the issue that this bug was opened about, and is not a bug in the mountall package, so I'm again closing this bug report.

Changed in mountall (Ubuntu):
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.