NSA325v2 - Shutdown & reboot NOK

Hi

When I wan't to shutdown my machine via ssh or via terminal the result is the same. It won't shutdown and is going in maintenance mode.
When pushing control-D like asked in this maintenance mode it boots right up in debian and can ssh into it, but when entering root password ssh isn't allowed and only terminal works.

For shutting down I used the command:

shutdown now

Second problem when booted and want to reboot the machine, it won't boot up properly because I noticed that my flashdrives gets assigned to sdc instead sdb when you power cycle via powerplug.

For rebooting I used two different commands, but with the same result:

shutdown -r now

reboot

When I power off my machine by unplugging my power cord and then plugging back in and power on, then everything is booting up fine without a problem.
Logs are given in attachment for more details what the machine is doing, I needed to zip it, because there where 4 logs and could only upload 3 files.

Can anyone point me out what is wrong to fix this problem, because it isn't very good to cut power off like that or is it?

----
Friendly regards


Ziggy

ziggy,

> When I power off my machine by unplugging my power
> cord and then plugging back in and power on, then
> everything is booting up fine without a problem.

1. This seems to be a timing problem. Observe this using serial console:

shutdown:

shutdown -h now

If it has problem, post your entire serial console log when it goes into maintenance mode. If not, use the power button to power up. If you see any problemduring power up, post the log.

2. Your second problem is because you u-boot env and your USB rootfs were not set up to boot with multiple disk drives attached. You could list you u-boot envs here:

fw_printenv

And list the label of all 3 disks using:

e2label /dev/sda1
e2label /dev/sdb1
e2label /dev/sdc1

Potential problems when booting multiple drives are described here:
http://forum.doozan.com/read.php?3,19093

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi

Thanks for the quick reply.
I've noticed that my usb_root was set to "/dev/db1" instead of "LABEL=rootfs".

root@RXkeNAS:~# fw_printenv
arcNumber=4495
baudrate=115200
bootcmd=run bootcmd_usb; run bootcmd_sata; run bootcmd_mmc; reset
bootcmd_mmc=run mmc_init; run set_bootargs_mmc; run mmc_boot
bootcmd_sata=run sata_init; run set_bootargs_sata; run sata_boot;
bootcmd_usb=run usb_init; run set_bootargs_usb; run usb_boot;
bootdelay=3
console=ttyS0,115200
device=0:1
ethact=egiga0
ethaddr=<masked, but is filled in correctly>
if_netconsole=ping $serverip
ipaddr=192.168.0.204
led_error=orange blinking
led_exit=green off
led_init=green blinking
mainlineLinux=yes
mmc_boot=mw 0x800000 0 1; run mmc_load_uimage; if run mmc_load_uinitrd; then bootm 0x800000 0x1100000; else bootm 0x800000; fi
mmc_init=mmc rescan
mmc_load_uimage=ext2load mmc $device 0x800000 /boot/uImage
mmc_load_uinitrd=ext2load mmc $device 0x1100000 /boot/uInitrd
mmc_root=/dev/mmcblk0p1
mtddevname=rootfs
mtddevnum=2
mtdids=nand0=orion_nand
mtdparts=mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)
partition=nand0,2
preboot_nc=run if_netconsole start_netconsole
rootdelay=5
rootfstype=ext4
sata_boot=mw 0x800000 0 1; run sata_load_uimage; if run sata_load_uinitrd; then bootm 0x800000 0x1100000; else bootm 0x800000; fi
sata_init=ide reset
sata_load_uimage=ext4load ide $device 0x800000 /boot/uImage
sata_load_uinitrd=ext4load ide $device 0x1100000 /boot/uInitrd
sata_root=/dev/sda1
serverip=192.168.0.220
set_bootargs_mmc=setenv bootargs console=$console root=$mmc_root rootdelay=$rootdelay rootfstype=$rootfstype $mtdparts
set_bootargs_sata=setenv bootargs console=$console root=$sata_root rootdelay=$rootdelay rootfstype=$rootfstype $mtdparts
set_bootargs_usb=setenv bootargs console=$console root=$usb_root rootdelay=$rootdelay rootfstype=$rootfstype $mtdparts
start_netconsole=setenv ncip $serverip; setenv bootdelay 10; setenv stdin nc; setenv stdout nc; setenv stderr nc; version;
stderr=serial
stdin=serial
stdout=serial
usb_boot=mw 0x800000 0 1; run usb_load_uimage; if run usb_load_uinitrd; then bootm 0x800000 0x1100000; else bootm 0x800000; fi
usb_init=usb start
usb_load_uimage=ext4load usb $device 0x800000 /boot/uImage
usb_load_uinitrd=ext4load usb $device 0x1100000 /boot/uInitrd
usb_root=LABEL=rootfs

