[RESOLVED]Auto mount USB drive

[Mazdaspeed6]

I running into a problem where when i plug my usb HDD into the P21 it doesnt mount it like it used too. If i boot the device up with it plugged in it wont boot at all. Im thinking its trying to boot to that instead of the usb thumbdrive that the OS is on. But i dont know why it wont detect and mount it when i plug it in while its booted up.
And now im trying to run pacman -Syy and it errors saying no address record.

[WarheadsSE]

check /etc/resolve.conf for the no address on record issue,

as for the drive, check it's filesystem, and `dmesg | tail` after inserting it. Logs are there for a reason after all.

[Mazdaspeed6]

I was able fix the auto mounting for now, But it still wont boot if i have it plugged in. I have t unplug it before i reboot and then wait for SSH then plug it in otherwise it will never boot.

[WarheadsSE]

Then what you have is that drive initializing faster than the other :/ This is an annoying bug that we have with the OXNAS, because I am limited in what I can squeeze into the NAND.

[Mazdaspeed6]

$this->bbcode_second_pass_quote('WarheadsSE', 'T')hen what you have is that drive initializing faster than the other :/ This is an annoying bug that we have with the OXNAS, because I am limited in what I can squeeze into the NAND.

[WarheadsSE]

try changing the order around, so that the one you want to boot is in the USB port nearest the ethernet, but again, there is no way to control the amount of time a drive takes to initialize, so it's pretty much no way around it at this time but we are working on a method to smooth all of this. kexec is being a pain.

[slycat]

I had a usb hdd start up faster than a usb flash, so when I had my rootfs on the flash, I would have to reboot with the hdd unplugged. As for the right timing, I had the led turn orange to notify when the rootfs was loaded, then have a 10s delay before trying to mount the hdd as so I can plug it in. After that a green led would mean success.

For ex: my old rc.local (before having moved everything to my faster hdd)
$this->bbcode_second_pass_code('', '##FIRST read on how to change the led color with proled (courtesy: WarheadsSE)
insmod /lib/modules/2.6.31.6_SMP_820/kernel/xce.ko
rmmod /lib/modules/2.6.31.6_SMP_820/kernel/xce.ko
bash proled orange
sleep 10
mount /dev/sdb1 /media/storage
bash proled green')

Super basic, but it worked for when I had the same problem. Just double-check that the rm/ins(mod) are still needed since there have been changes to the proled function that I haven't really caught up on, but my plug currently does the same process to change colors
$this->bbcode_second_pass_code('', '#my rc.local
insmod /lib/modules/2.6.31.6_SMP_820/kernel/xce.ko
rmmod /lib/modules/2.6.31.6_SMP_820/kernel/xce.ko
bash proled orange
swapon /dev/sda3
sleep 5
mount /dev/sda2 /media/Harddrive
sleep 10
#kill $(pidof udevd)
#sleep 3
#udevd &
rmmod usblp
sleep 3
/etc/rc.d/transmissiond start
sleep 5
/etc/rc.d/cupsd start
sleep 5
/etc/rc.d/samba start
sleep 5
#/etc/rc.d/minidlna start
bash proled green
pacman -Rs $(pacman -Qqtd)')
It now tells me once everything is completely up and running, though no error detection, just simple step-by-step functions.

[Mazdaspeed6]

Moving the USB drive with rootfs to the nearest port to the NIC seems to have worked at least the first few times i rebooted so i think im good to go, Thanks!

[sethjvm]

I think I am having a similar issue to the original poster. When I issue the reboot command, my Pogoplug Pro reboots to a flashing green light and does not appear on the network. The only way I can get it on the network it to physically unplug the Pogoplug Pro, wait a few minutes and then plug it back in. Is this "normal" behavior or is there some way to fix it so I can reboot and rejoin the network without unplugging it?

I set my USB stick up as root using UUID in fstab. I have installed udev-automount (I think this is the culprit.) I am also trying to use LVM to manage my USB hard drives as well.

Here's the result of fdisk -l:
$this->bbcode_second_pass_code('', '[seth@alarm ~]$ sudo fdisk -l
Disk /dev/sda: 2003 MB, 2003795968 bytes
8 heads, 38 sectors/track, 12873 cylinders, total 3913664 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xf599e193

Device Boot Start End Blocks Id System
/dev/sda1 38 3913391 1956677 83 Linux

Disk /dev/sdb: 2000.4 GB, 2000409772032 bytes
255 heads, 63 sectors/track, 243202 cylinders, total 3907050336 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xdd3506db

Device Boot Start End Blocks Id System
/dev/sdb1 63 4000184 2000061 82 Linux swap / Solaris
/dev/sdb2 4000185 3867054344 1931527080 83 Linux
/dev/sdb3 3867054345 3907050335 19997995+ 83 Linux
')

Here's the result of mount:
$this->bbcode_second_pass_code('', '
[seth@alarm ~]$ sudo mount
/dev/root on / type ext3 (rw,noatime,errors=continue,data=writeback)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
/sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
/run on /run type tmpfs (rw,nosuid,nodev,relatime,size=10240k,mode=755)
udev on /dev type tmpfs (rw,nosuid,relatime,size=10240k,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
shm on /dev/shm type tmpfs (rw,nosuid,nodev,rel')

Here's the result of df -h
$this->bbcode_second_pass_code('', '[seth@alarm ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 1.9G 796M 990M 45% /
/run 10M 128K 9.9M 2% /run
udev 10M 4.0K 10M 1% /dev
shm 62M 0 62M 0% /dev/shm
tmpfs 62M 0 62M 0% /tmp
')

[WarheadsSE]

if lvm & udev are both trying to manage disks, that could be a problem, yes.