[IDEA] Put a list of available snapshots in /boot

[mk01]

(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.