Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #242929 > unrolled thread

telling if we've actually booted from /boot/xen-4.14-amd64.gz

Back to article view | Back to linux.debian.user

Contents

  telling if we've actually booted from /boot/xen-4.14-amd64.gz Tim Woodall <debianuser@woodall.me.uk> - 2021-12-10 23:20 +0100
    Re: telling if we've actually booted from /boot/xen-4.14-amd64.gz Charles Curley <charlescurley@charlescurley.com> - 2021-12-11 04:40 +0100
      Re: telling if we've actually booted from /boot/xen-4.14-amd64.gz Tim Woodall <debianuser@woodall.me.uk> - 2021-12-11 07:00 +0100
        Re: telling if we've actually booted from /boot/xen-4.14-amd64.gz Charles Curley <charlescurley@charlescurley.com> - 2021-12-11 19:10 +0100
          Re: telling if we've actually booted from /boot/xen-4.14-amd64.gz Andrei POPESCU <andreimpopescu@gmail.com> - 2021-12-12 09:10 +0100
      Re: telling if we've actually booted from /boot/xen-4.14-amd64.gz Charles Curley <charlescurley@charlescurley.com> - 2021-12-11 22:00 +0100
    Re: telling if we've actually booted from /boot/xen-4.14-amd64.gz Andy Smith <andy@strugglers.net> - 2021-12-12 02:30 +0100
      Re: telling if we've actually booted from /boot/xen-4.14-amd64.gz Tim Woodall <debianuser@woodall.me.uk> - 2021-12-12 08:20 +0100
        Re: telling if we've actually booted from /boot/xen-4.14-amd64.gz Tim Woodall <debianuser@woodall.me.uk> - 2021-12-12 16:20 +0100

#242929 — telling if we've actually booted from /boot/xen-4.14-amd64.gz

Is there a simple way to tell if the kernel/hypervisor that was used to
boot is the one currently installed in /boot.

I have a script that emails me when it detects a mismatch and it's
broken with the latest bullseye xen hypervisor.

I was grepping for major.minor.release (from /sys/hypervisor/version)
but that gives 4.14.4-pre while strings on the (uncompressed) hypervisor gives
4.14.3+32-g9de3671772-1~deb11u1

/sys/hypervisor/compilation/compile_date:Thu Dec  2 20:45:55 UTC 2021
seems to match the timestamp on the files in /boot. Is that something I
can rely on?

Is there a good way to do what I want (which is to avoid missing an automatic
upgrade and then not rebooting for months)?

Automatic rebooting on upgrade is not an option as I only want to reboot
when I have time to deal with any issues if it fails to come up for any
reason.

So far my script to check the kernel version is ok, only the hypervisor
check has failed with the recent update. For the kernel I grep for uname
-r and uname -v.

This update has fixed my power-off problem though :-)

Tim.

[toc] | [next] | [standalone]

#242940

On Fri, 10 Dec 2021 22:11:04 +0000 (GMT)
Tim Woodall <debianuser@woodall.me.uk> wrote:

> Is there a good way to do what I want (which is to avoid missing an
> automatic upgrade and then not rebooting for months)?

If you are using the unattended-upgrades package, you can set it to
send you emails. Those emails will let you know which packages are
upgraded, and if a reboot is required. See
/etc/apt/apt.conf.d/50unattended-upgrades.

Aside from your use case, I highly recommend doing so if your hard
drive is encrypted.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#242947

On Fri, 10 Dec 2021, Charles Curley wrote:

> On Fri, 10 Dec 2021 22:11:04 +0000 (GMT)
> Tim Woodall <debianuser@woodall.me.uk> wrote:
>
>> Is there a good way to do what I want (which is to avoid missing an
>> automatic upgrade and then not rebooting for months)?
>
> If you are using the unattended-upgrades package, you can set it to
> send you emails. Those emails will let you know which packages are
> upgraded, and if a reboot is required. See
> /etc/apt/apt.conf.d/50unattended-upgrades.
>
> Aside from your use case, I highly recommend doing so if your hard
> drive is encrypted.
>
I don't use that but I do something similar. Does unattended-upgrades
email me each day until I reboot? If so then I should take a look at
switching to use it. (I've been doing it 'my way' since potato - so
change is hard ;-) )

Tim.

[toc] | [prev] | [next] | [standalone]

#242969

On Sat, 11 Dec 2021 05:52:30 +0000 (GMT)
Tim Woodall <debianuser@woodall.me.uk> wrote:

> I don't use that but I do something similar. Does unattended-upgrades
> email me each day until I reboot?

Not every day, but every day when an upgrade is applied it emails you,
and tells you that a reboot is pending.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#242995

[Multipart message — attachments visible in raw view] — view raw

On Sb, 11 dec 21, 10:42:56, Charles Curley wrote:
> On Sat, 11 Dec 2021 05:52:30 +0000 (GMT)
> Tim Woodall <debianuser@woodall.me.uk> wrote:
> 
> > I don't use that but I do something similar. Does unattended-upgrades
> > email me each day until I reboot?
> 
> Not every day, but every day when an upgrade is applied it emails you,
> and tells you that a reboot is pending.

As far as I recall there is some flag file that packages must set to 
signal a reboot is required. It should be trivial to set up a daily cron 
job to send you a mail if that file is (still) present.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#242977

On Fri, 10 Dec 2021 20:14:36 -0700
Charles Curley <charlescurley@charlescurley.com> wrote:

> If you are using the unattended-upgrades package, you can set it to
> send you emails. Those emails will let you know which packages are
> upgraded, and if a reboot is required. See
> /etc/apt/apt.conf.d/50unattended-upgrades.

