On Oct 22, 2014, at 3:14 PM, Stefan Huchler <stefan.huchler@xxxxxxx> wrote: > Chris Murphy <lists@xxxxxxxxxxxxxxxxx> writes: > > > So first of all, I am thankful that u helped me to understand the > problem I was shure I somehow on a interupted dnf process or something I > damaged something in fedora, because I did not remember or notice that > it did not update grub from the beginning. Based on a recent FESCO meeting it looks plausible this gets fixed in Fedora 21, but currently we're in feature freeze for beta so it's not yet merged. So we'll just have to see if it happens for final, once the beta ships. > >> >> 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. > > So the Grub people added this feature for nobody, for theoretical > persons who dont exist and me? The Btrfs folks wanted a sufficiently large pad to support embedding as no other filesystem actually supports this. ext has a tiny 2 sector bootloader pad that's just enough for block lists, it can't actually hold the full core.img for GRUB whereas Btrfs can. The thing is though, GRUB devs still prefer either the MBR gap or BIOSBoot on GPT because they really want a 1MB area to play with. > >> 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.) > > lets be real redhat devs are not really happy about uefi too, but they > dont see a way around it, because they cant force vendors to sell > different hardware, for me one reason to choose fedora over archlinux > was the commitment to free software, so hardwaredongels and proprietary > root-operating systems where linux run only as process 1 not 0 basicly > are not on my most-wanted list. I know bios had the same problems, but > at least they had less lines of code and did not do so much. FWIW Microsoft requires UEFI Secure Boot by default on workstations preloaded with Windows 8. There is a loophole allowing servers out of that requirement, and hence servers tend to ship as either BIOS, or UEFI systems with CSM-BIOS mode enabled (and Secure Boot disabled). So the idea Secure Boot is mainly about servers isn't correct. > BTW secure boot is a peace of shit, yes its for a few people a good > feature, but in reallity how many got such a bootloader rootkit > 0.000001% of all people? Ignorance is your choice. You are entitled to your own opinions, but you're not entitled to your own facts, and this definitely cross the line into willful ignorance and fact distortion. Companies do not spend hundreds of millions of dollars (conservatively estimated at this point) completely retooling firmware to something that has about as many lines of code as the linux kernel, and *requiring* manufacturers to enable a feature that obviates problems for a mere 5% let alone 0.000001%. It's just a stupid comment really, but I'll accept a certain lack of imagination about the malevolence and magnitude of things involved in the real world that has instigated the need for Secure Boot. So instead of just haphazardly responding with troll like language next time, either don't reply, or indicate you're capable of some level of critical thought why companies would have agreed to come together in the manner they have that doesn't involve lunatic asylum conspiracy theories. Thanks. (Because the loons have already spoken so much on this subject there is no possible way you could have an original variation on the theme.) > I never heard of anybody have such thing, it > happens maybe if nsa wants to crack some iran atom plants, but a normal > user cant even get affected because if they only use linux nobody finds > a executable linux file with such stuff on it, but it will make millions > of users complicate or they just will not install linux. There are rootkits in the wild, I will not google basic things like this for you. The whole reason why Secure Boot exists is to solve this problem, which is a MUCH MUCH MUCH bigger problem to Microsoft than the entirety of Linux. Linux is not even on the radar screen in comparison to bootloader malware over the time frames of support they have. And it is a linux problem too because without Secure Boot, a compromised linux kernel or kernel module can simply kvm boot Windows and we have exploited Windows running on exploited Linux and it's a completely silent unlogged event. This explanation isn't original it's been written about quite a bit for a long time, because massive piles of complicated (and hence buggy) code like UEFI don't just get written overnight because someone wants to be a dick to Linux users - that's paranoid delusion. > But ok I donnt want to flame here or something, just find it stupid that > there is a fix for grubby but nobody pulls that patch and integrates it > into fc21. Might happen. > > I just dont like it, that u cant make yourself a bootable system or fix > a broken grub2 because nobody understands anymore whats happen between > the 500 partitions with magic block sizes and 20 commands to 50 > different boot phases to them. grub2-mkconfig - it's a fairly easy work around to an annoying problem, it's not like it's some multipart sequence or one that requires additional reboots or actually coding shit, it's a static one size fits all command (granted different ones for BIOS and UEFI but that's another issue). Chris Murphy -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
