Merge lp:~jamesodhunt/snappy/bug-1412737 into lp:~snappy-dev/snappy/snappy-moved-to-github
| Status: | Merged |
|---|---|
| Approved by: | Michael Vogt on 2015-03-27 |
| Approved revision: | 186 |
| Merged at revision: | 269 |
| Proposed branch: | lp:~jamesodhunt/snappy/bug-1412737 |
| Merge into: | lp:~snappy-dev/snappy/snappy-moved-to-github |
| Diff against target: |
1087 lines (+690/-120) 6 files modified
debian/ubuntu-snappy.install (+1/-0) etc/grub.d/09_snappy (+410/-0) partition/bootloader_grub.go (+6/-17) partition/bootloader_grub_test.go (+4/-7) partition/partition.go (+129/-61) partition/partition_test.go (+140/-35) |
| To merge this branch: | bzr merge lp:~jamesodhunt/snappy/bug-1412737 |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Michael Vogt | Approve on 2015-03-27 | ||
| Sergio Schvezov | 2015-02-17 | Needs Information on 2015-03-26 | |
| Colin Watson (community) | 2015-02-17 | Approve on 2015-03-23 | |
| Steve Langasek | 2015-02-17 | Pending | |
|
Review via email:
|
|||
Commit Message
Make snappy on grub systems detect a broken boot and fall back to the other root partition on power cycling.
Description of the Change
Now that we have a single shared boot partition for grub, we can use it
to store bootloader variables that store state (as is already done for
snappy u-boot systems).
Further, we no longer need to re-install grub from within the chroot to
tell grub which rootfs to boot from since the variables suffice.
Note though that snappy still needs to call update-grub from within the
chroot since that chroot has the correct grub config files for that
particular rootfs (/etc/grub.d/*, etc).
Since the grub code is run from within a chroot (where the "other"
rootfs is mounted), it might _appear_ that the logic is inverted, but
this is not the case since the grub snippet queries the chroot
environment only to set up the grub menu (the grub snippet should work
correctly outside a chroot, although it would not be valid to do this on
a snappy system).
Specifically, the grub snippet performs 2 functions:
1) Create the grub menuentry's for the 2 rootfs's *at update-grub time*
and within the context of the "other" chroot.
2) Arrange for grub to toggle the rootfs *at boot time*, based on the
value of the grub environment block variables.
Remaining work:
- update the logic in ubuntu-core-snappy to also mount the current rootfs r/o at
/writable/
of snappy for the next release and the behaviour needs to match).
_________
* etc/grub.
- Creates menuentry's for both rootfs's.
- Boots using the rootfs specified by the snappy_ab variable
(which replaces the boot-by-uuid config auto-generated by
grub-install [which is no longer called]).
- Toggles the rootfs if the last boot failed (LP: #1412737).
* partition/
- ToggleRootFS: Remove call to grub-install now that
ubuntu-
* partition/
- bindmountRequir
bindmountTh
for both rootfs's on grub systems.
| James Hunt (jamesodhunt) wrote : | # |
| James Hunt (jamesodhunt) wrote : | # |
Changes for the snappy python implementation are here:
lp:~jamesodhunt/ubuntu/vivid/ubuntu-core-snappy/mount-current-rootfs-in-chroot-for-bug-1412737 (I'll raise an MP once this branch lands).
| Michael Vogt (mvo) wrote : | # |
Just a quick note without having looked at the code itself yet.
I feel a bit uneasy about the amount of code in 09_snappy that looks like its duplication from 10_linux. I wonder if there is anything we could do here? Maybe share code with 10_linux, maybe even generate from snappy-go directly instead of via shell (snappy-go knows about the partition layout for example already).
The other thing that does not feel ideal is the fact that we chroot and then bindmount the original back. The chroot also seems to not allow lsblk to work. I wonder if we could do something like make update-grub honor a GRUB_SYSCONF_
This may all be crazy, but I wanted to throw it out as ideas anyway :)
But in any case, merging this into trunk and running:
$ ./run-checks
fails for me so that needs addressing.
| James Hunt (jamesodhunt) wrote : | # |
Hi Michael,
> I feel a bit uneasy about the amount of code in 09_snappy that looks
> like its duplication from 10_linux.
> I wonder if there is anything we
> could do here? Maybe share code with 10_linux,
Well, yes 09_snappy is currently a very cleaned up version of 10_linux :)
I understand the concerns. Regarding 09_snappy and 10_linux, my plan is
to do the following (and get it upstreamed) to minimise the delta we
have to maintain:
1) Move the functions in 09_snappy to /usr/lib/
(or maybe /usr/lib/
2) Add linux_entry() to grub-lib-linux.
3) Make linux_entry() call linux_entry_ext().
4) Rework 10_linux to call the functions in grub-lib-linux.
Assuming this can be upstreamed, we could then collapse 09_snappy down
an ~75 line script.
> maybe even generate from
> snappy-go directly instead of via shell (snappy-go knows about the
> partition layout for example already).
I'm not super happy about the amount of shell in grub either tbh.
However, that is the current standard it seems and I'm trying to conform
to that. I like the idea of snappy-go generating the config but would
value input from others as to the safety of such an approach given the
number of other scripts and config files grub has here and there; if we
It feels rather dangerous to start generating the config entirely on our
own as we should be able to rely on grub library routines to handle any
internal grub changes. If we go it alone, that seems higher risk than
simply writing a new grub snippet such as this MP adds.
> The other thing that does not feel ideal is the fact that we chroot and
> then bindmount the original back.
Yes, the chroot'ing is a pita but is required to:
1) Ensure we're calling the correct grub commands for the "other"
rootfs.
2) Ensure that the command(s) in (1) have the correct config
(/etc/grub.d/* and /etc/default/grub).
> The chroot also seems to not allow lsblk to work.
Right - I haven't looked at the lsblk source, but it fails in a chroot,
only reporting "/".
>I wonder if we could do something like make update-grub
> honor a GRUB_SYSCONF_
That would be neat if upstream would agree to that. Again, if we're only
going to make these changes locally for snappy, which is worse? A delta
on grub itself or a delta on a packaged grub config file? Also, would
that variable be sufficient (I don't know yet I'm afraid).
> This may all be crazy, but I wanted to throw it out as ideas anyway :)
Definately good to get it into the open! :)
> But in any case, merging this into trunk and running: $ ./run-checks
> fails for me so that needs addressing.
Oops, sorry! I still cannot run the snappy tests due to the click issue
so once the new versions lands in vivid I'll fix that.
I think that if this branch is unlikely to land today (and that's
looking very likely :-), that we should postpone landing it (in any
form) until after the next promotion.
| Michael Vogt (mvo) wrote : | # |
Just a quite note for the "./run-checks". The new click is in the beta PPA since yesterday. You can also run the partition tests by doing: "go test ./partition", this part of the code does not use click so that should work.
| Sergio Schvezov (sergiusens) wrote : | # |
I just want to note that etc/grub.
Also added a couple of inline comments.
| James Hunt (jamesodhunt) wrote : | # |
Thanks - added rc check.
| Alexander Sack (asac) wrote : | # |
whats the state of this one? Are we doing this? Is this zombied?
| James Hunt (jamesodhunt) wrote : | # |
We still need the code to be reviewed by someone familiar with the grub package. The current behaviour:
If snappy fails to boot (hangs in early boot):
- uboot systems: will revert automatically to the "other" rootfs on next boot.
- grub systems: no rootfs switch happens on next boot due to this branch not having landed yet. A work-around currently would be enter the grub menu and modifying the cmdline to specify manually "root=system-a" or "root=system-b" (the user would need to try both as they won't know which is the current default).
Note that as well as bringing grub systems up to feature parity with uboot system, this MP also adds "boot by label" ("root=system-a") for simplicity.
| Colin Watson (cjwatson) wrote : | # |
The duplication isn't especially pleasant, but it also isn't a huge problem: this is well-contained within snappy and so isn't going to break anything else. And I certainly agree with James that generating this entirely from Go code and thus ignoring all of GRUB's library functions is unwise. The rest looks reasonable enough from a skim-read.
| Alexander Sack (asac) wrote : | # |
whats the plan for testing this? I think if we knew how to test this manually or even better automatically, we should land and get miles on this asap.
| James Hunt (jamesodhunt) wrote : | # |
A manual testcase is here: https:/
| Michael Vogt (mvo) wrote : | # |
Top-level approving based on the ACK from Colin.
| Snappy Tarmac (snappydevtarmac) wrote : | # |
Attempt to merge into lp:snappy failed due to conflicts:
text conflict in debian/
text conflict in partition/
| Sergio Schvezov (sergiusens) wrote : | # |
I don't see any a/b layout handling here, can you explain how that will work?
| James Hunt (jamesodhunt) wrote : | # |
That's handled at the very end of etc/grub.
(I'm currently reworking the snappy-go changes on this branch so it's no longer ready to land, hence the status change).
| Sergio Schvezov (sergiusens) wrote : | # |
On jueves 26 de marzo de 2015 10h'33:50 ART, James Hunt wrote:
> That's handled at the very end of etc/grub.
> "Toggle rootfs if previous boot failed.").
>
> (I'm currently reworking the snappy-go changes on this branch
> so it's no longer ready to land, hence the status change).
So the kernel lives in system-a and system-b and not system-boot?
| James Hunt (jamesodhunt) wrote : | # |
Currently snappy systems using grub mirror standard Ubuntu systems, so yes.
| James Hunt (jamesodhunt) wrote : | # |
Branch updated but not tested due to current devel-proposed issues.
| James Hunt (jamesodhunt) wrote : | # |
Tested .go changes performing a "snappy-go update".
- 186. By James Hunt on 2015-03-27
-
* Sync with lp:snappy.
| Michael Vogt (mvo) wrote : | # |
I have some inline comments, but I think its more important to land this than to do any of this so I will approve and we can followup in a different MP.


It is also worth pointing out here that the included etc/grub. d/09_snappy makes /etc/grub. d/10_linux redundant. The fact that 10_linux will be run as part of update-grub does not cause problems - it simply creates an additional menuentry in /boot/grub/ grub.cfg. So we could consider removing /etc/grub. d/10_linux from the images via a follow-on livecd-rootfs change.