3

On Solaris and variants, it makes a zfs clone of the current / filesystem and installs the new kernel there. When rebooting you get the new /.

In my case I have a /scripts directory, so if I ever should go back to a previous kernel, then my /scripts would also get rolled back, which to me should be independent of with kernel I am on.

Question

How can I avoid loosing the changes made to the filesystem from the time the kernel upgrade is finished till the host is rebooted?

Is there a procedure I am not aware of, as even if you are very fast to reboot after the kernel upgrade, log entries could easily have been made, which you would never see.

Jasmine Lognnes
  • 2,490
  • 8
  • 31
  • 51

1 Answers1

2

What you described are Boot Environments (BE), which will be created automatically on system upgrades or manually with the beadm command.

You can have multiple independent BEs, although only a single one can be active at the same time. You also can update/modify each BE separately. Normally you would do that to test specific software versions or a full system upgrade, but it is not restricted to that.

From Advantages to Maintaining Multiple Boot Environments:

Although only one boot environment can be active at a time, you can mount an inactive boot environment by using the beadm mount command. Then, you could use the pkg command with the alternate root (-R) option to install or update specific packages on that environment.

I just tried it, beadm mount BeName will mount BeName in a temp directory under /tmp, which is writeable. You could write a simple script to sync/copy your new or changed files to the old BE or vice versa.

The documentation also states that snapshots on BEs are possible (with beadm create BeName@snapshotNamedescription), which may be helpful if you want to track differences that occurred between two points in time (with zfs diff).

user121391
  • 2,452
  • 12
  • 31