Le 22/01/2020 à 16:05, Hongyi Zhao a écrit :

jdd@dodin.org 于2020年1月22日周三 下午10:28写道：

...

Le 22/01/2020 à 15:17, Hongyi Zhao a écrit :

...

Any hints / notes for my issue? Is it possible to boot opensuse on the btrfs with grub2 outside the btrfs?

sure, but some info are needed...

what firmware? BIOS, UEFI? what disk MSDOS? GPT?

GPT + UEFI

may be: https://unix.stackexchange.com/questions/473419/how-to-create-a-bios-grub-pa... jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Markus Koßmann 于2020年1月23日周四 上午11:02写道：

Am Mittwoch, 22. Januar 2020, 16:05:11 CET schrieb Hongyi Zhao:

...

jdd@dodin.org 于2020年1月22日周三 下午10:28写道：

...

Le 22/01/2020 à 15:17, Hongyi Zhao a écrit :

...

Any hints / notes for my issue? Is it possible to boot opensuse on the btrfs with grub2 outside the btrfs?

sure, but some info are needed...

what firmware? BIOS, UEFI? what disk MSDOS? GPT?

GPT + UEFI

UEFI boot requires that there is a VFAT formated EFI system partition. This partition should be mounted on /boot/efi and this is the location where GRUB2 will be installed.

Not necessarily to mount it. I use the grub-mkstandalone method to prepare the specific efi file and then let this efi to do the subsequent things. I have a project for this on the github: https://github.com/hongyi-zhao/multiboot This project is based on the following projects and aims to supply more a powerful and convenient boot-manager and os installer with the iso files: grub2: https://www.gnu.org/software/grub refind: http://www.rodsbooks.com and my port of original multibootusb ( https://github.com/aguslr/multibootusb ): https://github.com/hongyi-zhao/multibootusb Regards

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-- Hongsheng Zhao Institute of Semiconductors, Chinese Academy of Sciences GnuPG DSA: 0xD108493 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thu, Jan 23, 2020 at 1:30 PM Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 23/01/2020 04.02, Markus Koßmann wrote: | Am Mittwoch, 22. Januar 2020, 16:05:11 CET schrieb Hongyi Zhao: |> jdd@dodin.org 于2020年1月22日周三 下午10:28写道： |> |>> Le 22/01/2020 à 15:17, Hongyi Zhao a écrit : |>>> Any hints / notes for my issue? Is it possible to boot |>>> opensuse on the btrfs with grub2 outside the btrfs? |>> |>> sure, but some info are needed... |>> |>> what firmware? BIOS, UEFI? what disk MSDOS? GPT? |> |> GPT + UEFI |> | UEFI boot requires that there is a VFAT formated EFI system | partition. This partition should be mounted on /boot/efi and this | is the location where GRUB2 will be installed.

No, /boot/efi does not contain grub.

It does.

Grub is in /boot in all cases.

GRUB consists of multiple parts. At least in case of secure boot grub is completely located on ESP and does not load anything from /boot. Otherwise stage1.5 is in ESP.

Isengard:~ # tree /boot/efi/ /boot/efi/ └── EFI ~ ├── boot ~ │ ├── MokManager.efi ~ │ ├── bootx64.efi ~ │ ├── fallback.efi ~ │ ├── grub.cfg ~ │ └── grub.efi ~ └── opensuse ~ ├── MokManager.efi ~ ├── boot.csv ~ ├── grub.cfg ~ ├── grub.efi

Secure boot

~ ├── grubx64.efi

Non-secure boot

~ └── shim.efi

3 directories, 11 files Isengard:~ #

- -- Cheers / Saludos,

Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXil1mAAKCRC1MxgcbY1H 1cUfAKCEFRILxXsNAvbNvbJ6QyieNT9+5ACfVv8KxyJnghYh/On/Cnhv2OaVwvY= =T+0T -----END PGP SIGNATURE-----

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thu, 23 Jan 2020 11:48:18 +0100 "Carlos E. R." wrote:

On 23/01/2020 11.32, Andrei Borzenkov wrote:

...

On Thu, Jan 23, 2020 at 1:30 PM Carlos E. R. <> wrote:

...

...

| UEFI boot requires that there is a VFAT formated EFI system | partition. This partition should be mounted on /boot/efi and this | is the location where GRUB2 will be installed.

...

No, /boot/efi does not contain grub.

It does.

...

