We are looking at temporarily mounting an external hard disk on USB to an ESX1 v4 server from VMware. In /var/log/messages, we see the messages of the device being connected, but we cannot figure out the actual name of the device (/dev/???) to actually mount so we can retrieve the files ?
How to find usb storage devices on esxi server
devicefilesusbvmware-esx
Related Solutions
Regarding the bootmanager: when using FAT as filesystem then syslinux would be one approach. Especially when booting from USB you might consider using grub for booting, as you'll be flexible with the grub shell (providing a nice tab-completion). To install grub you'd be running something like:
mount /dev/sdX /mnt/
grub-install --recheck --no-floppy --root-directory=/mnt /dev/sdX
and adjust /boot/grub/menu.lst accordingly.
Your bootloader has to load kernel and initrd. So those files have to be outside your debianroot.img (unless you're using the ISO approach and grub2 with its loopback option, see http://michael-prokop.at/blog/2009/05/25/boot-an-iso-via-grub2/) and need to be referenced/configured in your bootloader (being syslinux.cfg for syslinux, menu.lst for grub1 and grub.cfg for grub2). The following is an example menu.lst file used for the grml live system (http://grml.org/) generated by grml2usb (http://grml.org/grml2usb/):
# misc options:
timeout 30
splashimage=(hd0,0)/boot/grub/splash.xpm.gz
foreground = 000000
background = FFCC33
title grml - Default boot (using 1024x768 framebuffer)
kernel (hd0,0)/boot/release/grml/linux26 apm=power-off vga=791 quiet boot=live nomce live-media-path=/live/grml/
initrd (hd0,0)/boot/release/grml/initrd.gz
The initrd file has to locate the debianroot.img on your devices and loopback mount it then. Then it should change your root file system via e.g. pivot_root (see http://linux.die.net/man/8/pivot_root) to inside the mounted loopback file. You can find more details regarding the initrd process in Documentation/initrd.txt of the linux kernel sources: http://lxr.linux.no/linux/Documentation/initrd.txt
If you'd like to know how common live systems do this kind of stuff check out debian-live (http://debian-live.alioth.debian.org/) or grml-live (http://grml.org/grml-live/) in combination with live-initramfs (which does all the initrd/initramfs magic and is used in most Debian based live systems; http://packages.debian.org/sid/live-initramfs).
A different approach to your debianroot.img approach would be talking an existing Debian based Linux Live system providing so called "root persistency" (for example the official Debian-live project provides this as well as grml 2009.05 does).
There are many things that seem wrong with your configuration.
It doesn't make sense to put USB drives in fstab. Fstab is a mostly static listing of system storage devices and their mount points. You assign a static drive/partition identification (based on controller/device address) to a static mount point. Neither of these are really static for USB drives. In your first example, you'd have problems if you install a second hard-disk to the system: it would become /dev/sdb, moving your current USB drive to /dev/sdc, thus breaking your configuration at boot time.
Also, having your drive in fstab and with "auto" option tells the system that the drive is to be mounted at boot time. If for any reason the drive is disconnected at boot time, you'll have your server failing at the boot procedure, which is a really undesirable situation. If the drive is not essential for the system to function, it at least should not have the "auto" option.
The "nouser" option is unnecessary, it is the default. The "sync" option is a really bad idea unless you really know what you are doing. Not only it severely impacts performance, it also causes additional wearing of the drive, specially flash media.
fs_passno = 3 (sixth column of fstab) causes undefined behavior. Valid values are 0, 1 or 2 only.
Using NTFS with a drive intended for backup of a Linux server. Why are you doing that? All Linux NTFS implementations are suboptimal, and inadequate to run any Linux subsystem upon. You should use a native Linux filesystem, like Ext3.
From your kernel log, I could predict that one or more of these may be valid:
You have a malpartitioned disk, i.e. the filesystem was formatted with the wrong parameters, bigger than the actual partition; or the partition in the partition table (the logical size) is bigger than the physical size of the drive. This is from the "Buffer I/O errors" you are seeing. You should consider resetting this disk completely, including the partition table, and repartitioning and reformatting it from scratch.
You have a bad sector in your disk ("end_request: I/O errors"). You should consider running
badblocks
over the disk to check.Your USB enclosure is not functioning properly (from "usb resets"). If it is an external hard drive, it should use an independent power supply. The 5V 500mA that is (sometimes) available from the USB port is not enough to keep the mechanics of a hard drive running. It may also be overheating, specially cheap USB flash drives.
The NTFS filesystem is corrupted. Fixing it may be possible with
ntfsfix
, but you should remember, again, that NTFS is not a native Linux filesystem. For best results, you'd need a Windows system to properly check this partition (using Scandisk).
Other suggestions include: stop using NTFS and choose a native Linux filesystem, remove that entry from fstab, manually mount the disk as part of the backup script, umounting it after finished and use UUID or filesystem labels to refer to the disk.
Related Topic
- SpinRite and USB blues – does a solution exist
- VMware ESX – Mounting ISO Image on Guest OS Without VMware Client
- Linux – How to disable hiddev96 in linux (or tell it to ignore a specific device)
- Linux console – programmatical detection of which device a USB storage is assigned to
- Linux – Access filesystem underneath another mounted filesystem
- Linux – detect specific device is USB / SATA apart from dmesg output
- How to retrieve a directory (folder) from Ubuntu Server 14.04 VM without FTP, SCP, or NFS
Best Answer
This is possible to do but no simple task unless you have a server that supports passthrough for USB http://vstorage.wordpress.com/2010/07/15/usb-passthrough-in-vsphere-4-1/
Any easier approach may be to hook the USB up to a Windows Desktop and transfer the files via SCP, after enabling file transfer in the ESXi Console using a program such as http://www.veeam.com/vmware-esxi-fastscp.html
or VSphere, File transfer will work if you don't want to "hack" esxi