By changing only this it has fixed my problem for not being able to reboot or halt my system without any errors.

Label list is as following:

root@RXkeNAS:~# e2label /dev/sda1
e2label: No such file or directory while trying to open /dev/sda1
Couldn't find valid filesystem superblock.
root@RXkeNAS:~# e2label /dev/sdb1
e2label: No such file or directory while trying to open /dev/sdb1
Couldn't find valid filesystem superblock.
root@RXkeNAS:~# e2label /dev/sdc1
rootfs
root@RXkeNAS:~#

But now I'm still confused/puzzled why my USB drive gets another /dev assigned when my nas, that is booted correctly, got a power failure and afterwards receive back power and power button has been pushed to boot up the nas.
Then it get's /dev/sdb1 and my internal HDD's respectively /dev/sda1 and /dev/sdc1.

EDIT: One more thing, this is not applicable if the NAS is correctly powered off and you then receive power failure it doesn't affect the assignment of the USB drive, neither when power off and then the power button is used to power on the nas again.

EDIT 2: Off course the above e2label commands get a different output according to what /dev/s... the USB got assigned.

When booted correctly and I now perform a shutdown -r now the USB drive gets /dev/sdc1 and internal drives /dev/sda1 and /dev/sdb1.
For just using the NAS this isn't a problem, but when using the NAS wit raid software like OMV (OpenMediaVault) in my opinion the raid wil fail in the first scenario, because then the drives aren't correctly configured at boot.

Haven't tested this yet, but I'm going to do that now.
In attachments both serial logs for one when rebooted and one after a simulated power failure.

Can you enlighten me in this? ;-)

----
Friendly regards


Ziggy



Edited 2 time(s). Last edit at 09/30/2015 03:16PM by ziggy.

ziggy Wrote:
-------------------------------------------------------
> Hi
>
> Thanks for the quick reply.
> I've noticed that my usb_root was set to
> "/dev/db1" instead of "LABEL=rootfs".
>
>

