From nobody Fri Jan 03 17:21:16 2025 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YPr2x1cKyz5kDHF for ; Fri, 03 Jan 2025 17:21:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YPr2w6yCXz4mWP for ; Fri, 3 Jan 2025 17:21:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x102d.google.com with SMTP id 98e67ed59e1d1-2eec9b3a1bbso13789638a91.3 for ; Fri, 03 Jan 2025 09:21:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1735924888; x=1736529688; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=MC8Vpb3GiZEch9glgN9WA6FQOV+YTnTEA+wo4NlRD0c=; b=NYq+Ey3odiONVnKhATLVEveZrDMjdBYU37bFB6LfOtbpuyCZ8FUcTYVCpYrk17uygo oyRwGRHuzcP8isn/VvqsLuUSTDeoefUnIvh4liDJUMU8QiPDIcLvRFYTmjp1dvgT9bLw E9f7OjBRCnYSlcJXJ6b51fWJjwVNeJWtUD6AMqLdg2NqEI+lPjJzCgYIjBkZ6pGAm8dx hWkCPMhYfDTcQkJZiC4eRBvSgrG06J5wGR3WdBL1gshUIDFng0PUe/pwLhHrzvG9HUTo /VwVu3ha2XcRaWlxYVinRfXtEvudqiIhfpFlnIcT7s4yXuvr37ndAgHuXPbssFWoAGF2 PxAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735924888; x=1736529688; h=cc: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=MC8Vpb3GiZEch9glgN9WA6FQOV+YTnTEA+wo4NlRD0c=; b=TVTfgMU/i8c+JL4iFvG0YmGM6TcrWbs/yfu8OY9rC3e7I//wvSL0MFUZldGOqz7Ch/ XlDHTdLck7nTrGOyojhvNDHDfZoSHPYyM1bIN2FgT4qIk4PRE/tk06SXoW9VAx/XLcmP CJGUqNiY9j7YYh2x3WrMnELApF4eerrP6RL2sjPpiNN2sSav209a8eXrBVZdZzihHQyS ckRa7any/CyxN6Ii4UK3CMux+3nuNTcmzDv4ZxlxF6muvP7+cQNS9W3vZ/lboxWWeLhZ fzStpruJd/DvaKpAszQhJWtCYhfUiNxU+iY4x1MF2EiusLrmpdQUvSBPelXhWRvILn2q R38Q== X-Gm-Message-State: AOJu0Yxx1NCjQH0WdVHIaf3A25J9SSGb4Y1Y1+hiER9MItHbnzCaLSEg Lbpk3DSzjjopd8as5RGWgv76czVsM/dq94j/Ww+CzyNKCkPvrEe1GgeX/OUkmQw6nRxw8E6KUHp +2lROaE4DkOYZY7e92AajTe85p1Z/uXjBsy1bYA== X-Gm-Gg: ASbGnctTQ+6U4dSnJ7XeJwXrZKtWRY9RW3idMvQkp3bEXqjhN7lpxB0IqhXF8uYrdcd 5XOoHBfgRUeoppaGQheI6csIA5UDGPMxqkNkUid5d7gsTGszH0ifGSJHkzf6x9grX8GA1dtc= X-Google-Smtp-Source: AGHT+IHeT6ANt8ZbZQ8OR024dnFfVzeBfLOoRp6hSaiqNebSveuy04tnvW5s04r8uNj/mkz0phOMd389ff6E7jXQA3c= X-Received: by 2002:a17:90b:3848:b0:2ee:f80c:6889 with SMTP id 98e67ed59e1d1-2f452edbb7emr77401530a91.33.1735924887602; Fri, 03 Jan 2025 09:21:27 -0800 (PST) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Fri, 3 Jan 2025 10:21:16 -0700 Message-ID: Subject: Re: "Loader needs to be updated" (azure guest context) To: "Edward Sanford Sutton, III" Cc: FreeBSD Stable ML Content-Type: multipart/alternative; boundary="000000000000486e26062ad08289" X-Rspamd-Queue-Id: 4YPr2w6yCXz4mWP X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] --000000000000486e26062ad08289 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 3, 2025, 10:15=E2=80=AFAM Edward Sanford Sutton, III < mirror176@hotmail.com> wrote: > On 12/30/24 10:59, Warner Losh wrote: > > On Mon, Dec 30, 2024, 8:45=E2=80=AFAM void wrote: > > > >> Hi, > >> > >> context is > >> > >> freebsd amd64 vm on Azure (initially installed via azure marketplace > >> several > >> years ago (12-releng)), and has been upgraded as updates became > available > >> with freebsd-update over the years all the way up to 13.4-p1 now. > >> System updates/upgrades have *always* been managed with freebsd-update= . > >> > >> Latest upgrade from 13.3-p6 to 13.4-p1 shows "loader needs to be > updated" > >> in the beastie menu in the console now. This is new. > >> > >> # zfs --version > >> zfs-2.1.14-FreeBSD_gd99134be8 > >> zfs-kmod-2.1.15-FreeBSD_gd99134be8 > >> > >> (perhaps side issue - different version numbers, same > -FreeBSD_gd99134be8 > >> ?!!) > >> > >> This system is *not* root-on-zfs. There is zfs, but it's data on > >> a non-boot virtual disk. > >> > >> "zpool status" invites me to upgrade the pool. I've not done this (hav= e > >> never done it with this vm, either), and don't want to unless I'm > >> absolutely certain upgrading the pool won't break everything. > >> > >> I note from a (similar, but different context) thread last September > >> > >> > https://lists.freebsd.org/archives/freebsd-current/2024-September/006378.= html > >> that FreeBSD uses "the guest's boot loader and the host's /boot/lua > files" > >> but I'm clueless how this would apply in an amd64 context with Azure > >> as the host. > >> > >> What do i have to do? Also, is the warning safe to ignore in this > context? > >> > > > > In this context, it's a known false positive. It's too risky to fix in = a > pX > > for 13.4, so will be in 13.5 since the fix is already in stable/13. It'= s > > just cosmetic, there's no bug it exposes. And even if you hadn't actual= ly > > updated the loader, it will fail safe for loaders installed from FreeBS= D > 11 > > and newer (though not relevant to your use case). It should be in the > > release notes for 13.4 as a known issue, but the process for post relea= se > > revision is murky at best. > > Why is there no errata entry for it? > I don't know how to create that. If someone reminds me I'll add it. Warner > > The host vs guest issue you highlighted is a different thing and applie= s > > only to bhyve. > > > > Warner > > > >> > > > > > --000000000000486e26062ad08289 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jan 3, 2025, 10:15=E2=80= =AFAM Edward Sanford Sutton, III <mirror176@hotmail.com> wrote:
On 12/30/24 10:59, Warner Losh wrote:
> On Mon, Dec 30, 2024, 8:45=E2=80=AFAM void <void@f-m.fm> wrote:
>
>> Hi,
>>
>> context is
>>
>> freebsd amd64 vm on Azure (initially installed via azure marketpla= ce
>> several
>> years ago (12-releng)), and has been upgraded as updates became av= ailable
>> with freebsd-update over the years all the way up to 13.4-p1 now.<= br> >> System updates/upgrades have *always* been managed with freebsd-up= date.
>>
>> Latest upgrade from 13.3-p6 to 13.4-p1 shows "loader needs to= be updated"
>> in the beastie menu in the console now. This is new.
>>
>> # zfs --version
>> zfs-2.1.14-FreeBSD_gd99134be8
>> zfs-kmod-2.1.15-FreeBSD_gd99134be8
>>
>> (perhaps side issue - different version numbers, same -FreeBSD_gd9= 9134be8
>> ?!!)
>>
>> This system is *not* root-on-zfs. There is zfs, but it's data = on
>> a non-boot virtual disk.
>>
>> "zpool status" invites me to upgrade the pool. I've = not done this (have
>> never done it with this vm, either), and don't want to unless = I'm
>> absolutely certain upgrading the pool won't break everything.<= br> >>
>> I note from a (similar, but different context) thread last Septemb= er
>>
>> htt= ps://lists.freebsd.org/archives/freebsd-current/2024-September/006378.html<= /a>
>> that FreeBSD uses "the guest's boot loader and the host&#= 39;s /boot/lua files"
>> but I'm clueless how this would apply in an amd64 context with= Azure
>> as the host.
>>
>> What do i have to do? Also, is the warning safe to ignore in this = context?
>>
>
> In this context, it's a known false positive. It's too risky t= o fix in a pX
> for 13.4, so will be in 13.5 since the fix is already in stable/13. It= 's
> just cosmetic, there's no bug it exposes. And even if you hadn'= ;t actually
> updated the loader, it will fail safe for loaders installed from FreeB= SD 11
> and newer (though not relevant to your use case). It should be in the<= br> > release notes for 13.4 as a known issue, but the process for post rele= ase
> revision is murky at best.

Why is there no errata entry for it?



--000000000000486e26062ad08289--