dracut/grubby fails to update grub.cfg

[Chris Murphy]

On Oct 22, 2014, at 10:48 AM, Stefan Huchler <stefan.huchler at mail.de> wrote:

> Chris Murphy <lists at colorremedies.com> writes:
> 
>> 
>> Again if you're using modern utilities, you don't have to know any of
>> these things, alignment is a solved problem. My point is that Btrfs
>> doesn't do anything differently than other filesystems in this regard,
>> which is exactly nothing. It all depends on an earlier tool aligning
>> the partition on the physical sector boundary.
> 
> is fdisk one of this modern utilities?

It depends on the version so you'd have to go through the changelogs. But yes, if it's an fdisk within the last few years, it will begin partition 1 at LBA 2048 and thus it is aligned. Another factor is to specify the partition size in whole MiB or GiB, to ensure subsequent partitions are aligned.

>> 
>> Rootkit immunity. Chain of trust. Why should only Windows users get these things? 
>> 
> 
> rootkit immunity, I guess thats a technical term that means something,
> but it cant mean what it suggest, u cant prevent complelty rootkits by
> any technology, only if you make your harddrives complelty readonly or
> something.

This is the point of Secure Boot.


> 
> or it can help you to notice a rootkit or prevent some special kind of
> rootkit, but uefi cant make rootkits impossible, sorry but this words
> sounds like that.

UEFI itself doesn't, UEFI Secure Boot does.

> Its basicly a server only feature, no normal desktop user uses 1000 console
> tools to check if there is a rootkit or something, thought redhat and
> centos is for servers and fedora primary for desktop.

UEFI isn't a server only feature. It's mandatory now for new desktops if the manufacturer wants to put a Windows 8 compatible sticker on it, which most of them do. And it's not just servers that get bootloader malware.
> 
> 
>> Right, so you're depending on the Btrfs 64KB bootloader pad (offset)
>> for GRUB core.img to reside on, and thus boot the system. That's fine,
>> but this isn't a supported layout by Fedora in that the installer
>> won't let you create such a system, so you're kinda on your own at the
>> moment.
> 
> I get taht this is no blocker bug, but do you ignore all issues that are
> no blockers?

It's a matter of emphasis, and allocating finite resources. There's a good chance this one gets about zero other than what upstreams put into enabling it. And right now it's not possible to use the Fedora graphical installer to create the layout you have, so that's about as close to not supported as it gets.



> I installed several gentoos in the past and arch linuxes
> and stuff, so I am able to install stuff by my own and can setup the
> grub stuff and so on. So now that I am a fedora User I should forget all
> that and only use the official installer? Or I get no support?

OK but you're on a list asking about why grubby fails to update grub.cfg and you don't like any of the work arounds suggested, while you're saying you can do this all on your own. People are busy, and I can't tell you for sure that the patches for grubby to fix this problem won't be in Fedora 21. They might get there. If not, then hopefully for Fedora 22. The suggested time frame now for Btrfs by default is Fedora 23, and that's probably pretty realistic considering the state of Btrfs development.

> 
>> Fedora Project, and by support it means an issue we'd block release on
>> if it didn't work correctly. You can do what you want by having /boot
>> on ext4 and the rest of your OS on / on Btrfs, and grubby will
>> properly update grub.cfg without complaints. If you insist on having
>> /boot on Btrfs, then right now you either have to use an out of tree
>> grubby or you need to manually use grub2-mkconfig -o, etc.
> 
> Yes but BTRFS is the future, there will be no ext4 boot partitions in a
> few years because everybody only uses btrfs in a few years like
> everybody uses ext4 only today (a few special server cases apart) so
> good btrfs support shhould be a goal.

Well, opensuse still uses ext3, not ext4, by default. And Fedora Server and RHEL 7 are now defaulting to XFS. So, I'm going to use those facts to refuse your premise that Btrfs will be the default in a few years for everyone. We've been hearing Btrfs by default since Fedora 16, by the way.

> BTW I did not even ask for a definite quick patch for fedora, I just
> wanted a workaround.

grub2-mkconfig everytime is a work around. So is putting /boot on ext4.

> 
> And yes maybe I am a year ahead, to what everybody will do in a year,

What you're doing isn't likely to ever be supported, because it's a non-partition disk. Right now and for the foreseeable future, the supported layouts will be MBR partitioned on BIOS systems when drives are < 2TB; and GPT in all other cases.


> I
> tend to be a bit early adopter somethimes (if its not useless garbage
> like uefi), I think when legacy is dead I will only buy hardware that is
> patchable by coreboot, or maybe we will see finaly a market of coreboot
> preinstalled hardware, then this technology which main focus is to fight
> linux aka uefi and secure-anti-linux-boot will go away. I will not buy
> it if possbile.

By the way, the GPT partition scheme is defined in UEFI, so good luck totally avoiding it (you can avoid it if you don't need to partition large drives but many people do need to.)


Chris Murphy