[mk01]

(17th Jul, 2013 06:25 AM)alfredo Wrote:  Please let me know if you spot something evidently wrong in my fstab.
In the meanwhile, I'll try again the same configuration with beta 1.1, and let you know how it goes. (Possibly moving on the new thread.)

Thanks again!

there will be no difference, because nothing in the core changed.

---

(17th Jul, 2013 06:25 AM)alfredo Wrote:  Furthermore, I disabled stdout and stderr redirection in mountall.conf, and the following is the last message I get, before the aforecited 127 error code.

127 generally means "target can't be started - not available". on exec, or other call. looks like mountall wan't to start something - i suppose from /usr/sbin.

as upstart is all going around plymouth, dbus, policykits etc, I bet you have winner - something after /sbin/init - mountall

did you try the "debug" parameter in cmdline.txt, it will disbable the redirects for you, it will use --verbose logging for all the processes, redirect all to screen etc.

as a check for this theory with /usr I would open initramfs.gz again, and anywhere between
move_root and echo "Switching root" would put

"mount -t btrfs -o subvol=usr,thread_pool=1,rw,compress=lzo,noatime,autodefrag /dev/XXX (don't use label|uuid there) ${CONFIG_newroot}/usr"

I'm quite sure it will boot. You can try force mountall attention to /usr at all cost with "bootwait" parameter. But we even don't know, if mountall is started. and, to trigger device creation and LABEL|UUID resolving, udev needs to be started. and this is tarted on virtual-filesystems only, which happens cca 3s after startup so not so easy the parallel starting up.

I think the /usr mount from initramfs is safe harbor for now.

try the "debug" param, really.

beta2 is taking control over boot by starting /etc/init/xbian.conf AS ABSOLUTELY FIRST event / started exclusively with nothing else. then, we can easily control process from there.

I hope I put some ideas to your plays.