Forum

I seem to recall that it is possible to boot to a previous snapshot by modifying the rootflags parameter of cmdline.txt in case your xbian copy no longer boots. That would be all dandy, except that there is no easily accessible list of snapshots when I put the SD card into my computer to change the parameter. It would be great if there was a "snapshots.txt" in the /boot partition which was updated when snapshots were created or destroyed. If your install failed to boot, you could insert the SD card into your computer, find the snapshot you want from the snapshots.txt file, update cmdline.txt as needed, and be on your merry way all without ever leaving the comfort of your FAT boot partition.

Ideas/questions/comments?

If you are in the recovery console you can do (from memory):

If you want to create that list:

Understood. Thank you curlymo.

My suggestion was prompted by a recent occurrence where I was unable to even get to the recovery console. Can you confirm that setting the root parameter in config.txt to a different snapshot would have allowed me to boot from that previous snapshot (assuming the previous snapshot was intact) ?

Even when the recovery console is available, I don't have a spare usb keyboard or spare usb ports, so it is much simpler for me to pull the sd card and edit the boot partition on another machine. I suspect many other xbian users run sans keyboard like myself, and thus might find this feature useful. Anybody else care to chime in?

sounds like a good idea to me

The problem is that the /boot (FAT) partition is the most troublesome part of most installs because it can get corrupt easily. There is no way around it then just leaving it alone as much as possible. Writing an up-to-date list would fail to do so.

You can always create a cronjob yourself that even mails you a list of all snapshots if you'd like.

(10th Apr, 2014 01:09 AM)CurlyMo Wrote: [ -> ]The problem is that the /boot (FAT) partition is the most troublesome part of most installs because it can get corrupt easily. There is no way around it then just leaving it alone as much as possible. Writing an up-to-date list would fail to do so.

You can always create a cronjob yourself that even mails you a list of all snapshots if you'd like.

Understood. Thank you for the explanation and suggestion. I will probably implement that since my installations seem to be inexplicably volatile.

What could be a good idea is to have a lets say "second-to-last" snapshot. So, a snapshot that always refers to previous to last state and always has the same name.

(9th Apr, 2014 11:48 PM)adepssimius Wrote: [ -> ]Understood. Thank you curlymo.

My suggestion was prompted by a recent occurrence where I was unable to even get to the recovery console. Can you confirm that setting the root parameter in config.txt to a different snapshot would have allowed me to boot from that previous snapshot (assuming the previous snapshot was intact) ?

Even when the recovery console is available, I don't have a spare usb keyboard or spare usb ports, so it is much simpler for me to pull the sd card and edit the boot partition on another machine. I suspect many other xbian users run sans keyboard like myself, and thus might find this feature useful. Anybody else care to chime in?

@adepssimius

there are few kernel parameters maybe interesting for you:
1) telnet (kernel parameter) - creates telnetd server as first action when entering initramfs (recovery console) and after rootfs is switched (init called). in the second case (switch root, init and starndard boot) telnetd is killed immediately as sshd is started. in the first case (initramfs) your RPI will be that way accessible remotely in case rootfs is inaccessible (impossible to boot) as initramfs will drop to recovery console and wait for user action.
2) busybox conspy -f (command) - when you enter recovery console remotely via telnet, you get spawned shell. you can do repair stuff there, but normally you would like to continue boot process after the management tasks are done. conspy will change your "view" to console view - like you would be using ext. keyboard and siting in front of RPI. there you can just type "exit" and boot process will continue
3) rescue (kernel parameter) - if rescue is put into cmdline.txt, your initramfs will always be interrupted by dropping to shell - even if no other errors detected. this way you can remotely tasks you normally on mounted root and booted system can't
4) ip=dhcp (kernel parameter) - to have use of RPI telnetd (as in (1)) you need network. ip=dhcp will force kernel to obtain IP even before initramfs stage, without use of external scripts or tools - so your RPI will have IP since cca 3s after switching the power on or reset. ip=xxxx can be in cmdline permanently - only if you configure your RPI that kernel should be responsible for IP configuration, set your eth0 from "static" or "dhcp" to "manual" in /etc/network/interfaces. that way system boot scripts will just mark eth0 as UP without any other operation on the eth0. otherwise is hard to predict what will happen. latest Debian versions are "working" ok, but older scripts & tools for instance deconfigured the network and never configured again, or kept configuration in tact but didn't mark eth0 as UP etc etc....
5) bootmenu (kernel parameter) - this is answer to your opening post. in that case initramfs is dropped to shell and start a ncurses "gui" to allow you to choose what disk/partition/snapshot you wan't to boot. all available partitions are scanned automatically for presence of "boot.cfg" file which describes boot parameters for this particular partition it is found on. you can even boot another kernel, different command line parameters. for btrfs partitions it also gets all snapshots from subvolume "root" and lists them as possible boot target. template for "boot.cfg" is at /etc/xbian-initramfs/boot.cfg.example. bootmenu can be also present always - it is possible to define "timeout" parameter. if no user action is taken in "timeout" limit, system is automatically booted with kernel and parameters from /dev/mmcblk0p1 (as no bootmenu was used)