Grub is in /boot in all cases.

GRUB consists of multiple parts. At least in case of secure boot grub is completely located on ESP and does not load anything from /boot. Otherwise stage1.5 is in ESP.

...

Isengard:~ # tree /boot/efi/ /boot/efi/ └── EFI ~ ├── boot ~ │ ├── MokManager.efi ~ │ ├── bootx64.efi ~ │ ├── fallback.efi ~ │ ├── grub.cfg ~ │ └── grub.efi ~ └── opensuse ~ ├── MokManager.efi ~ ├── boot.csv ~ ├── grub.cfg ~ ├── grub.efi

Secure boot

...

~ ├── grubx64.efi

Non-secure boot

...

~ └── shim.efi

3 directories, 11 files Isengard:~ #

It does have files in /boot/grub:

Isengard:~ # cat /boot/efi/EFI/opensuse/grub.cfg search --fs-uuid --set=root 0d457df1-b43d-4587-aa5a-6c919bcbedb8 set prefix=(${root})/boot/grub2 source "${prefix}/grub.cfg" Isengard:~ #

And /boot has the normal grub2 files, so I assume it continues from there.

I don't understand why you are flogging this dead horse, Carlos? Markus said "UEFI boot requires that there is a VFAT formated EFI system partition. This partition should be mounted on /boot/efi and this is the location where GRUB2 will be installed." and that is correct (modulo Hongyi's special case of not mounting the ESP). So I don't understand why you said it isn't. And then when Andrei corrected your blunt and incorrect assertion with an equally blunt but correct assertion, you try to disagree with that as well!!? And you try to disagree by changing the subject. Markus didn't say there weren't any grub-related files elsewhere, so they are totally irrelevant to the subject. Why not just do a search and read up on how grub2 works in a UEFI system and accept that you've [re?]learned something? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: El 2020-01-23 a las 14:22 +0100, Carlos E. R. escribió:

El 2020-01-23 a las 12:19 -0000, Dave Howorth escribió:

...

On Thu, 23 Jan 2020 11:48:18 +0100 "Carlos E. R." <> wrote:

...

On 23/01/2020 11.32, Andrei Borzenkov wrote:

...

On Thu, Jan 23, 2020 at 1:30 PM Carlos E. R. <> wrote:

...

...

...

...

Isengard:~ #

And /boot has the normal grub2 files, so I assume it continues from there.

I don't understand why you are flogging this dead horse, Carlos?

Markus said "UEFI boot requires that there is a VFAT formated EFI system partition. This partition should be mounted on /boot/efi and this is the location where GRUB2 will be installed."

I did not say the contrary. UEFI bot of course requires the EFI partition, booting starts there.

My understanding is that the UEFI firmware loads the EFI files in /boot/EFI, and these load Grub in /boot/grub2. If this is not so, you don't have to be angry at me. - -- Cheers Carlos E. R. (from openSUSE 15.1 (Legolas)) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXimgLxwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVDt0An1LOsKtF2SI4Ya/82Qxo xvu0sMU4AJ0Xb2/TGHZGPoR6mmDxP8KXaPIUfg== =rWGH -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26/01/2020 15.20, Anton Aylward wrote: | For some reason I never understood, /boot was created as ext2 and | I've never bothered with changing that. Ext2, not ext4, is the correct choice for a separate /boot. And yes, I still use a separate /boot, for historical reasons. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXi7VVwAKCRC1MxgcbY1H 1em8AJsGvuyb/NWXmfGHpNgSaKcxn/Mc1ACdGmCl5Qj9HgSnZxAg8bg2zJzNUf8= =1KDF -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. 于2020年1月23日周四 上午12:51写道：

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

El 2020-01-22 a las 22:17 +0800, Hongyi Zhao escribió:

...

Hi,

I installed the latest opensuse leap 15.1 with the default btrfs filesystem. But I want to boot it from outside the btrfs volume with grub2 which is located on a separated boot partition.

I tried many times, but still cannot figure it out. On the other hand, the refind boot manager can automatically detect the opensuse and boot it.

Any hints / notes for my issue? Is it possible to boot opensuse on the btrfs with grub2 outside the btrfs?

It is possible, but it is strongly disrecommended, so much so that YaST probably does not allow it.

Probably the most salient feature of btrfs is snapshots; for this to work the entire system must be in a single partition. That is, after a failed update or change, grub allows you to boot the system that was previous to the update. With boot in a different partition, the kernel is out of reach of the snapshot, so the feature is broken.

