Date:Mon, 25 Sep 2023 09:45:25 - (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| There can be multiple EFI system partitions on a drive,
That was my understanding from reading the spec.
| but it sometimes confuses software,
What can I say to
On Mon, 25 Sep 2023, Robert Elz wrote:
Date:Mon, 25 Sep 2023 05:57:49 +
From:Emmanuel Dreyfus
Message-ID:
| bootme.cfg is searched in EFI paririon /EFI/NetBSD/boot.cfg
Which EFI partition? I think I have about 5 or 6, sprinkled around
various bootable
k...@munnari.oz.au (Robert Elz) writes:
>Date:Mon, 25 Sep 2023 05:57:49 +
>From:Emmanuel Dreyfus
>Message-ID:
> | bootme.cfg is searched in EFI paririon /EFI/NetBSD/boot.cfg
>Which EFI partition? I think I have about 5 or 6, sprinkled around
>various
On Mon, Sep 25, 2023 at 10:43:56AM +0200, Edgar Fuß wrote:
> > boot[].cfg is > searched in EFI par[tit]ion /EFI/NetBSD/boot.cfg
> > and root partition /boot.cfg.
> But how can EFI locate it on the root partition if it tells where the root
> partition lives?
Not EFI, but the bootloader. It
> boot[].cfg is > searched in EFI par[tit]ion /EFI/NetBSD/boot.cfg
> and root partition /boot.cfg.
But how can EFI locate it on the root partition if it tells where the root
partition lives?
> | It's not obviously where efiboot finds boot.cfg, since that's in
> | esp:/EFI/NetBSD/boot.cfg or,
>
> And we correctly interpret that, always?
It works for me on four servers I recently set up if I put it into /EFI/NetBSD
on the ESP. It also, for reasons unknown to me, works on one other
On Mon, Sep 25, 2023 at 05:57:49AM +, Emmanuel Dreyfus wrote:
> Bootme tels bootstrap where to look root partition. bootme.cfg is
> searched in EFI paririon /EFI/NetBSD/boot.cfg and root partition /boot.cfg.
I would describe it differently:
- firmware finds bootloader "somewhere" on some
Date:Mon, 25 Sep 2023 05:57:49 +
From:Emmanuel Dreyfus
Message-ID:
| bootme.cfg is searched in EFI paririon /EFI/NetBSD/boot.cfg
Which EFI partition? I think I have about 5 or 6, sprinkled around
various bootable devices (more than one on some). None of
On Mon, Sep 25, 2023 at 08:13:29AM +0200, Michael van Elst wrote:
> So, the bootme flag effectively specifies the root partition, but only
> by virtue of defaults being passed down the chain. The kernel should
> not outguess things and interpret the flag itself.
I am working with oster@ on that.
On Mon, Sep 25, 2023 at 05:57:49AM +, Emmanuel Dreyfus wrote:
> On Mon, Sep 25, 2023 at 12:20:00PM +0700, Robert Elz wrote:
> [bootme flag]
> > I'd always assumed it to be where efiboot should locate boot.cfg.
> > Where the kernel and root filesystems are located are in boot.cfg.
>
> Bootme
On Mon, Sep 25, 2023 at 12:20:00PM +0700, Robert Elz wrote:
[bootme flag]
> I'd always assumed it to be where efiboot should locate boot.cfg.
> Where the kernel and root filesystems are located are in boot.cfg.
Bootme tels bootstrap where to look root partition. bootme.cfg is
searched in EFI
Date:Sun, 24 Sep 2023 17:41:30 +
From:Taylor R Campbell
Message-ID: <20230924174130.481dd60...@jupiter.mumble.net>
| Why would bootme be usually set on the EFI system partition?
|
| The documentation in gpt(8) needs to be clarified -- and I'm not sure
|
On Sun, Sep 24, 2023 at 08:14:07PM +0200, Martin Husemann wrote:
> To me the flag sounds totally useless and I'd say we should remove support
> for it (or document it as only valid for compatibility with existing
> setups).
Please don't break setup that are in use, expecially when it comes to
On Sun, Sep 24, 2023 at 05:41:30PM +, Taylor R Campbell wrote:
> The documentation in gpt(8) needs to be clarified -- and I'm not sure
> there's any other canonical reference about it in any of our
> documentation -- but it sounds to me like it is supposed to be:
>
> (a) where NetBSD's
> Date: Mon, 18 Sep 2023 19:21:09 +0200
> From: Martin Husemann
>
> On Mon, Sep 18, 2023 at 06:14:58PM +0100, David Brownlee wrote:
> > Specifically in the absence of any other information (empty devname?
> > etc), would it not be reasonable to fall back to the bootme marked
> > filesystem as a
Date:Mon, 18 Sep 2023 19:21:09 +0200
From:Martin Husemann
Message-ID: <20230918172109.ga4...@mail.duskware.de>
| A fallback similar to the current implementation picking the first non-swap
| partition would be usefull.
The first netbsd style partition (not just
On Mon, Sep 18, 2023 at 10:41:56PM -, Michael van Elst wrote:
> So in many cases bootme marks the root partition. It is rarely
> used on the EFI partition, but that's also a possibility.
I guess it comes down to what bootselector your setup is for.
IMO the ideal setup is for all possilble
a...@absd.org (David Brownlee) writes:
>Our gpt(8) states "bootme flag is used to indicate which partition
>should be booted by UEFI boot code", which could be read either way.
The flag is used to find the partition to load /boot, /boot.cfg or
the kernel from. The boot disk information is also
On Mon, 18 Sept 2023 at 18:21, Martin Husemann wrote:
>
> On Mon, Sep 18, 2023 at 06:14:58PM +0100, David Brownlee wrote:
> > Specifically in the absence of any other information (empty devname?
> > etc), would it not be reasonable to fall back to the bootme marked
> > filesystem as a root
On Mon, Sep 18, 2023 at 06:14:58PM +0100, David Brownlee wrote:
> Specifically in the absence of any other information (empty devname?
> etc), would it not be reasonable to fall back to the bootme marked
> filesystem as a root filesystem candidate? I'm thinking about
> minimally configured disks
On Sun, 17 Sept 2023 at 23:25, Robert Elz wrote:
> [...]
>
> That is what you MUST NOT do, BOOTME has nothing whatever to do
> with what is root. That's the part that must be done some other way.
>
> (The bit where the flag was copied into the wedge info was just a
> layer violation, and easy
Date:Sat, 16 Sep 2023 05:01:00 +
From:Emmanuel Dreyfus
Message-ID:
| Initial proposal was to aad access to the bootme flag in dkwedge,
| which has been considered bad design, and I agreed with that.
Yes, but that's not what was really wrong with the
On Sat, Sep 16, 2023 at 08:57:28PM +1000, Simon Burge wrote:
> The only corner case that an older kernel won't understand a longer root
> device name passed in by a newer /boot as the old kernel will still have
> the 16 char length limit.
Yes, old kernels will truncate the name. Since that's
Martin Husemann wrote:
> On Sat, Sep 16, 2023 at 06:51:40AM -, Michael van Elst wrote:
>
> > There is one caveat. Since all x86 bootloader data is funneled through
> > the bootinfo structure we have:
> >
> > struct btinfo_rootdevice {
> > struct btinfo_common common;
> >
On Sat, Sep 16, 2023 at 08:17:16AM +0200, Martin Husemann wrote:
> [...]
> But the more general solution (which would be just as easy for the end
> user, but more flexibel) is to add support for a rootdev statement
> in boot.cfg and then put the label name or the guid there. Similar
> to evbarm
On Sat, Sep 16, 2023 at 06:51:40AM -, Michael van Elst wrote:
> You can already specify the root in boot.cfg.
OK, the man page needs an update.
> >It would also be cool if boot.cfg could specify the partition to load
> >the kernel from via something similiar to NAME=.
>
> You can already
mar...@duskware.de (Martin Husemann) writes:
>But the more general solution (which would be just as easy for the end
>user, but more flexibel) is to add support for a rootdev statement
>in boot.cfg and then put the label name or the guid there. Similar
>to evbarm taking a root=dev argument passed
On Sat, Sep 16, 2023 at 05:01:00AM +, Emmanuel Dreyfus wrote:
> The patch moves the GPT parser out of dkwedge so that it can
> be used by other kernel componentx. You calll gpt_walk() with
> a callback invoked for each GPT entry. dkwedge use it to do the
> job it was doing before, and
On Sat, Sep 16, 2023 at 08:34:23AM +0700, Robert Elz wrote:
> I didn't attempt to read the patch, no. Just the regular text
> parts of the mail thread.
Initial proposal was to aad access to the bootme flag in dkwedge,
which has been considered bad design, and I agreed with that.
The patch
Date:Fri, 15 Sep 2023 22:46:47 +
From:Emmanuel Dreyfus
Message-ID:
| You noted that latest patch does not introduce bootme stuff
| into dkwaedge code, right?
I didn't attempt to read the patch, no. Just the regular text
parts of the mail thread.
kre
On Sat, Sep 16, 2023 at 02:13:06AM +0700, Robert Elz wrote:
> What happens after that needs to be handled some other way.
You noted that latest patch does not introduce bootme stuff
into dkwaedge code, right?
--
Emmanuel Dreyfus
m...@netbsd.org
On Fri, Sep 15, 2023 at 08:28:13PM +, os...@netbsd.org wrote:
> So no, Emmanuel's changes arn't needed if you really know what you're doing
> on an install with sysinst, but a novice just following the default is
> currently going to really be a long way from a bootable system. (I'm not
>
September 15, 2023 at 10:15 AM, "Martin Husemann" wrote:
>
> On Fri, Sep 15, 2023 at 04:01:15PM +, Emmanuel Dreyfus wrote:
>
> >
> > A multiboot bootloader cannot, because all the information that is passed
> > is about partition numbers. There is no way of specifying a LBA offset,
> >
Date:Fri, 15 Sep 2023 15:15:10 +
From:Emmanuel Dreyfus
Message-ID:
| Ths user took care of setting bootme so that botstrap finds
| the kernel, and we should disregard this explicit setting
| when mounting root?
I agree with others, where you boot from
On Fri, Sep 15, 2023 at 04:01:15PM +, Emmanuel Dreyfus wrote:
> A multiboot bootloader cannot, because all the information that is passed
> is about partition numbers. There is no way of specifying a LBA offset,
> hence the setup where you have a GPT inside raidframe seems impossible
> to
On Fri, Sep 15, 2023 at 05:27:32PM +0200, Michael van Elst wrote:
> That setting tells where /boot is loaded from and where /boot.cfg
> is loaded from. The bootloader tells the kernel where the boot
> partition is, traditionally in terms of offset and size, but optionally
> as wedge identifier.
On Fri, Sep 15, 2023 at 05:25:51PM +0200, Martin Husemann wrote:
> Something groks enough raidframe to find a GPT partition inside a raidframe
> and can load the kernel from there, but it can't pass any usable information
> to that kernel how it was loaded (and from where), without our bootloader
On Fri, Sep 15, 2023 at 03:15:10PM +, Emmanuel Dreyfus wrote:
> On Fri, Sep 15, 2023 at 03:06:46PM -, Michael van Elst wrote:
> > What about just telling the kernel what to use in /boot.cfg ?
> > No need to add more magic to the kernel.
>
> Ths user took care of setting bootme so that
On Fri, Sep 15, 2023 at 03:15:10PM +, Emmanuel Dreyfus wrote:
> On Fri, Sep 15, 2023 at 03:06:46PM -, Michael van Elst wrote:
> > What about just telling the kernel what to use in /boot.cfg ?
> > No need to add more magic to the kernel.
>
> Ths user took care of setting bootme so that
On Fri, Sep 15, 2023 at 03:06:46PM -, Michael van Elst wrote:
> What about just telling the kernel what to use in /boot.cfg ?
> No need to add more magic to the kernel.
Ths user took care of setting bootme so that botstrap finds
the kernel, and we should disregard this explicit setting
when
m...@netbsd.org (Emmanuel Dreyfus) writes:
>multitboot lets the bootloader pass boot device information as BIOS
>driver, partition number, subpartition number. This is intended
>for MBR extended partitions or MBR/disklabel.
What about just telling the kernel what to use in /boot.cfg ?
No need to
On Tue, Sep 12, 2023 at 05:21:06PM +, Emmanuel Dreyfus wrote:
> > But Michaels question is a good one - why can't the bootloader deal
> > with all this and pass e.g. the start offset of the root partition
> > via (optional) boot params?
>
> I will have a look at that, but I am not sure how it
42 matches
Mail list logo