I neglected to mention: You also have the option of having
unattended-upgrades reboot the computer for you. *Not* recommended for
encrypted systems, or the OP's (Tim Woodall <debianuser@woodall.me.uk>)
case.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#242986

[Multipart message — attachments visible in raw view] — view raw

Hi Tim,

On Fri, Dec 10, 2021 at 10:11:04PM +0000, Tim Woodall wrote:
> Is there a simple way to tell if the kernel/hypervisor that was used to
> boot is the one currently installed in /boot.

I do not do this - I build my own hypervisor packages when there is
an upstream XSA that affects me and then I have to schedule downtime
to boot into it, so I am well aware of what is booted into what.

However, it seems you can read the ELF build ID from the kernel file
and also from "xl info" (or /sys/hypervisor/properties/buildid if
you decode it). Please see attached file check_running_hypervisor.sh
for an example.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#242994

On Sun, 12 Dec 2021, Andy Smith wrote:

> Hi Tim,
>
> On Fri, Dec 10, 2021 at 10:11:04PM +0000, Tim Woodall wrote:
>> Is there a simple way to tell if the kernel/hypervisor that was used to
>> boot is the one currently installed in /boot.
>
> I do not do this - I build my own hypervisor packages when there is
> an upstream XSA that affects me and then I have to schedule downtime
> to boot into it, so I am well aware of what is booted into what.
>
> However, it seems you can read the ELF build ID from the kernel file
> and also from "xl info" (or /sys/hypervisor/properties/buildid if
> you decode it). Please see attached file check_running_hypervisor.sh
> for an example.
>
Awesome! Thank you.

Tim.

[toc] | [prev] | [next] | [standalone]

#243012

On Sun, 12 Dec 2021, Tim Woodall wrote:

> On Sun, 12 Dec 2021, Andy Smith wrote:
>
>> Hi Tim,
>> 
>> On Fri, Dec 10, 2021 at 10:11:04PM +0000, Tim Woodall wrote:
>>> Is there a simple way to tell if the kernel/hypervisor that was used to
>>> boot is the one currently installed in /boot.
>> 
>> I do not do this - I build my own hypervisor packages when there is
>> an upstream XSA that affects me and then I have to schedule downtime
>> to boot into it, so I am well aware of what is booted into what.
>> 
>> However, it seems you can read the ELF build ID from the kernel file
>> and also from "xl info" (or /sys/hypervisor/properties/buildid if
>> you decode it). Please see attached file check_running_hypervisor.sh
>> for an example.
>> 
> Awesome! Thank you.
>

Interesting, and weird. /sys/hypervisor/properties/buildid isn't
consistent in its output:

tim@dirac:~ (none)$ od -v -w20 -t x1 -A none /sys/hypervisor/properties/buildid | sed 's/ //g'
87e9d3e5762b1c3aa26b5a82ed3e72c2ffffffff
d859ad3a8188ffff
tim@dirac:~ (none)$ od -v -w20 -t x1 -A none /sys/hypervisor/properties/buildid | sed 's/ //g'
87e9d3e5762b1c3aa26b5a82ed3e72c2
tim@dirac:~ (none)$ od -v -w20 -t x1 -A none /sys/hypervisor/properties/buildid | sed 's/ //g'
87e9d3e5762b1c3aa26b5a82ed3e72c2ffffffff
58c331
tim@dirac:~ (none)$ od -v -w20 -t x1 -A none /sys/hypervisor/properties/buildid | sed 's/ //g'
87e9d3e5762b1c3aa26b5a82ed3e72c2
tim@dirac:~ (none)$ od -v -w20 -t x1 -A none /sys/hypervisor/properties/buildid | sed 's/ //g'
87e9d3e5762b1c3aa26b5a82ed3e72c2
tim@dirac:~ (none)$ od -v -w20 -t x1 -A none /sys/hypervisor/properties/buildid | sed 's/ //g'
87e9d3e5762b1c3aa26b5a82ed3e72c2
tim@dirac:~ (none)$ od -v -w20 -t x1 -A none /sys/hypervisor/properties/buildid | sed 's/ //g'
87e9d3e5762b1c3aa26b5a82ed3e72c2
tim@dirac:~ (none)$ od -v -w20 -t x1 -A none /sys/hypervisor/properties/buildid | sed 's/ //g'
87e9d3e5762b1c3aa26b5a82ed3e72c2
tim@dirac:~ (none)$ od -v -w20 -t x1 -A none /sys/hypervisor/properties/buildid | sed 's/ //g'
87e9d3e5762b1c3aa26b5a82ed3e72c2
tim@dirac:~ (none)$ od -v -w20 -t x1 -A none /sys/hypervisor/properties/buildid | sed 's/ //g'
87e9d3e5762b1c3aa26b5a82ed3e72c2
tim@dirac:~ (none)$ od -v -w20 -t x1 -A none /sys/hypervisor/properties/buildid | sed 's/ //g'
87e9d3e5762b1c3aa26b5a82ed3e72c2
tim@dirac:~ (none)$ od -v -w20 -t x1 -A none /sys/hypervisor/properties/buildid | sed 's/ //g'
87e9d3e5762b1c3aa26b5a82ed3e72c2ffffffff
58cd31
tim@dirac:~ (none)$ od -v -w20 -t x1 -A none /sys/hypervisor/properties/buildid | sed 's/ //g'
87e9d3e5762b1c3aa26b5a82ed3e72c2ffffffff
584d78368188ffff
tim@dirac:~ (none)$ od -v -w20 -t x1 -A none /sys/hypervisor/properties/buildid | sed 's/ //g'
87e9d3e5762b1c3aa26b5a82ed3e72c2


Every now and again it reads 12 extra bytes.

Seems to only happen on buster, not bullseye.

Tim.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web