May be I should depicted my method more detailed: I only let the grub itself on a separate partition, with which I can boot the kernels located on the btrfs. Regards

If you insist on using a separate /boot, you might as well not use btrfs.

- -- Cheers Carlos E. R.

(from openSUSE 15.1 (Legolas))

-----BEGIN PGP SIGNATURE-----

iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXih9cxwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVttoAnidCeNAz96Tbk3zOTjHu wMXuyuT5AJ4uMEF5UYUP7dcDyntHw0MRBn/ggw== =JpN9 -----END PGP SIGNATURE-----

-- Hongsheng Zhao Institute of Semiconductors, Chinese Academy of Sciences GnuPG DSA: 0xD108493 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2020-01-22 8:23 p.m., Hongyi Zhao wrote:

May be I should depicted my method more detailed:

I only let the grub itself on a separate partition, with which I can boot the kernels located on the btrfs.

Err NO. NOT I have /boot where the bootable kernels live. There is a /boot/grub2 and all the other /boot/* But the /boot/initrd and /boot/vmlinuz and stuff are there. Where do you think the bootable kernels would reside if not on /boot? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2020-01-26 12:19 p.m., Dave Howorth wrote:

On Sun, 26 Jan 2020 09:20:03 -0500 Anton Aylward wrote:

...

On 2020-01-22 8:23 p.m., Hongyi Zhao wrote:

...

May be I should depicted my method more detailed:

I only let the grub itself on a separate partition, with which I can boot the kernels located on the btrfs.

Err NO.

Err, yes.

...

NOT

I have /boot where the bootable kernels live. There is a /boot/grub2 and all the other /boot/*

But the /boot/initrd and /boot/vmlinuz and stuff are there.

Where do you think the bootable kernels would reside if not on /boot?

The bootable kernels live in boot, which is part of the root partition

The point I was trying to make is that need not be the case. All of /boot and what lies underneath it, and there I agree with you, can quite reasonably reside on a seperate partitioon. I know this is possible since I am running a system like that, have been running a system like, ran a system like that even back when I just had the BtrFS for the rest of the file system. I can, after booting, unmount /boot. If I run 'zypper up' to download a new kernel or have other reson to run the few programs that update what's there, rebuild the grub menu or whatever, then, yes, it had better be mounted :-)

'/' and so do grub modules, but grub itself (the actual boot code) lives in /boot/efi/,

Depending on how you interpret what constitutes 'boot code'. There's stuff under /boot/grub2/ that comes into play as well :-)

which is the ESP (EFI System Partition) and is always formatted vfat on UEFI systems. The base grub understands enough to be able to load its modules from wherever, but the ROM that comes before grub doesn't.

I'm never happy with 'whatever' as an answer. I've been in system support and had to deal with phone calls and email from people who have mucked around with putting stuff in weird places, the 'whatever'. I want to see grub load its modules from under /boot/grub2 or whatever is appropriate for that version and revision of the OS. That you COULD put it on /mnt/mountable/mytoys/grubmodules doesn't mean you SHOULD. And especially not forget to tell phone support you've played such silly-bugger games with the 'whatever'. BT had the stupid buggers do stuff like that and yell at me when it doesn't work and stuff isn't where I tell them to look for it because they've moved it to 'whatever'. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sun, 26 Jan 2020 19:25:34 +0100 "jdd@dodin.org" wrote:

Le 26/01/2020 à 18:56, Anton Aylward a écrit :

...

All of /boot and what lies underneath it, and there I agree with you, can quite reasonably reside on a seperate partitioon.

and don't forget, on multi boot linux (no windows involved), the boot system can very well be on *an other distro*, so yes, in an other partition.

The point is that the initial boot code has to be able to run in the very limited environment the ROM provides it, and it subsequently has to be able to locate and read whatever filesystem on whatever disk or other storage (network maybe) contains the files of the to-be-run system. So the initial code of grub has to run from a filesystem that the ROM understands (i.e. vfat in the case of UEFI) whilst later stages of grub can use whatever filesystem drivers are built-in to the first stage or bootstrapped later in modules. So there's a fundamental difference between the initial boot code and later stages. And indeed the initial boot code doesn't have to be part of the filesystems of the eventually running OS, except it makes it convenient if it is for user-level tools to be able to modify the initial boot environment.

as of efi, it's not necessary to have efi code if your firmware have the compatibility code. I like pretty much UEFI, but if one want to have several openSUSE (for example) on the same computer, using EFI can be a bit tricky (not grub fault)

jdd

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2020-01-26 7:11 p.m., Carlos E. R. wrote:

Now, put /boot on different partition, and the feature can not work.

It depends on the 'whatever' that got updated. What gets updated when you get a kernel update is not the same as an update for anything else. I'm not running BtrFS but when I get a new kernel, an update via kernel_Stable, the earlier version stays around and the update to the grub config just alters the menu so that the new one becomes the default. I can still boot from the old one EVEN THOUGH I"M NOT USING BTRFS. # ls /boot/vmlinuz* /boot/vmlinuz /boot/vmlinuz-5.4.13-1.g5cf5394-default /boot/vmlinuz-5.4.11-1.g2d02eb4-default /boot/vmlinuz-5.4.14-1.gfc4ea7a-default /boot/vmlinuz-5.4.12-2.gcea1843-default Just as with BtrFS snapshots you can 'purge' old ones btrfs subvolume delete ..... The old kernels stay around until I 'purge-kernel'. How many kernels I keep at a purge is set in '/etc/zypp/zypp.conf' by the parameter 'multiversion.kernels' Because of this, you don't want the snapshot feature of BtrFS to snapshot the kernel updates & history (and that includes the corresponding kernel kernel modules). Yes, you could list them in the BtrFS configuration file as excluded directories. Yes, you could put up with the waste and pointlessness of the duplication. But please, the revision history mechanisms for the kernel exist quite independently from BtrFS. I don't use BtrFS but I do have the ability to boot from previous kernels for testing or if there is a problem with an update (as sometimes happens). -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 27/01/2020 à 01:11, Carlos E. R. a écrit :

You do not want to do this with btrfs. Not if you want its most brilliant feature, that of rolling up udates.

not useful for kernel updates, one can always boot the last kernel, and the main use is precisely *not* to update a kernel without thinking. if you plan to have the kernel/grub in an other folder than the default one, of course your better have finely tuned your config. my preferred BTRFS feature is the ability to change disk on a running system :-) jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26/01/2020 15.41, Anton Aylward wrote: | On 2020-01-22 11:50 a.m., Carlos E. R. wrote: |> | |> |> Probably the most salient feature of btrfs is snapshots; for this |> to work the entire system must be in a single partition. That is, |> after a failed update or change, grub allows you to boot the |> system that was previous to the update. With boot in a different |> partition, the kernel is out of reach of the snapshot, so the |> feature is broken. | | I deem it unnecessary. Unless and until you run 'purge-kernels' the | previous kernel and the libraries are still there. There is not | need for BtrFS snapshotting of them. In fact I'd make the case that | the kernels and all in /boot SHOULD be out of scope of BtrFS either | on a separate partition or by settings in the configuration Not the same feature by very far. It allows rolling back everything that was changed on the previous update, including the kernel and everything else in a single quick and easy operation. You may not like it, I don't, but it still is a brilliant feature. And the fact is, using a separate /boot partition breaks the feature. And Hongyi Zhao /is/ using btrfs, so let us not break it - unless he says he does want to break it, or explains that we have misunderstood. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXi7WtQAKCRC1MxgcbY1H 1QHhAJ4+OTEonwtZGSOHeeV20xIT+ZdKtACffBoeN9/Zzx1KtLymTdWehfceB58= =bgIw -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2020-01-27 at 10:50 -0500, Anton Aylward wrote:

On 2020-01-27 7:25 a.m., Carlos E. R. wrote:

...

Not the same feature by very far.

It allows rolling back everything that was changed on the previous update, including the kernel and everything else in a single quick and easy operation. You may not like it, I don't, but it still is a brilliant feature.

And the fact is, using a separate /boot partition breaks the feature.

Yes and that's my point, which you are missing. I do not want to roll back the kernel. I want to be able to boot from a previous kernel, one, two or more steps back, and move forward for the next boot. Maybe I'm debugging the new offering from Nvidia!

But that is irrelevant. It is not our case that matters, it is the OP's case. - -- Cheers, Carlos E. R. (from openSUSE 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXi9f4xwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfV4FcAn0FiBBqnVkKeBw7MWwcm POpDj+4SAKCXALyVyMrpT7ost5mpuBJdAvjj/Q== =o44F -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org