---

of course if one insist on walking to RPI each time something needs to be done, turning it off, pulling sd out, then editing, putting back, walking back, starting etc, creating txt file with snapshot names is the least problem. actually will do it asap.

but let's imagine your problem with damaged content on root/@. from the txt list file you wont see if the other snapshot name is bootable or not. so how many times you will repeat this procedure ? for each snapshot RPI off, SD out, PC in, EDIT, SD in, RPI on - to realise this one is also bad.

with early(recovery) console being accessible via network you can just start "bootmenu" manually and just hitting enter to see, if it works.

((bootmenu is not yet available as "released" functionality of XBian and was only minimally tested by myself - so one can expect some bugs as it was written from scratch))

mk

---

(10th Apr, 2014 04:37 AM)CurlyMo Wrote: [ -> ]What could be a good idea is to have a lets say "second-to-last" snapshot. So, a snapshot that always refers to previous to last state and always has the same name.

this one can also be added easily.

let's say btrfs-auto-snapshot tool will always create @last_good_known snapshot from currently created one. with next snapshot creation, @last_good_known will be destroyed and recreated from the freshly created.

will do as well.

---

@all

if "bootmenu" will be adopted later (in any functionality which can still "shape" for future), using it by default (configurable to "off" by user) can have another big advantage - and this is the problem CurlyMo is telling about - /boot consistency.

although it is not happening so often on XBian, there are still cases when /boot get's corrupted - making system unbootable for standard user. and user seeing system unbootable automatically assumes that XBian as a whole is broken.
- in majority of such cases user is going to re-flash whole install and wasting time with reconfiguration to previous state (if there is no backup).
- in majority of such cases rootfs is not broken and user can get system back by simply restoring /boot

currently, bootmenu & booting uses /boot as with normal setup - there is kernel, initramfs, cmdline.txt etc. but assuming bootmenu as part of boot process (even with timeout=0 in which case system will just straight boot into default) /boot partition doesn't need to be updated with setting changes, with kernel updates, etc. it could be unmounted permanently with a static "kernel" which would update on rare occasions only. the "actual" kernel & boot setttings would be still in /boot but as part of rootfs. and "bootmenu" booting process would find the "real" kernel & setups on rootfs as when it is now looking for other possible boot targets.

so there are plenty of possibilities how to use this.

@mk01 thank you very much for your detailed and very informative post. The bootmenu parameter looks like a fantastic piece of work and I will try it as soon as my rpi is unpacked (currently in the process of moving) along with the telnet parameter.

When using the telnet parameter, I assume that since I use reserved DHCP addresses I would need to also set the ip=dhcp parameter. From reading your explanation of the rescue parameter, I assume that if my system was in need of some manual intervention (me), I would have to add the rescue parameter in addition to the telnet and ip=dhcp parameters in order to actually assume control via telnet, correct?

Lastly, I am obviously not a linux guru by any means, but I would assume that at the recovery console since we are still running out of the initramfs that I would not be able to use wlan0 and I must use eth0 since the system loads kernel modules/drivers (please tell me which is the correct term) later on in the boot sequence. Is that also a correct assumption?

Lastly, thank you for all your hard work on xbian. IMO it is the most useful, feature-filled distro in the whole rpi community.

@adepssimius

CurlyMo has initramfs extended with wifi support, but for official stable it has been dropped.

The telnet has no other dependencies and is processed at two stages. Imagine boot as two steps. One is initramfs. Normally it takes 2-3s if there is nothing to do. Then root is mounted and init started. There begins 2nd stage.

If you have telnet as parameter this happens:
1) if initramfs phase is interrupted, telnetd server is created. Nothing less nothing more. So reason for which initramfs was interrupted is not condition for telnetd, neither if you started network from kernel. It is only up to you if you allows network at kernel stage (ip=dhcp) and/or if you decide, that initramfs stage will hold for you unconditionally (rescue). This is the only way to do VERY LOW LEVEL maintenance if you don't have physical access. Without rescue even with telnet and with ip=dhcp initramfs will not wait for you and until no error happened 2nd stage is started instantly.
2) telnet has its use even after initramfs phase. Imagine network config went wrong. Or /etc/ completely. Or there is service in S runlevel which won't stop so runlevel 2 won't be started and this would mean no net, no multiuser mode not even CONSOLE at physical access. Telnet there means that as /sbin/init is started from initramfs, telnetd is immediately after predeceasing all other possibilities for system to fail. But you can login and fix - again makes sense only if net is configured somewhere (ip=dhcp)

the first telnet session is stopped as initramfs passes - so normally is not even started within the 2-3s. the second telnetd is stopped automatically as soon as net is configured - so most part of startup is ok and ssh is available -- so telnet can be sure you are not left without access.

All this was implemented because I'm a bit lazy. And walking to RPI, handling SD card in another PC etc. It is too much demanding. that way I don't have to move from place until BOOT gets completely corrupted.