ring up this specific firmware
menu though...
Thanks,
--
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
for the foreseeable future, and users
will have to use the UEFI firmware's built-in boot manager for this
use case?
This seems related to thread: "How to boot Windows when Bitlocker
enabled with key sealed in TPM External"
https://lists.gnu.org/archive/html/grub-devel/2022-02/msg00
enu, which causes GRUB to use --bootnext to do a
one-time boot using that UEFI boot entry, thus loading that distro's signed
shim+GRUB combo.
Or, is this just not a priority for the foreseeable future, and users will
have to use the UEFI firmware's built-in boot manager for this u
On Fri, Mar 25, 2022 at 5:00 PM Chris Murphy wrote:
>
> On Fri, Mar 25, 2022 at 2:32 PM Vladimir 'phcoder' Serbinenko
> wrote:
> >
> > On Fri, Mar 25, 2022 at 9:14 PM Chris Murphy
> > wrote:
> > >
> > > For all practical purposes, this
On Fri, Mar 25, 2022 at 2:32 PM Vladimir 'phcoder' Serbinenko
wrote:
>
> On Fri, Mar 25, 2022 at 9:14 PM Chris Murphy wrote:
> >
> > For all practical purposes, this is functionally the end to dual boot
> > in GRUB, if there is no work around, e.g. bootne
For all practical purposes, this is functionally the end to dual boot
in GRUB, if there is no work around, e.g. bootnext. Is that the
direction GRUB maintainers want to go in?
--
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https
On Thu, Feb 10, 2022 at 12:29 PM Lennart Sorensen
wrote:
>
> On Thu, Feb 10, 2022 at 11:46:33AM -0700, Chris Murphy wrote:
> > On Thu, Feb 10, 2022 at 10:18 AM Lennart Sorensen
> > wrote:
> > >
> > > On Mon, Feb 07, 2022 at 04:48:43PM -0700, Chris Murph
On Thu, Feb 10, 2022 at 10:18 AM Lennart Sorensen
wrote:
>
> On Mon, Feb 07, 2022 at 04:48:43PM -0700, Chris Murphy wrote:
> > One idea I've heard floated is, having GRUB alter efivars such that
> > BootNext is changed to do a one time boot of Windows, instead of using
&
t;BootNext" for this use case? Or else I guess distros need to consider
removing the creation of a Windows menu entry, as there's no point
creating menu entries that don't work.
--
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.
be made unambiguous, I'm not
super fussy how that's done. The advantage of this is permitting
static creation of configuration files, less dependency on customized
configuration.
--
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
y will expand due
to the Windows 11 requirement that supporting hardware have TPM 2.0.
--
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Forgot to mention, I do see GRUB knows about "BIOS boot" partition
type guid, when it comes to the grub-install command. But I'm not sure
if GRUB as a concept of doing a search by arbitrary partition type
codes.
Thanks,
Chris Murphy
___
b.cfg much more generic and portable, searching
by partition types rather than by specific and unique file system or
partition UUIDs.
Thanks,
--
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
se. Or even make it explicitly a GRUB
bootloader partition type GUID. It's better if each bootloader has its
own? Originally BIOS Boot wasn't "owned" by GRUB, any bootloader can
use it, but insofar as I'm aware it's the only bootloader that uses
this partition typ
grubenv only for that purpose. I'd like to see
more consistency, fewer exceptions.
And that also means the old argument about the MBR gap. GRUB should
have its own partition here too.
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
On Thu, May 27, 2021 at 2:59 AM Michael Chang wrote:
>
> On Wed, May 26, 2021 at 08:36:05PM -0600, Chris Murphy wrote:
> > So is the next era going to be we recommend /boot on FAT?
>
> No. I meant a new partition type only for grubenv files and keep
> everything else as is.
On Wed, May 26, 2021 at 3:17 AM Michael Chang via Grub-devel
wrote:
>
> On Tue, May 25, 2021 at 04:58:23PM -0600, Chris Murphy wrote:
> > Hi,
> >
> > It's not possible for GRUB pre-boot environment to write to grubenv
> > when it's on Btrfs, ZFS, LVM,
On Wed, May 26, 2021 at 2:08 AM Konrad Rzeszutek Wilk
wrote:
>
> On Tue, May 25, 2021 at 04:58:23PM -0600, Chris Murphy wrote:
> > Hi,
> >
> > It's not possible for GRUB pre-boot environment to write to grubenv
> > when it's on Btrfs, ZFS, LVM, mdadm raid,
g
between the preboot and booted environments, which is the point of
grubenv, but it can't work much of the time due to the above
limitations.
--
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
volumes?
When I do 'ls (hdX)/' I consistently get an error from
efidisk.c:602:failure reading sector 0x80 for each of hd0, hd1, hd2,
hd3. For hd4 I get a different error which is fs.c:120:unknown file
system.
--
Chris Murphy
___
Grub-devel m
ce.
Photos of "lsefi" output
https://photos.app.goo.gl/pBxLJNdbzz6J9Vo56
--
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
On Sat, Nov 30, 2019 at 10:02 AM Chris Murphy wrote:
>
> Hardware:
> Macboo Pro 8,2 (2001)
> (1) Samsung SSD drive
> (1) internal DVD-ROM drive
> (2) USB 2, nothing external connected but built-in keyboard shows up
> as USB device
> (1) wired ethernet
> firmware,
[
On Sat, Nov 30, 2019 at 10:02 AM Chris Murphy wrote:
> SSD partition layout:
> 1 FAT32 EFI system partition (unused)
> 2 APFS (macOS)
> 3 HFS+ (used as ESP by Fedora)
> 4 Btrfs, sysroot
> 5 swap
> 6 Btrfs, sysroot
I goofed that up a bit:
1 FAT32 EFI system partition, unused
ernel to get it to support faster storage devices such as NVMe.
A possible use case would be resuming from a hibernation image.
--
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
ot either my Macbook Pro or my hp spectre (2016). I
have to MBR or GPT partition a USB stick, format it FAT32, and cp -a
the files onto it, that the HP will boot, still the Mac will not (that
2011 Mac will not USB boot with the CSM; CSM booting is only possib
.
Fedora ISO's use isohybrid and have multiple partitions on their ISOs:
MBR, GPT, and APM.
https://mjg59.dreamwidth.org/11285.html
--
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
more than the first 4 MiB are needed, let me know.
https://drive.google.com/open?id=1JgPv8EBHDn5A7hTEwewGK1MuFHvHbJnr
--
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
On Thu, Sep 27, 2018 at 10:38 AM, Daniel Kiper wrote:
> On Wed, Sep 26, 2018 at 04:45:51PM -0600, Chris Murphy wrote:
>> On Fri, Sep 21, 2018 at 12:35 PM, Daniel Kiper wrote:
>> > On Tue, Sep 18, 2018 at 01:40:06PM -0600, Chris Murphy wrote:
>> >> On Mon, Sep 17,
On Fri, Sep 21, 2018 at 12:35 PM, Daniel Kiper wrote:
> On Tue, Sep 18, 2018 at 01:40:06PM -0600, Chris Murphy wrote:
>> On Mon, Sep 17, 2018 at 10:59 PM, Chris Murphy
>> wrote:
>> > Hi,
>> >
>> > GRUB code can certainly read files that are on Btrfs,
On Mon, Sep 17, 2018 at 10:59 PM, Chris Murphy wrote:
> Hi,
>
> GRUB code can certainly read files that are on Btrfs, md devices,
> LUKS, LVM, and so on. But GRUB code can also write to the physical
> block for grubenv - but are there safe guards that prevent it from
> doing s
? This used to be safe, but now with reflink
support, grubenv could be reflink copied, meaning any overwrite is
disallowed and must be COW'd. How is that handled?
I'm pretty sure on Btrfs GRUB knows is can't write to grubenv, I'm
just curious about the other case
thank you for posting the patch. LGTM.
>
> Chris, may I ask you to test it and add your "Tested-by:" if it works?
Fedora openQA (which caught the bug) now passes. I did a separate test
making sure sparse inode feature is enabled and grub-probe,
grub-install, grub-mkconfig
On Tue, May 15, 2018 at 6:33 AM, Daniel Kiper wrote:
> Hi,
>
> On Mon, May 14, 2018 at 01:12:27PM -0600, Chris Murphy wrote:
>> Hi,
>>
>> xfsprogs 4.16.0 defaults to enabling "sparse inode" which is not
>> compatible with GRUB.
>>
>> Dow
pproximate time frame for getting this
fixed, to know whether for Fedora 29 /boot on XFS should be inhibited
until a proper tested patch for GRUB exists.
Thanks,
--
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
s a lot better
than nothing. I really don't think it's ok for grub-mkconfig to assume
something else is going to properly sync, unmount, or remount-ro whatever
file system the grub.cfg is being written to. grub-mkconfig needs to take
responsibility for its own action, and ensure complete and
paths are not really subvolumes. I hope that makes sense...
If grub-probe does not parse for subvol= then that's not likely the
problem here.
--
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
error: cannot find a device for / (is /dev
mounted?).
[root@localhost /]#
--
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
o as if whatever it finds there is not at
all helpful.
inside
< 693 225 0:6 / /dev rw,nosuid shared:22 - devtmpfs devtmpfs
rw,seclabel,size=3999060k,nr_inodes=999765,mode=755
outside
> 21 71 0:6 / /dev rw,nosuid shared:22 - devtmpfs devtmpfs
> rw,seclabel,size=3999060k,nr_ino
5f8fd37.0/
btrfs
# chroot
/mnt/sysimage/ostree/deploy/fedora-workstation/deploy/e52f5de4c5d3f52211ab216d5bf5331b81c929e967f9cbfcba3ad85e45f8fd37.0/
# grub2-probe /
grub2-probe: error: cannot find a device for / (is /dev mounted?).
--
Chris Murphy
___
G
On Thu, Jan 7, 2016 at 4:10 PM, Filipe Manana wrote:
> On Thu, Jan 7, 2016 at 10:05 PM, Chris Murphy wrote:
>> On Thu, Jan 7, 2016 at 12:16 PM, Filipe Manana wrote:
>>> On Thu, Jan 7, 2016 at 7:11 PM, Andrei Borzenkov
>>> wrote:
>>>> As discussed on o
using by referring to MBR, which mainly
exists only at LBA 0. In the case of extended partitions, the EBR
(using the same MBR format) is still outside the LBA range for Btrfs
to apply fitrim ioctl. The VBR however, would be inside that range,
and it's that 64KiB boot
Are these two equivalent, or identical? And if so, which is preferred?
grub2-install --no-bootsector
grub2-install --grub-setup=/bin/true
Thanks,
--
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo
On Nov 3, 2014, at 9:50 PM, Michael Chang wrote:
> On Mon, Nov 03, 2014 at 01:04:33PM -0700, Chris Murphy wrote:
>>
>> Well, Btrfs raid1 might make sense for some of them but opensuse will
>> constrain people from multiple device btrfs. So you can just disallow them
>
On Nov 3, 2014, at 10:50 PM, Andrei Borzenkov wrote:
> В Mon, 3 Nov 2014 14:05:24 -0700
> Chris Murphy пишет:
>
>>
>> On Nov 3, 2014, at 1:29 PM, Andrei Borzenkov wrote:
>>
>>> В Mon, 3 Nov 2014 12:36:24 -0700
>>> Chris Murphy пишет:
>&g
On Nov 3, 2014, at 1:29 PM, Andrei Borzenkov wrote:
> В Mon, 3 Nov 2014 12:36:24 -0700
> Chris Murphy пишет:
>
>>
>> On Nov 2, 2014, at 10:36 PM, Andrei Borzenkov wrote:
>>
>>> В Sun, 2 Nov 2014 15:19:43 -0700
>>> Chris Murphy пишет:
>&g
placed on filesystem.
OK fine, but this just adds to the already complicated matrix of GRUB MBR
installations, to have yet another fallback for yet another special case. This
proves the primary case is broken that so many fallback methods are even
necessary. Already the ESP and BIOSboot workflows are vastly more reliable, and
completely consistent regardless of the filesystems being used. It's the MBR
gap workflow that's busted. If the primary use case is fixed, most use cases
will inherit the benefit with no additional work or testing.
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
On Nov 2, 2014, at 10:36 PM, Andrei Borzenkov wrote:
> В Sun, 2 Nov 2014 15:19:43 -0700
> Chris Murphy пишет:
>
>>
>> On Nov 1, 2014, at 11:37 PM, Andrei Borzenkov wrote:
>>>
>>> So far nobody suggested solution for grubenv on unwritable loca
On Nov 2, 2014, at 10:31 PM, Andrei Borzenkov wrote:
> В Sun, 2 Nov 2014 15:11:29 -0700
> Chris Murphy пишет:
>
>>
>> On Nov 1, 2014, at 11:27 PM, Andrei Borzenkov wrote:
>>
>>> В Sat, 1 Nov 2014 14:35:57 -0600
>>> Chris Murphy пишет:
>>&
On Nov 1, 2014, at 11:37 PM, Andrei Borzenkov wrote:
> В Sat, 1 Nov 2014 19:34:56 -0600
> Chris Murphy пишет:
>
>>
>> On Oct 30, 2014, at 6:42 AM, Andrei Borzenkov wrote:
>>>
>>> I still believe this is more flexible; in particular, /boot/grub on
On Nov 1, 2014, at 11:27 PM, Andrei Borzenkov wrote:
> В Sat, 1 Nov 2014 14:35:57 -0600
> Chris Murphy пишет:
>>
>> Why not have a dedicated partition with MBR type code for core.img,
>> equivalent to BIOSBoot currently used on GPT? freedesktop.org has a proposal
ate /boot on ext was fine as a short/medium term work around, but
/boot on btrfs has use case benefits so it really needs to work eventually.
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
is purpose (in part). The boot.img code in the MBR can
arbitrarily jump to any LBA, so 0xEA doesn't need to be a primary partition
does it?
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
On Oct 27, 2014, at 6:34 PM, "Sun, Ning" wrote:
> Hi,
> I encountered an error when installing grub 2.00 on my Linux system(boot from
> EFI BIOS), the error showed “source_dir doesn't exist. Please specify
> --target or –directory”
> The error occurred after I run this command:
> #grub-install
On Oct 27, 2014, at 12:01 PM, Andrei Borzenkov wrote:
> В Mon, 27 Oct 2014 10:30:31 -0600
> Chris Murphy пишет:
>
>>
>> On Oct 27, 2014, at 1:39 AM, Andrei Borzenkov wrote:
>>
>>
>>
>>> It does not look like anything needs to
>>&g
On Oct 27, 2014, at 11:46 AM, Mike Gilbert wrote:
> ./configure --build=x86_64-pc-linux-gnu
OK so do ./configure --build=x86_64-pc-linux-gnu --platform=efi
?
Passing only --platform=efi did seem to work: it compiled and grub-install
works.
Chris Mur
otloader, so that the built-in firmware boot manager
displays it as a boot option at start up time (which it doesn't do if the EFI
binary is on the EFI System partition).
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
On Oct 26, 2014, at 10:06 PM, Chris Murphy wrote:
> OK I've got this working. The problem was user error. Explicitly setting root
> is necessary, and I've updated the bug.
> https://savannah.gnu.org/bugs/index.php?42954
>
> So the approach of chainloading Apple&#x
an it be used. By putting grubx64.efi on hfsplus, and tricking the firmware
into thinking it's an OS X bootloader, we get a prettier user friendly linux
boot experience on Macs.
[1] partitiontype GUID 426F6F74--11AA-AA11-00306543ECAC
[2] partitiontype GUID 484653
rm=efi ;;
I guess $target_vendor isn't getting set to apple and therefore platform
doesn't get set to efi.
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
and tab won't
autocomplete; whereas chainloader does tab autocomplete and I'm able to
navigate to the boot.efi file.
And I also note that Recovery HD (Apple Boot partition type GUID) contains two
bootloaders:
/System/Library/CoreServices/boot.efi
/com.apple.recovery.b
On Oct 24, 2014, at 12:50 PM, SevenBits wrote:
> On Friday, October 24, 2014, Chris Murphy wrote:
> We need to re-evaluate how GRUB will boot OS X for the following reasons:
>
> 1. Apple OS X 10.10 (just released) now by default converts for existing, and
> new installs, the p
rsion (?) but
isn't anymore and I'm not sure why.
https://savannah.gnu.org/bugs/?42954
https://bugzilla.redhat.com/show_bug.cgi?id=1128374
Once the Apple bootloader is chainloaded, it can of course read Core Storage
volumes, encrypted or not, and properly ask for user authenticatio
ned grubx64.efi to each ESP, and
place a grub.cfg [1] on each ESP that forwards to the "real"
/boot/grub/grub.cfg on the md device. But how does upstream intend this to be
done with existing tools?
Chris Murphy
[1]
# forward to real config
search --no-floppy --fs-uuid --
On Jan 17, 2014, at 5:01 AM, joe faith wrote:
>
>>
>> - Original Message -
>> From: Chris Murphy
>> Sent: 01/16/14 11:55 PM
>> To: The development of GNU GRUB
>> Subject: Re: [RFC] Allow separate boot block and core.img location?
>>
>
On Jan 16, 2014, at 7:13 PM, joe faith wrote:
>
>>
>> - Original Message -
>> From: Chris Murphy
>> Sent: 01/16/14 04:04 PM
>> To: The development of GNU GRUB
>> Subject: Re: [RFC] Allow separate boot block and core.img location?
>>
LBA to load. If that's the case core.img could be
in an extended partition. And once GRUB is running, it doesn't care about
primary or extended partitions anyway, right?
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
On Jan 12, 2014, at 10:13 PM, Michael Chang wrote:
> 2014/1/10 Chris Murphy :
>>
>> On Jan 9, 2014, at 3:03 AM, Michael Chang wrote:
>>>
>>> cat < /boot/efi/EFI//grub.cfg
>>> search --fs-uuid --set=root `grub-probe --target=fs_uuid /boot/grub`
>
On Jan 9, 2014, at 3:03 AM, Michael Chang wrote:
> 2014/1/9 Chris Murphy :
>>
>> On Jan 7, 2014, at 10:55 AM, Chris Murphy wrote:
>>
>>>
>>> On Jan 1, 2014, at 10:17 PM, Michael Chang wrote:
>>>>
>>>> We snapshot /boot for
On Jan 7, 2014, at 10:55 AM, Chris Murphy wrote:
>
> On Jan 1, 2014, at 10:17 PM, Michael Chang wrote:
>>
>> We snapshot /boot for kernel and initrd, otherwise the rollback would
>> encounter problem of incompatible userland and kernel/kernel modules.
>> And w
's in fstab. It
can use name substitution to do the same thing with the other
subvolume-snapshots that match the root one. Meaning all of the snapshots for a
system have the same base (re)naming convention.
Chris Murphy
___
Grub-devel mailing list
;> On Mon, Dec 23, 2013 at 08:43:34PM -0700, Chris Murphy wrote:
>>>>>
>>>>> On Dec 23, 2013, at 7:26 PM, Michael Chang wrote:
>>>>>
>>>>>> Now I tend to agree that supporting config for snapshot booting
>>>>>>
On Dec 23, 2013, at 9:20 PM, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> On 24.12.2013 04:43, Chris Murphy wrote:
>> d point. Your snapshot tool could first create a read only snapshot, then
>> for no space
>> cost also create a rw snapshot of the
On Dec 23, 2013, at 8:46 PM, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> On 24.12.2013 04:43, Chris Murphy wrote:
>> Another thing to note is that there are UEFI computers shipping that don't
>> have USB initialized by the firmware by default at boot time. So
your kernel parameters are asking to mount it as /.
Yes good point. Your snapshot tool could first create a read only snapshot,
then for no space cost also create a rw snapshot of the read only one, then add
the rw snapshot to the grub.cfg. The tool c
On Dec 22, 2013, at 10:32 PM, Chris Murphy wrote:
>
> If relative paths are used, neither core.img nor grub.cfg needs to be
> modified, because merely a user space program changing the default subvolume
> would cause the existing core.img and grub.cfg to boot the snapshot.
This
On Dec 22, 2013, at 9:52 PM, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> On 23.12.2013 05:45, Chris Murphy wrote:
>> As for grub's part in the solution, it seems like it would need to
>> understand absolute paths to subvol 5, as well as relative paths to the
that point. It's no different than being in chroot, or mounting a partition and
being unable to navigate into other partitions. 'btrfs subvol set-default'
requires both and a .
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
enance
of that snapshot is obliterated.
And with all of these snapshots being created, something to clean up all these
bouquets is necessary. Do we really want GRUB doing that also? I just this this
is out of scope for GRUB.
An FHS for Btrfs installation locations and shapshot behaviors is p
to happen.
I'm also going to opine that knowledge of configfile, is about as obscure as
changing the btrfs default subvolume. I think if someone knows about
configfile, even though it's orthogonal to btrfs, that they will have some idea
how to troubleshoot or where to go to get help if boot breaks as a result of
this change.
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
to know what
they're doing in this realm of computing. It's complicated enough that even
individual experts have developed highly specialized knowledge that their peers
don't have.
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.or
On Dec 9, 2013, at 5:55 PM, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> On 10.12.2013 01:11, Chris Murphy wrote:
>>
>> Technically if the alternate is invalid by being in the wrong location
>> (either end of disk or where the primary header says it should
On Dec 9, 2013, at 4:37 AM, Colin Watson wrote:
> On Sat, Dec 07, 2013 at 04:42:02PM -0700, Chris Murphy wrote:
>> Encrypted /boot seems to be an edge case, at least for x86 UEFI
> [...]
>
> GRUB supports many platforms; an issue with a single one, even if it's
>
So maybe it can be argued the firmware has a role to play in fixing up GPT? Or
maybe this is a hideously bad idea for firmware, which as we know is slightly
less than massively bug ridden, to have such write privileges to the disk.
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
boot.
Anyway, I'm uncertain about the benefit of encrypted /boot. If boot files are
supposed to be protected from modification then that's what secure boot is for.
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
On Nov 27, 2013, at 11:31 AM, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> On 27.11.2013 19:26, Andrey Borzenkov wrote:
>>
>> Any progress on it?
> What is the exact panic message?
http://savannah.gnu.org/bugs/?39460
Chris Murphy
__
On Oct 23, 2013, at 7:58 PM, Chris Murphy wrote:
>
> On Oct 23, 2013, at 6:37 PM, FireIcer wrote:
>
>> I am looking at the impact in general with changing the grub-mkconfig
>> scan not to pickup and update the grub.cfg with the UUID code but the
>> PARTUUID code
On Oct 24, 2013, at 7:39 AM, "Lennart Sorensen"
wrote:
> On Wed, Oct 23, 2013 at 09:07:21PM -0600, Chris Murphy wrote:
>> While technically a violation of the UEFI spec, I think this can be worked
>> around by considering the disk GPT if the first entry in the MBR
Thanks for the response:
On Oct 23, 2013, at 7:49 PM, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> On 24.10.2013 03:38, Chris Murphy wrote:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1022743
>>
>> Gist is, starting with a disk with valid PMBR, primary GP
anymore; and further assumes
the GPT UniquePartitionGUID is not changed.
I think that combination is possible but probably not really common. I think
the common case is a drive dies and it's going to get all new UUIDs in any case.
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
https://bugzilla.redhat.com/show_bug.cgi?id=1022743
Gist is, starting with a disk with valid PMBR, primary GPT, and backup GPT, if
I zero LBA 2, I can no longer boot from the disk. I get a grub rescue prompt.
Instead, if I merely corrupt a portion of the first partitiontypeguid to mimic
corrupt
On Oct 15, 2013, at 8:50 PM, Andrey Borzenkov wrote:
> В Mon, 14 Oct 2013 14:20:14 -0600
> Chris Murphy пишет:
>
>>
>>> Is there a way to detect that mountinfo gives garbage and somehow get
>>> where the real root points?
>>
>> I don't know
On Oct 15, 2013, at 8:45 PM, Andrey Borzenkov wrote:
> В Tue, 15 Oct 2013 13:47:14 -0600
> Chris Murphy пишет:
>
>>
>>> I'm not sure when and how top level may become != 5.
>>
>> starting where you left off with the sub2 subvolume mounted
>>
om top level 5 subvolume. That makes
things more clear and less complicated and also won't break bootability if the
user wants to e.g. always mount their current home subvolume by default, then
nothing else is affected.
Chris Murphy
___
Grub-deve
On Oct 15, 2013, at 2:02 PM, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> On 15.10.2013 21:47, Chris Murphy wrote:
>>
>> On Oct 15, 2013, at 10:58 AM, Andrey Borzenkov wrote:
>>
>>>
>>> I do not know whether it was the case in the pas
ubvol create /mnt/nested
# btrfs subvol list /mnt
ID 262 gen 135 top level 5 path dir1/sub1
ID 263 gen 140 top level 5 path dir2/sub2
ID 264 gen 140 top level 263 path nested
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
On Oct 14, 2013, at 8:33 PM, Andrey Borzenkov wrote:
> В Mon, 14 Oct 2013 22:50:10 +0200
> Vladimir 'φ-coder/phcoder' Serbinenko пишет:
>
>> On 14.10.2013 22:45, Chris Murphy wrote:
>>>
>>> On Oct 14, 2013, at 1:29 PM, Vladimir 'φ-coder/phcoder
On Oct 14, 2013, at 5:09 PM, Chris Murphy wrote:
>
> On Oct 14, 2013, at 3:01 PM, Vladimir 'φ-coder/phcoder' Serbinenko
> wrote:
>
>> On 14.10.2013 22:45, Chris Murphy wrote:
>>>
>>> On Oct 14, 2013, at 1:29 PM, Vladimir 'φ-coder/phcoder&#
On Oct 14, 2013, at 3:01 PM, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> On 14.10.2013 22:45, Chris Murphy wrote:
>>
>> On Oct 14, 2013, at 1:29 PM, Vladimir 'φ-coder/phcoder' Serbinenko
>> wrote:
>>
>>>> So it seems tha
nge grub-mkrelpath to match runtime behaviour.
> Is there a way to detect that mountinfo gives garbage and somehow get
> where the real root points?
Here's the response. It seems similar but not identical to what you described
above.
http://www.mai
pt subvolume in a subvolume, another a subvolume in a
directory): in both cases /proc/self/mountinfo reports / as the root, not the
full path or ID of the subvolume actually mounted.
Somehow it seems like the mountinfo root field should return a block device and
full path to th
1 - 100 of 163 matches
Mail list logo
