Disk initialisation order when waking up from Deep Standby

[Mickkie]

I've posted in the past about a problem with waking up from Deep Standby for a recording and not going back into Standby, but this problem I report here gave me a fright.

I flashed my Mut@ant with OpenViX 5.2.001 and rebooted, restored settings, installed e2iplayer which was not reinstalled as part of restoring plugins and thought all was well done.

Then thought of testing to see if waking up from Deep Standby worked as it used to some versions ago, so put it into Deep Standby and a couple of hours later when a recording was meant to have started I went back to it to see if it had succeeded to go into Standby, while it was recording a program. I was confronted with this error message:

Creating hardlink to timeshift failed!
The filesystem on your Timeshift-Device does not support hard links.
Make sure it is formatted in EXT2 or EXT3.
[Errno 1] Operation not permitted.

I checked the settings to make sure Timeshift was assigned to use the /media/hdd/ drive and not a USB stick I have plugged in for PICONS. The settings were all correct. I looked at the list of recorded programs and then I panicked because all the recordings were gone, except for the recording currently in progress.

I also checked the Recordings settings to see they were assigned to the /media/hdd/ drive as they should be and this setting was also correct.

I stopped the recording and deleted the current timer, unmounted both spinning disk and USB stick and run fsck on both of them. The USB had a dirty bit set. I rebooted and all my recordings were restored. Listing the contents of the USB drive revealed it had been initialised as /dev/sda1 instead of the HDD and therefore it was being used for recordings and timeshift.

Any idea why this happened and how I can avoid this happening in the future? I am avoiding placing the Mut@nt into Deep Standby for now.

[abu baniaz]

Initialisation = format

Your issue is not initialisation, but mounting. Go to Mount Manager and ensure mounts are as you need.

[adm]

I've seen this type of problem a couple of times in the past immediately after performing an image update where a USB gets mounted on the reboot but not the hard disk. As a result the box attempts to put the timeshift and/or recordings on the stick (which has insufficient capacity). A cold reboot (switching off at the mains for 60 seconds) after an image update has always restored correct operation with respect to mounting the hard disk. Subsequent daily entry into deep standby has not shown the problem again.

[Mickkie]

@abu baniaz: Apologies for not using the correct nomenclature. I meant when the MoBo starts probing devices and udev initialises them, they are not initialised in the correct order and therefore they are mounted incorrectly. Where is the "mount manager"?

@adm: I tried what you suggested. The same problem occurred:

Before I powered down:

# blkid | grep sd.1
/dev/sda1: UUID="e639994e-9466-471a-8c77-285b59d9ff13" TYPE="ext4" PARTLABEL="primary" PARTUUID="1483c56d-85ce-4de1-a0be-e216dcf9b3c4"
/dev/sdb1: LABEL="USB DISK" UUID="1043-0091" TYPE="vfat" PARTUUID="c3072e18-01"

After I powered up:

# blkid | grep sd.1
/dev/sda1: LABEL="USB DISK" UUID="1043-0091" TYPE="vfat" PARTUUID="c3072e18-01"
/dev/sdb1: UUID="e639994e-9466-471a-8c77-285b59d9ff13" TYPE="ext4" PARTLABEL="primary" PARTUUID="1483c56d-85ce-4de1-a0be-e216dcf9b3c4"

This problem does not occur if I just reboot.

[twol]

Menu/setup/vix ——> Mountmanager

[Mickkie]

Thank you twol, I just came across it as I was checking which drive is used to save backups and images. Here is a screenshot ofBBC ONE HD-2992018-1847.jpg what it shows, but this is not the order in which devices are mounted when the Mut@nt is woken up from a Deep Standby.

[abu baniaz]

IIRC, if you save the mount points in mount manager, the mount points use a different, more resilient method.

Please confirm you have "saved" while in mount manager.

May I ask why you need the USB stick and also in a non-linux file system.

[Huevos]

You are in the correct screen. Open each device in turn and save the settings.

[birdman]

Listing the contents of the USB drive revealed it had been initialised as /dev/sda1 instead of the HDD and therefore it was being used for recordings and timeshift.

Any idea why this happened

It's an issue about which device responds first when the various communication buses are probed at boot time.
This can be random, and also dependent on any "extra" USB devices present at boot time.
The solution is to mount devices using their partition UUID, which is what will be set-up if you configure mount points in the Device/Mount Manager.

[Mickkie]

Thank you all for your replies. I've used the Mount Manager in the Vix menu to (re)confirm the devices were as shown and saved the results, rebooting each time as it asked me to do. I set the device into Deep Standby and when it woke up their order in which they were mounted was respected.

Interestingly, /etc/fstab shows the devices with their UUIDs:

/dev/mmcblk0p1		/boot		auto		defaults	1  1
rootfs			/		auto		defaults		1  1
proc			/proc		proc		defaults		0  0
devpts			/dev/pts	devpts		mode=0620,gid=5	0  0
usbdevfs		/proc/bus/usb	usbdevfs	noauto				0  0
tmpfs			/var/volatile	tmpfs		defaults				0  0
/dev/mmcblk0p10 none swap defaults 0 0
UUID=e639994e-9466-471a-8c77-285b59d9ff13	 /media/hdd	auto	defaults	0 0
UUID=1043-0091	/media/usb	vfat	defaults	0 0

@abu baniaz: I'm sure I read somewhere a USB stick is recommended for saving PICONS and for storing the EPG. I left it with a VFAT fs (as opposed to ext2) because this is what I use often to flash the Mut@nt with a new image and the various guides state the USB used for flashing should be formatted as VFAT.

[abu baniaz]

EPG is best on HDD.

I'd only use a separate flash drive for picons if it is a large picon set. Internal flash is fine. Anyway, your issue should be resolved now.

[bbbuk]

I use HDD for both EPG and picons without any issues

[Huevos]

I use HDD for both EPG and picons

Putting picons on the HDD means either the HDD is kept permanently awake, or the HDD has to spin up just to open the infobar. Either way, not something we would recommend.

The only benefit of putting picons on a USB drive is that it is easy to transport them from box to box.

[abu baniaz]

Or not having to reinstall after flashing

[Huevos]

Or not having to reinstall after flashing

Mine are on USB and not added from the feeds, but means the picons go out of date over time.