> root@RXkeNAS:~# fw_printenv
> arcNumber=4495
> baudrate=115200
> bootcmd=run bootcmd_usb; run bootcmd_sata; run
> bootcmd_mmc; reset
> bootcmd_mmc=run mmc_init; run set_bootargs_mmc;
> run mmc_boot
> bootcmd_sata=run sata_init; run set_bootargs_sata;
> run sata_boot;
> bootcmd_usb=run usb_init; run set_bootargs_usb;
> run usb_boot;
> bootdelay=3
> console=ttyS0,115200
> device=0:1
> ethact=egiga0
> ethaddr=<masked, but is filled in correctly>
> if_netconsole=ping $serverip
> ipaddr=192.168.0.204
> led_error=orange blinking
> led_exit=green off
> led_init=green blinking
> mainlineLinux=yes
> mmc_boot=mw 0x800000 0 1; run mmc_load_uimage; if
> run mmc_load_uinitrd; then bootm 0x800000
> 0x1100000; else bootm 0x800000; fi
> mmc_init=mmc rescan
> mmc_load_uimage=ext2load mmc $device 0x800000
> /boot/uImage
> mmc_load_uinitrd=ext2load mmc $device 0x1100000
> /boot/uInitrd
> mmc_root=/dev/mmcblk0p1
> mtddevname=rootfs
> mtddevnum=2
> mtdids=nand0=orion_nand
> mtdparts=mtdparts=orion_nand:1M(u-boot),4M(uImage)
> ,32M(rootfs),-(data)
> partition=nand0,2
> preboot_nc=run if_netconsole start_netconsole
> rootdelay=5
> rootfstype=ext4
> sata_boot=mw 0x800000 0 1; run sata_load_uimage;
> if run sata_load_uinitrd; then bootm 0x800000
> 0x1100000; else bootm 0x800000; fi
> sata_init=ide reset
> sata_load_uimage=ext4load ide $device 0x800000
> /boot/uImage
> sata_load_uinitrd=ext4load ide $device 0x1100000
> /boot/uInitrd
> sata_root=/dev/sda1
> serverip=192.168.0.220
> set_bootargs_mmc=setenv bootargs console=$console
> root=$mmc_root rootdelay=$rootdelay
> rootfstype=$rootfstype $mtdparts
> set_bootargs_sata=setenv bootargs console=$console
> root=$sata_root rootdelay=$rootdelay
> rootfstype=$rootfstype $mtdparts
> set_bootargs_usb=setenv bootargs console=$console
> root=$usb_root rootdelay=$rootdelay
> rootfstype=$rootfstype $mtdparts
> start_netconsole=setenv ncip $serverip; setenv
> bootdelay 10; setenv stdin nc; setenv stdout nc;
> setenv stderr nc; version;
> stderr=serial
> stdin=serial
> stdout=serial
> usb_boot=mw 0x800000 0 1; run usb_load_uimage; if
> run usb_load_uinitrd; then bootm 0x800000
> 0x1100000; else bootm 0x800000; fi
> usb_init=usb start
> usb_load_uimage=ext4load usb $device 0x800000
> /boot/uImage
> usb_load_uinitrd=ext4load usb $device 0x1100000
> /boot/uInitrd
> usb_root=LABEL=rootfs
>

>
> By changing only this it has fixed my problem for
> not being able to reboot or halt my system without
> any errors.
>
> Label list is as following:
>

> root@RXkeNAS:~# e2label /dev/sda1
> e2label: No such file or directory while trying to
> open /dev/sda1
> Couldn't find valid filesystem superblock.
> root@RXkeNAS:~# e2label /dev/sdb1
> e2label: No such file or directory while trying to
> open /dev/sdb1
> Couldn't find valid filesystem superblock.
> root@RXkeNAS:~# e2label /dev/sdc1
> rootfs
> root@RXkeNAS:~# 
>

>
> But now I'm still confused/puzzled why my USB
> drive gets another /dev assigned when my nas, that
> is booted correctly, got a power failure and
> afterwards receive back power and power button has
> been pushed to boot up the nas.
> Then it get's /dev/sdb1 and my internal HDD's
> respectively /dev/sda1 and /dev/sdc1.
>
> EDIT: One more thing, this is not applicable if
> the NAS is correctly powered off and you then
> receive power failure it doesn't affect the
> assignment of the USB drive, neither when power
> off and then the power button is used to power on
> the nas again.
>
> EDIT 2: Off course the above e2label commands get
> a different output according to what /dev/s... the
> USB got assigned.
>
> When booted correctly and I now perform a shutdown
> -r now the USB drive gets /dev/sdc1 and internal
> drives /dev/sda1 and /dev/sdb1.
> For just using the NAS this isn't a problem, but
> when using the NAS wit raid software like OMV
> (OpenMediaVault) in my opinion the raid wil fail
> in the first scenario, because then the drives
> aren't correctly configured at boot.
>
> Haven't tested this yet, but I'm going to do that
> now.
> In attachments both serial logs for one when
> rebooted and one after a simulated power failure.
>
> Can you enlighten me in this? ;-)

Sure.

The assignment of disk letter should never be relied upon in configuring software. If your OMV sw does rely on that then it is not doing its job. The timing of the disks changed in different booting scenarios and different hardware different configuration will cause spinup time changes. In a nomal case, your HDDs are spun up first, so they will get sda and sdb assigment.

The only way to make it work consistenly is through u-boot envs, in that you can tell uboot which disk is used for what purpose. So that's why in the linked post above I showed how u-boot env can be set up to consistently choose the correct drives during boot.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)