From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id AF22A158020 for ; Fri, 9 Dec 2022 17:17:43 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B8007E088C; Fri, 9 Dec 2022 17:17:37 +0000 (UTC) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6BAA4E0871 for ; Fri, 9 Dec 2022 17:17:37 +0000 (UTC) Received: by mail-lf1-x134.google.com with SMTP id d6so8026365lfs.10 for ; Fri, 09 Dec 2022 09:17:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=9q374wN43+95ijRxz/jTicxX3CawKT9Q9t6rrma3iEo=; b=fsg19yZISgMEz3ZqxU46OlKhn8yxRMQIcLI2lGRJdfLwQp6IcOTV16eovkU2iL81gC 4dREQ/1Bgg/pjdUULH5HH7Ctcqfa3yQNSU2V61BMpyfD2Rtq0tU91x5xLuZH4dFLa0+1 LXPr2unFCxZnRUUxzcnkGODhXkhbS3zIHCYnRwljL3ROuus2yqb0mpIeVWV1c8FTEjED 73kmDKJ2WV+MODZOp3WDC/mR0GSmqY227HI/HhbDIuXEc/uNUHlzGJucLBYi6+Vpn/fw +3WPi5VD6mHSgune9HCqpqUeyGZFZeCzlt1Ql2dkxe7qSExz5EjlsJ1ryCxcCKZJrmFp ekjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9q374wN43+95ijRxz/jTicxX3CawKT9Q9t6rrma3iEo=; b=JGmTx7Qp0nyHywHHddIfnGOc0wNChoCtoFvoMbG1mmVisWOG2FrcDSeJf5JKGLv260 q4b2u9zBxzHOD/wqqHBtMBSKEKIIIFdfs1btBPVAT3cnDDn9hBXhsksd4T4wf3/VF4fY feGP0CJE1AnjNmb+2z9QCoIT97nEVp3C+FbCyGa+W2b2FFCEzh5HgBR7fykXtOdqgNTA W5k9H/z6xjFOH/rg4pDQ5xpYd3bJ8UeemVJCZ7LkutuKlUKwprURXK7al+5iu0+sk1Ea lD1K0M8Qa+mHLb4BLC1P4ygJ2sAkEPym6tUQsGLhdtNjC92Y6JAu1eVOX20t5ZbGjz8B BSxg== X-Gm-Message-State: ANoB5pkkojJic7XA68Pqr8ItZ+mV0BnBWij4/Xay3u7euEWDpPQGV2ta vzqlMtEEZargbSjwXINZVNcWRrR3JHC2wDKhxJ0zAfxB X-Google-Smtp-Source: AA0mqf7M25MoNel5PHE4GHspGxeEbbmLTu1olZNcSjfdmwPH0UrV2tiYhceE5ZuHTx73Yo5ydhT06twdIyyHJ7XWIjI= X-Received: by 2002:ac2:4dad:0:b0:4b5:2f4e:a0cc with SMTP id h13-20020ac24dad000000b004b52f4ea0ccmr14655463lfe.392.1670606255635; Fri, 09 Dec 2022 09:17:35 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <8153803.T7Z3S40VBb@lenovo.localdomain> In-Reply-To: From: Mark Knecht Date: Fri, 9 Dec 2022 10:17:24 -0700 Message-ID: Subject: Re: [gentoo-user] Duel boot - How to verify boot loader updates? To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary="0000000000006d413305ef6854b8" X-Archives-Salt: 69e4d350-7bae-490c-a57a-4fd74aed7d1f X-Archives-Hash: a899740669a5bf2300da4950d040dc69 --0000000000006d413305ef6854b8 Content-Type: text/plain; charset="UTF-8" On Fri, Dec 9, 2022 at 4:07 AM Arve Barsnes wrote: > > On Fri, 9 Dec 2022 at 11:55, Michael wrote: > > To check the GRUB version of the second OS without booting into it, you can > > grep for grub in its /var/log/emerge.log > > Or see what version is named in the /usr/share/doc/grub-2.?? folder name. > > On the other hand, if the question is *really* about knowing if > grub-install has been run on one of the machines, I don't know if > there is a way. Probably look at change dates on the files in > /boot/grub/? > > Regards, > Arve Thanks to both of you for your responses. I appreciate them, although I don't think they get as far down in the weeds as I was wondering about. My understanding of the boot loader - and maybe I'm using the wrong terminology so if I am someone please correct me - is that at the start of boot BIOS tells the processor to read some part of the disk and it is the code read there that gets the whole process kicked off and out of BIOS's control. I'm wondering about that first bit of code being written by installation #2's update into the initial section of installation #1's disk. Rethink the picture a bit and make installation #1 Windows and installation #2 Linux. Assume that after updating each install, and further assume both installs made some very minor change to their own first bits of code on the disk, and assume everything still boots correctly, BUT assume that one of the updates actually wrote into the other install's initial boot code and replaced it with their own because it was confused about which disk it was supposed to put this on. How would I be able to determine that this happened? It's not totally a thought experiment. One machine I have which is dual boot recently complained that the original disk grub was installed on had changed when in fact there hadn't been any hardware changes and I had to carefully figure out how to answer a couple of questions. After the fact I started to wonder about this edge case. I think it comes down to reading what's on the disk with a hex editor possibly but I know nothing about what to expect there. Thanks, Mark --0000000000006d413305ef6854b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Dec 9, 2022 at 4:07 AM Arve Barsnes <arve.barsnes@gmail.com> wrot= e:
>
> On Fri, 9 Dec 2022 at 11:55, Michael <confabulate@kintzios.com> wrote:
>= ; > To check the GRUB version of the second OS without booting into it, = you can
> > grep for grub in its /var/log/emerge.log
>
&g= t; Or see what version is named in the /usr/share/doc/grub-2.?? folder name= .
>
> On the other hand, if the question is *really* about know= ing if
> grub-install has been run on one of the machines, I don'= t know if
> there is a way. Probably look at change dates on the file= s in
> /boot/grub/?
>
> Regards,
> Arve

Thanks to both of you for your responses. I appreciate them, althou= gh I
don't think they get as far down in the weeds as I was w= ondering about.

My understanding of the boot loade= r - and maybe I'm using the wrong
terminology so if I am some= one please correct me - is that at the start
of boot BIOS tells t= he processor to read some part of the disk and it is
the code rea= d there that gets the whole process kicked off and
out of BIOS= 9;s control.

I'm wondering about that first bi= t of code being written by installation
#2's update into the = initial section of installation #1's disk.

Ret= hink the picture a bit and make installation #1 Windows and=C2=A0
installation=C2=A0#2 Linux. Assume that after updating each install, and
further assume both installs made some very minor change to their<= /div>
own first bits of code on the disk, and assume everything still
boots correctly, BUT assume that one of the updates actually
=
wrote into the other install's initial boot code and replaced it w= ith
their own because it was confused about which disk it was=C2= =A0
supposed to put this on. How would I be able to determine tha= t
this happened?

It's not totally a = thought experiment. One machine I have which=C2=A0
is dual boot r= ecently complained that the original disk grub was=C2=A0
installe= d on had changed when in fact there hadn't been any=C2=A0
har= dware changes and I had to carefully figure out how to=C2=A0
answ= er a couple of questions. After the fact I started to wonder
abou= t this edge case.

I think it comes down to reading= what's on the disk with a=C2=A0
hex editor possibly but I kn= ow nothing about what to expect
there.

T= hanks,
Mark
--0000000000006d413305ef6854b8--