How can we make F17 be able to boot on Macs (with or without reFit)
First post. I stumbled across this subject while performing an unrelated search. I have found EFI booting Apple hardware is problematic on the two models I've tested. I think these are kernel related problems that would need to be sorted out to get a full boot and startup to a GUI login. CSM-BIOS boot works OK on these models. Apple hardware tested: mbp41 = MacBookPro 4,1 (2008), Nvidia Geforce8600M GT. mbp82 = MacBookPro 8,2 (2011), Intel HD Graphics 3000 and AMD Radeon HD 6750M. 1. mbp41 booting is inconsistent. Without additional kernel parameters I generally end up with one of three results: successful boot to GUI login window; hang at nouveau (dmesg points to VBIOS corruption having occurred very early during boot); hang when unpacking initramfs (possibly the same intermittent corruption of VBIOS, causes corruption when unpacking initramfs). With 'nomodeset' I usually am able to boot and complete startup except for x. So it's a text only situation. But all other function appears reliable. https://bugzilla.redhat.com/show_bug.cgi?id=751147 2. mbp82 booting of kernel and initramfs appears to work 100% of the time. However immediately after a GRUB menu item is chosen, GRUB-EFI vanishes and is replaced with garbage on the screen. I speculate that in this boot mode, both video adapters are active at the same time and are conflicting maybe? In any event, I can't see anything. But it is possible to ssh into the computer or blindly type commands and they all appear to work. https://bugzilla.redhat.com/show_bug.cgi?id=765954 Also, all EFI testing I've done is without rEFIt as I feel it adds another layer of unknowns to the process. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
How can we make F17 be able to boot on Macs (with or without reFit)
Volume 2 CSM-BIOS boot notes: Apple hardware tested: mbp41 = MacBookPro 4,1 (2008), Nvidia Geforce8600M GT. mbp82 = MacBookPro 8,2 (2011), Intel HD Graphics 3000 and AMD Radeon HD 6750M. All notes based on booting with the Apple-EFI option-key startup menu to choose how to boot, not rEFIt. 1. After default install using any installation type, and reboot, neither model loads GRUB2 (and thus does not boot) by default. Pre or post-install work is needed. 2. Both models CAN boot and startup Fedora to a GUI login with pre- or post-install work. a. 'nogpt' kernel parameter for Fedora only installs produces a bootable system without post-install work. b. In dual-boot (Mac OS + Fedora) anaconda isn't creating a hybrid MBR post-install, therefore Apple's EFI startup disk menu doesn't see the F16 installation. Further, creating the hybrid MBR in advance is useless as parted wipes out the hybrid MBR in favor of a protective MBR just prior to installation. (See 3 below for additional fallout of this behavior.) c. Triple boot (Mac OS, Fedora, Windows) is possible, but there are more ways this won't work, than will work. And more ways that will work, but aren't good partition schemes (invitations for data loss) since there really isn't such a thing as a safe hybrid MBR + GPT. I have found one or two that I think are about as "safe" as they can get, and it means that the user needs to install Mac OS, Windows, Fedora, in that order, but located on the disk in order: Mac OS, Fedora, Windows. 3. Anaconda + parted consistently remove pre-existing hybrid MBRs, replacing them with protective MBRs. The hybrid MBR will exist in a case where Windows has already been installed (using Apple's Bootcamp application). If removed in favor of a protective MBR, Windows is no longer bootable. So not only is Fedora not bootable, a previously bootable Windows is no longer bootable. This happens with either EFI or BIOS mode installs of Fedora. So either anaconda needs to proceed no further upon discovery of a hybrid MBR, or it needs to become pretty good at sorting out hybrid MBR and GPT schemes that are "safe". 4. gptsycnc: I don't think gptsync has such a sophisticated heuristic for creating such hybrid MBRs - I regularly see it produce very linear MBRs while suggesting huge percentages of the disk are empty. Any MBR only aware tool would see these areas as fair game - what I call an invitation for data loss and probably not a good idea. 5. If all requirements are met, Apple's startup disk menu (option-key at startup chime) will present a single "Windows" disk icon which if selected will load GRUB2 and its menu. That "Windows" label is apparently hard coded in Apple's EFI for any foreign OS requiring legacy CSM-BIOS booting. Additional EFI boot notes: 1. By default EFI//EFI/redhat/grub.efi isn't found by Apple's EFI and install a choosable option. If it and the .conf are moved to EFI//EFI/BOOT/BOOTX64.efi and .conf, both models have an "EFI Boot" labeled disk icon in the option-key startup menu. I'm guessing like the "Windows" equivalent, that "EFI Boot" is hardwired. This is being addressed by this: https://bugzilla.redhat.com/show_bug.cgi?id=755093 2. GRUB-EFI (legacy) regularly just hangs are loading the kernel and initramfs, on mbp41. I don't have this problem with GRUB2-EFI but I still have other problems mentioned in the previous email. Chris Murphy-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How can we make F17 be able to boot on Macs (with or without reFit)
Responding to my own email on various boot behaviors, with some editorialization. EFI vs CSM-BIOS: EFI boot produces highly variable results between Apple models, while CSM-BIOS boot is very consistent between Apple models. Windows 7 will not boot in UEFI mode on Apple hardware. I have searched thoroughly and have found no success stories so far. Even if it has been done, it's outside of what normal people are willing or able to do. Yet CSM-BIOS booting works fine on all of Apple's hardware for the past 4-5 years. This makes some sense, because Microsoft says they explicitly support UEFI 2.x and higher only, while Apple's firmware is based on Intel EFI 1.10, not UEFI 2.x. CSM-BIOS boot is not ideal. But it's also not ideal to support a flakey EFI boot scenario that may take a lot of effort for low efficacy. Also consider Mac users are running into the BIOS-MBR 2.2TB limit on Apple hardware. It stands to reason Apple will need to make some modifications to their EFI implementation to deal with this eventually. This accommodation of Windows (U)EFI requirements may be good for linux, or may be bad for linux. I think investing in Apple EFI unknowns is risky. Further, consider CSM-BIOS has the best chance of supporting Fedora when Apple releases new hardware. It may take months or years to support the peculiarities of each model's EFI. So if I were voting, I'd suggest a constrained type of support for CSM-BIOS boot, both Fedora only (atypical) and dual boot (typical). Triple Boot: This is possible, I've done it with several combinations, but it's non-trivial. I question if gptsync is at all appropriate for making sure the resulting hybrid MBR and GPT aren't a disaster (more often than not gptsync produces ill advised hybrid MBRs, more so than they already are). The big gotcha with triple boot support, is that the most common situation is the existence of Mac OS and Windows, which means there is a hybrid MBR and GPT. This means a Fedora installation must make sure both an appropriate MBR and GPT are produced not merely so that all three systems to boot as expected, but to ensure neither of the previously working systems become unbootable. Today this is not the case with Fedora 16. Anaconda+parted blow away such a hybrid MBR in favor of GPT only with protective MBR, the result of which is an unbootable Windows (Mac OS remains bootable). Even refusing to install Fedora (or a warning about the consequences) would be a much needed improvement here. A bit about Apple's philosophy: Apple doesn't sell hardware. They don't sell operating systems. They sell an experience that combines both. That's how they see it. The two are inseparable. At best they "tolerate" Windows support, and not just any Windows, only Windows 7 is supported for the better part of a year now. I have zero doubt they'd be baffled by the idea anyone would want to run linux on a Mac, and would not care one single bit if it could not be done with either EFI or CSM-BOOT modes. This is the hallmark company that does not believe users have any right to boot an operating system of their choice on any hardware they produce. People who buy Apple hardware today cannot even run the most recent previous version of Mac OS 10.6.8 (released July 28 2011) - it simply won't boot on their hardware. I am leery of excessive amounts of effort, which in effect is a kind of turd polishing, to deal with Apple's non-standard EFI. I don't like being relegated to CSM-BIOS mode booting, but it does work, with well understood limitations. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How can we make F17 be able to boot on Macs (with or without reFit)
On Dec 26, 2011, at 5:55 PM, Todd V Orvieto wrote: > Chris, > I got really frustrated with triple boot on Max OS X Lion. At one point I > had it working on snow leopard pretty well. A possible problem with Lion is not technically with Lion itself. When 10.7 is installed, there is an additional partition created called Recovery HD, which contains a minimal system for booting a limited environment. Because of this, out of the gate you have at least three partitions: sda1, sda2, sda3. You can only add one more partition and have parity with a hybrid MBR and I'll bet gptsync does this incorrectly. And there are also 2.2TB concerns because of course the Windows partition can't go beyond the 2.2TB limit. So how the MBR should look in a triple boot, is unique. I've done probably 2-3 dozen installs and figured out one that's ideal for less than 2.2TB disks, and one or two that are tolerable, but still gross lies, for 2.2TB+ drives. It also requires giving up on the Windows bootloader and use GRUB2 for bootloading both Windows and Fedora. > My buddy who works for Apple has told me that the installation of refit voids > the warranty and they have refused to fix computers under warranty with refit > installed. Well that's completely bogus. I've heard this myth before, I don't know where it started. I think some traveling support crew probably were misinformed that rEFIt is an EFI firmware replacement, and if it were true that people were flashing Apple's firmware with some 3rd party firmware, they'd be able to void warranties. But rEFIt is not firmware, it's a set of EFI applications and drivers. So whoever says this is completely full of crap and doesn't know what they're talking about. > I think this is bummer because the Apple hardware is good, it makes no sense > why Apple cares. Apple doesn't care to support foreign OS's. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Does anyone still need to create legacy HFS filesystems?
On Feb 2, 2012, at 5:25 PM, David Lehman wrote: > > My understanding is that the so-called "Apple Bootstrap" filesystem > required for ppc Macs to boot is HFS. That's what anaconda uses for it. > If we could be using HFS+ instead, fine. PPC Macs could only boot using HFS+ since Mac OS X 10.0 shipped in 2001 because HFS did not support file system permissions, etc. PPC Macs could boot from either HFS or HFS+ with previous versions of Mac OS. 680x0 CPU Macs could only boot using HFS. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Does anyone still need to create legacy HFS filesystems?
On Feb 2, 2012, at 6:45 PM, John Reiser wrote: >> Does anyone object [to dropping support for HFS]? > > Plain HFS has no journal, so there are workloads where HFS is faster > than HFS+ which has a journal. Mac OS Extended or HFS+ or HFS Plus, does not inherently have a journal. There is a separate variant called Journaled HFS+ (acronym appears as HFSJ or jhfs+). There is yet another variant called HFSX which is case-sensitive, but also has more feature potential than HFSJ. For nearly nine years Apple's tools have only created HFSJ/jhfs+ by default. > Is it economical to cater to such cases? > Probably not. However, I do have a PowerPC Mac Mini that runs plain HFS > and Fedora 10 with ext3. Are you sure you mean HFS? The original maximum volume size for Mac OS Standard (HFS) format, was 2GB. The maximum number of allocation blocks is 65,536. For a 100GB disk, your allocation block would need to be 1.6MB. Considering Mac OS X 10.7, today's current Apple operating system, is optimized for 4K allocation block sizes, the performance and efficiency of a 1.6MB allocation block would be hideous. HFS is dead. I'm not even finding a partition type GUID for it, it was always intended to be used with the APM partitioning scheme (not MDB or GPT). Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Does anyone still need to create legacy HFS filesystems?
On Feb 3, 2012, at 6:56 AM, Jim Meyering wrote: > Matthew Garrett wrote: >> There's various issues with the hfsplus utilities we ship at the moment, >> including the fact that fsck.hfsplus crashes on 64-bit. I'd like to > > Glad you're looking at this. I noticed that recently, too. > I wanted to use fsck.hfsplus in a test to verify that parted's > newly-revived FS-resizing code produces something reasonable, > but fsck.hfsplus itself segfaults. On the issue of HFSJ resizing, I may have found a major discrepancy between reality and Apple's documentation. I'm skeptical that the current resizing code is going to work on large disks at all until it's updated to handle a jhdr_size of 4096 bytes for disks with a 512 byte sector size. Presently the code interprets jhdr_size as the disk's sector size. A difference between the two causes resizing to fail. I'm seeing resizing fail with virtual and real disks of 2TB or greater in size. I do not know what the failure threshold is in terms of volume or disk size, but it appears jhdr_size depends on the size of the volume, not the size of the disk sectors, contrary to Apple's documentation. http://developer.apple.com/legacy/mac/library/#technotes/tn/tn1150.html jhdr_size - The size of the journal header, in bytes. The journal header always occupies exactly one sector so that it can be updated atomically. Therefore, this value is equal to the sector size (for example, 2048 on many types of optical media). Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Does anyone still need to create legacy HFS filesystems?
On Feb 3, 2012, at 11:12 AM, Chris Murphy wrote: > There is yet another variant called HFSX which is case-sensitive, but also > has more feature potential than HFSJ. Correction, according to the following URL, HFSX can be case sensitive or insensitive. http://docs.info.apple.com/article.html?path=ServerAdmin/10.6/en/asa76d058e.html However, I see no way to create a case insensitive HFSX using either command line tool diskutil or the GUI Disk Utility. diskutil listfilesystems HFS+Mac OS Extended Case-sensitive HFS+ Mac OS Extended (Case-sensitive) (or) hfsx Case-sensitive Journaled HFS+ Mac OS Extended (Case-sensitive, Journaled) (or) jhfsx Journaled HFS+ Mac OS Extended (Journaled) (or) jhfs+ The one unique thing about HFSX appears to be the lack of the HFS Wrapper found on HFS+ and HFSJ volumes. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Does anyone still need to create legacy HFS filesystems?
On Feb 3, 2012, at 12:47 PM, Jim Meyering wrote: > Right. The code explicitly rejects any attempt to resize a partition > on a disk with sector size != 512. Due to this confusion with > jhdr_size, at least for now, I do not plan to change that bit. > > Maybe someone who is motivated and capable will submit a patch, > once the resizing code is back on parted's master branch. The most relevant document, TN1150, which I cited, is considered a legacy document and was last updated in 2004. I haven't been able to find newer documentation. It would seem something has changed with respect to jhdr_size, and has not been documented. (I'm not even slightly surprised.) A separate subject is the lack of read or write support for hfsx. GNU parted does distinguish between hfs+ and hfsx, but mount will not mount hfsx volumes, journaled or not. There is also the issue of 10.7's Core Storage, Apple's logical volume manager. Volumes, encrypted or not, using Core Storage, are obscured from linux. I will not be surprised to see Apple move to Core Storage based encrypted disks using jhfsx by default in 10.8, assuming they don't come up with an entirely new file system by then. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Does anyone still need to create legacy HFS filesystems?
On Feb 3, 2012, at 1:39 PM, Chris Murphy wrote: > mount will not mount hfsx volumes, journaled or not. False. -t hfsplus does work in F16, but is confusing because hfsx != hfs+. In any case, journaled fs is read only. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Does anyone still need to create legacy HFS filesystems?
On Feb 3, 2012, at 12:06 PM, John Reiser wrote: > Examining with gparted and Disk Utility, I see an Apple partition label > that designates partitions: > > HFS (not plus) 1 MB boot > HFS+ journalled 25.6 GB Machintosh HD > ext3 10.6 GB Fedora root > swap 1.0 GB > > I believe that the plain HFS boot partition was created during > Fedora install. It's now running MacOS 10.4.11 and Fedora 12, > which are both the latest applicable releases. I though you meant a user accessible volume being formatted as HFS. HFS+ and HFSX volumes must be greater than 32MB, where as HFS supports smaller sizes. As for the purpose of the 1MB HFS volume, it may be a Fedora PPC convention. I have a PowerPC machine dual booting two versions of Mac OS X, and the disk does not have an HFS volume on it. They are jhfs+. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Does anyone still need to create legacy HFS filesystems?
On Feb 6, 2012, at 5:30 AM, Joel Rees wrote: > > retro computing? Maintaining access to pre-historic data? The only suggestion is dropping the ability to *create* HFS volumes using hfsplus-tools. Not dropping read support for existing HFS volumes. > But, no, HFS isn't really dead. Old formats should not be allowed to > die. I do want to be able to read my old media under emulation > someday. Apple doesn't care, but I do. HFS is about as dead as Espiranto. Those who really want to keep it alive need to put the effort into keeping it alive. As a long time Mac user, I don't expect someone else in the open source community to do this for me, so that I can have access to weird ancient junk. Migrating the data forward to new media and contemporary volume formats is the only sure way to have access to your data. That old media is oxidizing and eventually won't be readable even if you have something that understands HFS. I'd migrate it before it's too late. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT and Fedora 17
On Feb 6, 2012, at 3:40 PM, Brian C. Lane wrote: > > In anaconda-17.6 I have reverted the Lenovo blacklist and changed things > so that pmbr_boot is always set on GPT labeled installs. This should > ensure that thing boot correctly. Is this happening only for Lenovo hardware? Or all hardware? I ask because my Apple hardware fails to boot any OS including pre-existing Mac OS, if the protective MBR (MBR entry 1) has an active (boot) flag set. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
btrfs "scrub" not included in F16?
I'm seeing all sorts of examples using the command "btrfs scrub" yet on all of my F16 installs (including current 3.2.3-1) the command: btrfs scrub start / ERROR: unknown command 'scrub' Usage: [ . . . ] Intentionally not included, or user error? Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Feb 7, 2012, at 7:46 PM, Adam Williamson wrote: > Note that this has not actually been implemented in anaconda yet, so if > you do an anaconda upgrade at this time, it will explode horribly. So the instructions here: http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedora_17 Are the expected steps to move from F16 to F17 Alpha TC1? And then by Alpha TC2 the expectation is that these steps will be performed by anaconda? Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux Questions Desktop Environment of the Year - interesting result
On Feb 13, 2012, at 1:38 PM, Kevin Kofler wrote: > The LQ poll proves it was the latter. I don't like Gnome 3 either. From the largely outsider perspective and new to linux in general, I get the impression Gnome dev is on a mission, of unknown origin, and could absolutely care less about any feedback, except large scale rejection of Gnome 3. Nevertheless, the LQ poll can prove nothing. It is unlikely to be a scientific sample. And even if it turned out to be one, there is no data to prove it's a scientific sample. Fedora DE vs KDE spin download ratio compared to past release ratios would be more suggestive of a trend, if it exists. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F16 Alpha GRUB install failure
On Feb 13, 2012, at 9:16 AM, valent.turko...@gmail.com wrote: > > I did Fedora 16 Respin iso install with all latest packages, including > latest Anaconda package, and still had this issue. > > There were two ntfs partitions (Windows 7 + data partition) and 30 GB > of free space. > > From 30GB free space I created > /root # 200 MB, ext4 > /swap # 2.5 GB, swap > / # 8.0 GB, ext4 > /home # 19 GB, btrfs > > grub2 install fails miserably :( > > Are there any updates regarding this bug? I think the problem is GRUB2's own install script/app, doesn't do a great job of accounting for disks partitioned where the 1st partition comes less than 35KB after the MBR, and as the core.img is too large it fails to install between the MBR and partition 1. Strangely though, anaconda manages to get it to install without a complaint. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux Questions Desktop Environment of the Year - interesting result
On Feb 13, 2012, at 2:32 PM, Genes MailLists wrote: > On 02/13/2012 03:47 PM, Chris Murphy wrote: > >> Fedora DE vs KDE spin download ratio compared to past release ratios would >> be more suggestive of a trend, if it exists. > > Not necessarily - I always used the standard DVD to install and use > KDE and frankly never used the KDE spin - not once. Doesn't matter. The question is whether there is a change in trend. It's improbable that KDE adoption is increasing in statistically significant numbers, while at the same time KDE spin downloads remain flat, just because people can install KDE from the standard DVD installer. If there is a new trend developing, downloads and even yum updates would represent much more valuable data from which to draw general conclusions than a poll off one forum. The very poll's existence, and question structure, will disproportionately draw disaffected Gnome users to participate in the poll. Let's not forget there are KDE affectionados who were not pleased with KDE4. But in any event, the users almost don't matter when it comes to desktop experience. It's which environment has the most development (both for apps that run in it, as well as developers for the environment itself). Windows is an example of abysmal UI and UX, yet has a huge installed base who are not punishing MS over an objectively poor UI design. And long time Mac users have been expressing in larger numbers than any other release how irritated they are with the incorporation of iOS UI into Mac OS Lion (10.7) - and yet it's one of the most successful, by raw numbers, Mac OS upgrades of all time. So the complaining, the anecdotes of people switching environments, and totally non-scientific forum polls, probably means almost exactly zero. What is a valid concern for RH though, is whether and when Gnome 3 makes sense on RHEL, and if the fallback mode experience is a better and practical default, than the standard experience, for the RHEL market. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F16 Alpha GRUB install failure
On Feb 13, 2012, at 7:10 PM, Adam Williamson wrote: > On Mon, 2012-02-13 at 14:25 -0700, Chris Murphy wrote: >> >> I think the problem is GRUB2's own install script/app, doesn't do a great >> job of accounting for disks partitioned where the 1st partition comes less >> than 35KB after the MBR, and as the core.img is too large it fails to >> install between the MBR and partition 1. >> >> Strangely though, anaconda manages to get it to install without a complaint. > > No, that's clearly not the problem here, because this thread is about > installing grub to the front of a partition - *not* to the MBR. The GRUB2 manually doesn't outright say "unsupported" or "not recommended" but it does say insertion prior to the 1st partition is what's recommended. I've had zero problems with GRUB legacy installing into specific partitions, but worse than 50% failure with GRUB2 so I've given up on stuffing it into specific partitions. > anaconda only calls grub2-install, with appropriate parameters, to > install grub. It doesn't do anything particularly special or clever. Well I've got a number of cases on F16 where anaconda's call to grub2-install produces a smaller core.img than calling grub2-install directly. I don't have an explanation for this, but it's just enough of a difference in size that it causes problems with older partitioning schemes that start partition 1 at sector 63. Is anaconda passing --force by default? Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 bootloader error
On Feb 15, 2012, at 10:41 AM, Mike Chambers wrote: > When trying to do test install against F17Alpha TC2, during partition > layout, I get error below... > > "you have not created a bootloader stage1 target device" > > I have F16 installed on here, and even reformatted the disks to GPT > before I installed F16. So using same partitions as installed like I > always do should just work. So hoping this a install issue and not a > "me" issue LOL. It looks like you did a custom partitioning, and did not create a BIOS GRUB partition, which is what the error is complaining about. That partition is used for GPT disks to store GRUB2's core.img rather than stuffing it in unclaimed space. A bug should be filed against this error message IMO, because there is no "stage1" for GRUB2. And "target device" is about as redonkulous of a term as I've heard in 4 hours - what it's looking for is a partition, let's call it that. > Error... > > http://miketc.net/bootloader.jpg > > Partition Layout... > > http://miketc.net/partitions.jpg > For future reference, I'd resize these JPEGs, they don't need to be this huge, and post them somewhere where they download faster. This was crawling painfully. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 bootloader error(s)
On Feb 15, 2012, at 10:41 AM, Mike Chambers wrote:
> When trying to do test install against F17Alpha TC2, during partition
> layout, I get error below...
>
> "you have not created a bootloader stage1 target device"
anaconda-17.8-1.fc17.src.rpm
pyanaconda/storage/__init__.py
line 1250
errors.append(_("you have not created a bootloader stage1 "
"target device"))
If this only occurs on GPT disks, which I'm pretty sure is true, then a more
elucidative message would be:
errors.append(_("You have not specified a BIOS Boot "
"partition."))
The current message is obscure, and consistently results in questions on forums.
For consistency, I suggest the following lines be changed:
line 1165 "You have not defined a root partition (/), "
to
"You have not specified a root partition (/), "
line 1259 "You have not created a bootable partition."
to
"You have not specified a bootable partition."
The four "you have not" partition related errors in this script would then read:
"You have not specified a swap partition. "
"You have not specified a root partition (/), "
"You have not specified a BIOS boot partition "
"You have not specified a bootable partition."
Not sure where the "You have not specified an EFI System partition." is
located...
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 bootloader error
On Feb 16, 2012, at 2:45 AM, Mike Chambers wrote: > I don't have a BIOS boot partition now on F16 and it had to be GPT when > I first installed it. So what's the difference and do I *have* to have > it on F17 because of a change? The exact same message happens on F16 with GPT disks using the customize installation type, if you forget to create a BIOS Boot partition. I don't think GRUB2 devs mean for BIOS Boot to be required per se, but I think it's a good enough idea for a distribution to require it, because on GPT disks there's no obvious safe place for core.img to go, except in its own defined partition. grub2-install specifically looks for the BIOS Boot partition type GUID, and it only needs to be 1MB (which is also consistent with maintaining alignment for 512e and 4Kn disks). Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Feb 17, 2012, at 10:20 AM, Nathaniel McCallum wrote: > Tone down the rhetoric please. I'm no expert, but I think the UsrMove issue has pushed some people beyond anxiety disorder. MDMA or diazepam would probably have a higher efficacy than more emails on the subject. Chris Murphy-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Issues with yum
On Feb 27, 2012, at 9:08 AM, Bruno Wolff III wrote: > I don't believe yum has a way to roll back transactions reliably. http://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Issues with yum
On Feb 27, 2012, at 12:18 PM, Bruno Wolff III wrote: > On Mon, Feb 27, 2012 at 11:24:55 -0700, > Chris Murphy wrote: >> >> http://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs > > Yeah being able to rollback file systems will help in some cases. It > isn't a complete answer for the case where you are using the machine > for other things at the time you are doing the updates, since you amy > want to rollback the updates without rolling back other changes (logfiles > newly delivered email messages and the like). It's a very broad rollback implementation. I think an eventual goal for the yum plugin, once btrfs is stable, is to make it more flexible. Maybe where /home is exempt from rollback. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Issues with yum
On Feb 27, 2012, at 12:22 PM, drago01 wrote: >> > > This fixable by taking the system "down" during the update (close all > apps and services) similar like what windows and os x do. At least on OS X this behavior depends on what's being updated. Most things are updated in place. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Issues with yum
On Feb 27, 2012, at 1:56 PM, James Antill wrote: > On Mon, 2012-02-27 at 12:25 -0700, Chris Murphy wrote: >> >> It's a very broad rollback implementation. I think an eventual goal for the >> yum plugin, once btrfs is stable, is to make it more flexible. Maybe where >> /home is exempt from rollback. > > It's already usable with LVM and BtrFS, and you can exclude arbitrary > mount points. > However creating mount points in a way that makes it only "rollback" > those things you want is ... non-trivial. > Pretty sure it works without a dependency on LVM, rather uses btrfs snapshots. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Issues with yum
On Feb 27, 2012, at 9:28 PM, Adam Williamson wrote: > On Mon, 2012-02-27 at 11:24 -0700, Chris Murphy wrote: >> On Feb 27, 2012, at 9:08 AM, Bruno Wolff III wrote: >> >>> I don't believe yum has a way to roll back transactions reliably. >> >> http://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs > > Yeah...you might want to remember the context of the conversation. > > I don't think you're *seriously* suggesting that hitting ctrl-c while > using yum should result in a btrfs snapshot restoration, are you? I'm agreeing with the assertion I quoted, but pointing out there is an option to gain rollback functionality. That's all. I've never used control-c during a yum update. Too me, that seems like "Oh hell, I didn't mean to throw that cup of habaneros in my blueberry smoothie! Control-c?!" Even if they haven't been blended in yet, the smoothie is destroyed. So no, I was not suggesting automatic rollback. However... What's the expectation of a user hitting control-c in the middle of a yum update anyway? My first inclination is it makes zero sense, like habaneros in a smoothie. But if control-c means "stop here" as in "don't push the frappe button!" is that really as useful as "go back to start" as in "magically remove the habaneros?" I'd pick a return to a known stable state, rather than being dropped in who knows what, where I'm probably going to have to install yum-utils and run yum-complete-transaction and who knows what. It'd probably work, that's what it's there for. Like picking each habanero and seed out of a blender with a fork? Magic sounds better. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
UEFI install from USB media
http://docs.fedoraproject.org/en-US/Fedora/16/html/Installation_Guide/Making_USB_Media.html 2nd sentence reads: Note that you cannot install Fedora on UEFI-based AMD64 and Intel 64 systems from a USB flash drive, although you can use a USB flash drive to boot the Fedora installer on UEFI-based AMD64 and Intel 64 systems This appears to say "you cannot install, but you can boot". It's quite confusing. I have used livecd-tools to create UEFI bootable LiveCD media on a USB stick and also installed it onto an Intel-64 system. So this portion of documentation appears to be incorrect. If so, I'll volunteer to file a documentation bug - however the bugzilla only has a documentation bug report version of "devel" so it's slightly unclear how to file such a doc bug report. If it's a bug. Chris Murphy-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Issues with yum
On Feb 28, 2012, at 12:19 AM, elison.ni...@gmail.com wrote: > On Tue, Feb 28, 2012 at 12:39 PM, Chris Murphy > wrote: >> What's the expectation of a user hitting control-c in the middle of a yum >> update anyway? My first inclination is it makes zero sense, like habaneros >> in a smoothie. > > As stated earlier, the expectation is that when yum is still setting > up update process or downloading repo information, it will stop that > and quit. > Only when yum reaches "starting transaction test" or "running > transaction", it should restrict ctrl-c. *shrug* OK I'm not going to deny you a feature. I still don't understand why it would be started in the first place if you didn't intend to finish it. But then, I never use -y either so I kinda know what I'm getting into before I confirm with "Y" that I do want to proceed with the update. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Issues with yum
On Feb 28, 2012, at 10:02 AM, John Reiser wrote: > On 02/28/2012 08:51 AM, Chris Murphy wrote: > >> *shrug* OK I'm not going to deny you a feature. I still don't understand >> why it would be started in the first place if you didn't intend to finish it. > > The Fedora mirror system doesn't always behave nicely > (timeouts, bad sync, slow transfer rate, ...) > I find that SIGINT is appropriate about once per week > just for downloads. Well I sure love eating crow. I have in fact hit control-c in the case where a slow mirror (like, dial-up modem slow) was even delaying the database update. 10 minutes later, still no idea if there were any applicable updates available. But control-c during that initial database updating for me has always been instant kill and drop to a prompt. Retrying, nothing is inconsistent, and I'm connected to a much faster mirror 100% of the time. So at least that instance of control-c appears to work. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How can we make F17 be able to boot on Macs (with or without reFit)
On Feb 28, 2012, at 12:15 PM, Adam Williamson wrote: > > Chris Murphy is pretty active testing various things in regards to Mac > booting, and I've been meaning to get in touch and ask if he's taken a > look at F17 Alpha. I just downloaded the LiveCD, installed it in VM so I can use the latest livecd-tools to make an EFI bootable USB stick for the Mac hardware I have here. Will report back. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How can we make F17 be able to boot on Macs (with or without reFit)
On Feb 28, 2012, at 12:53 PM, Matthew Garrett wrote: > > Yes. I'm mostly working on the netinst isos, and right now if you take > that and dd it onto a USB stick, then insert that and hold down alt on > boot, you'll get a Mac install. 1. http://mirrors.yocum.org/fedora/releases/test/17-Alpha/Fedora/x86_64/iso/Fedora-17-Alpha-x86_64-netinst.iso dd if=Fedora-17-Alpha-x86_64-netinst.iso of=/dev/rdisk1 2. I get two additional icons to boot from, both named "EFI Boot". One is an orange USB icon, the other is a blue Fedora icon. 3. If I choose the blue Fedora icon, I get a GRUB Legacy menu, let it time out. It appears to be loading data from the USB stick. After about 45 seconds, the computer reboots, and I'm at a Mac OS login window. No text error messages indicating why. 4. I reboot with option key to get the AppleEFI boot menu, choose the orange USB "EFI Boot" icon, the same thing happens. 45 seconds, I get a reboot, and I'm at a Mac OS login window. No text error messages indicating why. 5. In Mac OS X 10.7.3, Startup Disk panel, there are no additional boot options listed when the USB stick is inserted, yet there are two "ANACONDA" labeled volumes mounted. The hardware is a Macbook Pro 4,1 (2008) model. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How can we make F17 be able to boot on Macs (with or without reFit)
Prior attempt, I mentioned at the very bottom of the email, easy to miss, was a Macbook Pro 4,1 (2008) model. --- Attempt 2 with different hardware: Apple Macbook Pro 8,2 (2011). 1. Starting with a USB stick produced with the following: http://mirrors.yocum.org/fedora/releases/test/17-Alpha/Fedora/x86_64/iso/Fedora-17-Alpha-x86_64-netinst.iso dd if=Fedora-17-Alpha-x86_64-netinst.iso of=/dev/rdisk1 2. Inserting the USB stick while Mac OS 10.6.8 is running (I know, older OS on the newer hardware, I'm on crack), the Startup Disk panel does not show any additional options for booting. 3. Rebooting, holding option key, I get two additional boot option icons both labeled "EFI Boot". One is an orange USB icon. The other is a blue Fedora icon. 4. When choosing either option, I get the GRUB Legacy menu, it times down to zero, I get 7 seconds of USB stick activity, followed by a tone from the laptop I have only ever heard when doing firmware updates. Interval is approximately 0.7 seconds tone, 0.3 seconds silence, three times. Followed by 3 seconds of silence. Then repeats. It does not end on its own after 2 minutes, and the computer does not reboot. And the keyboard is not functional. I have to hold the power button for 5 minutes to force a shutdown. Again, no text onscreen to indicate what the problem is - it's still at the GRUB window during all of this. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How can we make F17 be able to boot on Macs (with or without reFit)
> > Starting with a USB stick produced with the following: > http://mirrors.yocum.org/fedora/releases/test/17-Alpha/Fedora/x86_64/iso/Fedora-17-Alpha-x86_64-netinst.iso > > dd if=Fedora-17-Alpha-x86_64-netinst.iso of=/dev/rdisk1 I'm not sure if this is expected or not, but I make the following observations about the resulting USB stick, which appears to have a bogus GPT according to three utilities. 1. GPT fdisk (gdisk) version 0.8.2 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Warning! Main partition table overlaps the first partition by 48 blocks! You will need to delete this partition or resize it in another utility. Disk /dev/disk1: 3915776 sectors, 1.9 GiB Logical sector size: 512 bytes Disk identifier (GUID): E2E967A4-B1E8-4D61-9F5D-37F99C3E603E Partition table holds up to 128 entries First usable sector is 48, last usable sector is 319454 Partitions will be aligned on 4-sector boundaries Total free space is 1550 sectors (775.0 KiB) Number Start (sector)End (sector) Size Code Name 2 58168 59483 658.0 KiB 0700 卉䡏批楲d灁汰e灁汰 3 59484 61323 920.0 KiB AF00 卉䡏批楲d灁汰e灁汰 Similar results but different Name encoding for gdisk on Fedora. 2. parted on F17 Error: The backup GPT table is not at the end of the disk, as it should be. This might mean that another operating system believes the disk is smaller. Fix, by moving the backup to the end (and removing the old backup)? Fix/Ignore/Cancel? i Warning: Not all of the space available to /dev/sdb appears to be used, you can fix the GPT to use all of the space (an extra 3596288 blocks) or continue with the current setting? Fix/Ignore? i Error: Unable to satisfy all constraints on the partition. 3. Apple's "gpt" program: cd2:~ chris@ gpt show -l disk2 gpt show: error: bogus map gpt show: unable to open device 'disk2': No such file or directory -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How can we make F17 be able to boot on Macs (with or without reFit)
On Feb 28, 2012, at 2:37 PM, Chris Murphy wrote: >> >> Starting with a USB stick produced with the following: >> http://mirrors.yocum.org/fedora/releases/test/17-Alpha/Fedora/x86_64/iso/Fedora-17-Alpha-x86_64-netinst.iso >> >> dd if=Fedora-17-Alpha-x86_64-netinst.iso of=/dev/rdisk1 > > I'm not sure if this is expected or not, but I make the following > observations about the resulting USB stick, which appears to have a bogus GPT > according to three utilities. parted can't fix it. gdisk then says the GPT is damaged and will not fix/restore the 1st partition which contains the bulk of the boot data. gpt bails entirely. AFAIK this ISO isn't valid, insofar as the GPT is invalid, but I'm not sure if that relates to the booting problems both computers are having. I'm going to try making an EFI bootable USB stick using the latest livecd-tools and the F17-alpha-LiveCD and see where that takes me. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17, Apple, EFI boot, livecd-tools
Following applies to a 2008, Macbook Pro 4,1 1. Used livecd-tools-17.6-1.fc17 to successfully create an EFI bootable USB stick of Fedora-17-Alpha-x86_64-Live-Desktop.iso. 2. Due to this bug: EFI boot fails on Macs with NVIDIA GeForce 8600M GT https://bugzilla.redhat.com/show_bug.cgi?id=751147 I add 'nomodeset' kernel parameter. I know of no work around to get a GUI on this hardware. But it does boot kernel and most services. 3. tty1 hangs at "Started Display Manager" tty2 is functional, not sure how to get any information on what's up with tty1. Normally what I'm used to with EFI boot and nomodeset is X can't actually startup, but the rest of the services load, and I end up at a prompt. 4. Out of 5 boot attempts, I get to a usable tty2 console and can reboot thrice. Twice, I get a hang right after GRUB loads either the kernel or initrd, the GRUB splash screen is present with no text. The machine has hung and I have to hold the power button to shut down. So on this hardware I'd say GRUB is marginally reliable. 5. At reboot/poweroff time, there's a LOT of extra "garbage" information being produced on-screen compared to F16. It goes by quick enough and isn't logged, so I'm not sure if it's important. But I do get a reboot, albeit with about a 1 minute delay over F16. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17, Apple, EFI boot, livecd-tools
Following applies to a 2011, Macbook Pro 8,2 1. Used livecd-tools-17.6-1.fc17 to successfully create an EFI bootable USB stick of Fedora-17-Alpha-x86_64-Live-Desktop.iso. 2. I get to the GRUB menu. Times out and starts to boot. Same result as: EFI boot failure to properly initialize graphics on Macs with Intel and AMD graphics https://bugzilla.redhat.com/show_bug.cgi?id=765954 So no improvement so far over F16 on either hardware. But livecd-tools appears to work correctly. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17, Apple, EFI boot, livecd-tools
On Feb 28, 2012, at 11:21 PM, Adam Williamson wrote: > > I suppose it might be interesting to see if grub2-efi works any > better... It's been a year since I've tested it so it needs to be retested. But I do know that doesn't fix bug 765954, so the machine is, for me, functionally useless as a laptop with just a text console. >> 5. >> At reboot/poweroff time, there's a LOT of extra "garbage" information being >> produced on-screen compared to F16. It goes by quick enough and isn't >> logged, so I'm not sure if it's important. But I do get a reboot, albeit >> with about a 1 minute delay over F16. > > I suspect 'yum install plymouth' may help with that. With rhgb and quiet disabled on F16 and F17, so plymouth is a non-factor. I just get a lot (like probably 10+ screenfulls) of repetitive text that scrolls by very quickly with F17. This comes after the unmounting of filesystems sequence, where as on F16 the computer shuts down. This only happens on actual hardware, in VM, I'm not seeing much of a difference. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17, Apple, EFI boot, livecd-tools
On Feb 29, 2012, at 12:09 AM, Adam Williamson wrote: > On Tue, 2012-02-28 at 23:30 -0700, Chris Murphy wrote: >> On Feb 28, 2012, at 11:21 PM, Adam Williamson wrote: >>> >>> I suppose it might be interesting to see if grub2-efi works any >>> better... >> >> It's been a year since I've tested it so it needs to be retested. But I do >> know that doesn't fix bug 765954, so the machine is, for me, functionally >> useless as a laptop with just a text console. >> >>>> 5. >>>> At reboot/poweroff time, there's a LOT of extra "garbage" information >>>> being produced on-screen compared to F16. It goes by quick enough and >>>> isn't logged, so I'm not sure if it's important. But I do get a reboot, >>>> albeit with about a 1 minute delay over F16. >>> >>> I suspect 'yum install plymouth' may help with that. >> >> With rhgb and quiet disabled on F16 and F17, so plymouth is a non-factor. > > that doesn't actually disable plymouth, it's still involved. ok i don't get the fedora logo splash at shutdown in any event. Chris -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Torvalds:requiring root password for mundane things is moronic
On Feb 29, 2012, at 5:15 AM, drago01 wrote: > On Wed, Feb 29, 2012 at 1:02 PM, Neal Becker wrote: >> I think he's got a point >> >> http://www.osnews.com/story/25659/Torvalds_requiring_root_password_for_mundane_things_is_quot_moronic_quot_ > My example is mDNS being blocked in the Firewall by default *and* it requires a root password to unblocked it. Completely retarded. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Torvalds:requiring root password for mundane things is moronic
On Feb 29, 2012, at 7:08 AM, Nikos Roussos wrote: > Why not add by default the first user created (right after installation > finishes) to administrative group and disable the root account? This is, is fact, how Apple has done things circa 1999 with Mac OS X. You can 'su' to root, you can also 'sudo' but you can't literally login as root either in text console or GUI, the account is disabled. And the first user is an 'admin' by default. Chris Murphy-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Torvalds:requiring root password for mundane things is moronic
On Feb 29, 2012, at 3:51 PM, Simo Sorce wrote: > On Wed, 2012-02-29 at 10:09 -0700, Chris Murphy wrote: >> >> My example is mDNS being blocked in the Firewall by default *and* it >> requires a root password to unblocked it. Completely retarded. > > Except that mDNS is a real security issue (because you can hijack name > resolution quite easily with it). Fair enough but then I'd argue mDNS's present method of dealing with hijacking. If two clients respond with the same name, it seems that all other clients on the network should blacklist both clients rather than trusting the one that answers first. Disabling it entirely is the granularity of a large hammer. mDNS is still much more useful than not useful, and more useful than statistically risky, despite being highly spoofable. > That said I understand your pain and the realize the current solution is > not ideal for the casual user. Maybe we should have 2 security profiles > (lax and strict) that you can choose at install time so that people can > choose what they like best. I was under the impression F17 was going to have a different firewall, such that mDNS was going to be enabled if a service, such as sshd, was enabled and also has an Avahi service listing. Or something like that. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Torvalds:requiring root password for mundane things is moronic
On Mar 1, 2012, at 10:53 PM, Adam Williamson wrote: > On Thu, 2012-03-01 at 17:43 -0500, Adam Jackson wrote: >> On Thu, 2012-03-01 at 16:39 -0500, Daniel J Walsh wrote: >> >>> I believe Fedora 17 has an add user to admin group checkbox when >>> adding the initial user, not sure if it is checked on or off by default. >> >> Off by default (having just tried it today). > > In case anyone's wondering what that actually does, here's what I can > figure out. > > What it does directly is to add the user to the 'wheel' group. I'm not > sure what all the consequences of that are, but there's two I've been > able to find. The first is that the default /etc/sudoers allows people > in the wheel group to run any command as root, which is great and all, > but we don't use sudo for anything at the desktop level, so it really > only affects people who run sudo from the console. > > The other thing it does, if I'm reading stuff right, is that users in > the wheel group are considered 'admins' by PolicyKit. That's good. Now > as to what that means, I'm not 100% sure, but I *think* what it means is > that for any action which would require a non-admin user to authenticate > as root, an admin user can authenticate as themselves. i.e. instead of a > root password dialog, you'd get a your-own-password dialog. I might be > off base there, though, and if I am I'm sure someone smarter will > correct me. :) From my own experience, anything I change in the GUI that requires authentication, it is for user 'chris' if that user was added as an admin with the checkbox in the create first user steps. If that checkbox is not checked, any authentication dialog that appears is for user 'root'. My interpretation of Torvalds' complaint, is with the mere existence of authentication dialogs in the first place, for certain things. Mac OS X has always required authentication (from a user with "admin" privileges) for changing the Date/Time including time zones, which is an absurdity. In the most recent version, it's no longer possible for a non-authenticated user with admin privileges (in effect two levels of privileges for the same user with the same login and the same password) to install e.g. ICC color profiles to a folder making the profiles available to all users. So I'm an admin, and if I want to modify a folder, I have to enter my password in a pop-up authentication dialog to add/remove ICC profiles. Worse, the individual user folder for these profiles is now hidden by default. It's high order insanity. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Torvalds:requiring root password for mundane things is moronic
On Mar 2, 2012, at 10:26 AM, Kevin Wright wrote: > On Feb 29, 2012, at 9:18 AM, Chris Murphy wrote: >> >> On Feb 29, 2012, at 7:08 AM, Nikos Roussos wrote: >> >>> Why not add by default the first user created (right after installation >>> finishes) to administrative group and disable the root account? >> >> >> This is, is fact, how Apple has done things circa 1999 with Mac OS X. You >> can 'su' to root, you can also 'sudo' but you can't literally login as root >> either in text console or GUI, the account is disabled. And the first user >> is an 'admin' by default. >> >> > > Hi Chris, > > I'm not sure what you mean but "you can't literally login as root either in > the text console..." > > This is confusing to me since I've been using the root account on Mac OS X > since 2001. I was working for Apple as a build engineer and all of our builds > were performed using the root account. > > Here's an article that explains how to enable the root account: > > http://support.apple.com/kb/HT1528 I'm not sure why you're confused. The account is disabled, and until it's enabled you can't login as root, either using ssh, or entering ">" at the loginwindow to get to a text console and trying to login as root there. Once the root account is enabled you can. Chris Murphy-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT and Fedora 17
On Mar 2, 2012, at 10:37 AM, Pádraig Brady wrote: > Yep as expected F17 alpha is broken in the same way on my laptop. Your laptop is what hardware? Any install media kernel parameters used? What installation type? Can you provide both an fdisk and parted (or gdisk) listing of the post-installation disk? Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT and Fedora 17
On Mar 2, 2012, at 2:20 PM, Pádraig Brady wrote: > > Model: ATA ST9500420AS (scsi) > Disk /dev/sda: 500GB > Sector size (logical/physical): 512B/512B > Partition Table: gpt > Disk Flags: pmbr_boot > > Number Start End SizeFile system Name Flags > 1 1049kB 2097kB 1049kB bios_grub > 2 2097kB 526MB 524MB ext4 ext4 boot > 3 526MB 500GB 500GB lvm 1. What happens if you remove the GPT boot flag from sda2? 2. What happens if you add the GPT legacy_boot flag to sda2? 3. While I wouldn't recommend supporting such a solution, but I'm curious what happens if you use gdisk to create a hybrid MBR, and add only partition 3 (lvm), set it as bootable instead of the PMBR. GPT fdisk (gdisk) can do this. It's now on the F17 LiveCD. Menu 'r' option 'h'. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Torvalds:requiring root password for mundane things is moronic
On Mar 3, 2012, at 1:00 PM, Neal Becker wrote: >> > > Here's one part of the principle: > > I. The ONLY reason for re-auth is to prevent trojans/web attacks. > > This implies > > -> Don't ask for re-auth for an action that isn't really potentially harmful > (e.g., adding a printer) Depends. What if what's being added is a remote printer, that's merely a way to smuggle documents out of a company? So direct attach printers are probably fair game for adding without authentication. The user clearly has physical access to both computer and printer, the most applicable security control in this context is physical. But to add a non-local IPP printer is possibly a red flag. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Torvalds:requiring root password for mundane things is moronic
On Mar 3, 2012, at 3:19 PM, Miloslav Trmač wrote: > A complete lockdown to prevent transferring data out of the system is > a much harder problem (even if you only allow users to run a web > browser, they may use it to send data to a server). Yeah, you're right, I can just open a gmail or dropbox account within a web browser, upload the data. I think the distinction is "who is going to have to support the result". If it's a home user or small business, they will have to provide support no matter what the connection is; and in a many user environment with some kind of IT staff, it's potentially a different granularity. In some cases they may have no problem with a local printer being attached, or conversely as you point out may have no problem with remote printers. But any printer addition affects the UI and UX, and a potential increase for support. Therefore blanket allowance for any user to add any device is probably not a good idea. Even if there aren't security risks. I prefer the first created user defaulting to being an administrator. At least on Mac OS (not to suggest it's right, only that I'm most familiar with its behavior), the consequences to this are authentication dialogs appear far less often. And I'm added to the following groups: _appserveradm _appserverusr _lpadmin access_bpf admin com.apple.access_screensharing com.apple.access_ssh Without additional authentication, as an admin, I can add/modify/remove printers, change timezone, make network modifications, make file and device sharing modifications, perform software updates, change startup disk. Normal users can't change these things. As admin, I can't make changes to users and groups, or security/privacy related changes unless there is additional authentication. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /etc/default in Fedora
On Mar 5, 2012, at 3:24 PM, Adam Williamson wrote: > > But then, we already 'invalidate upstream documentation for Fedora > users' by renaming all the command-line tools from 'grub-foo' to > 'grub2-foo'. Indeed, I lost about 47 brain cells on this issue alone. (By no means is it the winner for GRUB induced brain damage.) Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How can we make F17 be able to boot on Macs (with or without reFit)
On Feb 28, 2012, at 12:53 PM, Matthew Garrett wrote: > Yes. I'm mostly working on the netinst isos, and right now if you take > that and dd it onto a USB stick, then insert that and hold down alt on > boot, you'll get a Mac install. OK so color me extremely confused. Starting with a zero'd USB stick (no APM, GPT or MBR), dd'ing the netinst.iso to the stick, I end up with a stick that all tools claims has a GPT, but is a broken GPT (see previous emails on this). When I burn it to a DVD, diskutil and gdisk claim the partition scheme is APM! It's not GPT at all as far as they are concerned. I don't know how this is possible...but I've reproduced the results twice. DVD version behaviors, on a 2008 Macbook Pro: 1.) Upon boot with option key, to get the Apple-EFI boot screen, there are four new options. Windows, EFI Boot, EFI Boot, EFI Boot. a.) When I choose the CD/DVD icon labeled Windows, I get syslinux, and then a menu from which I can start Fedora. It produces a text anaconda installer which appears to function, although I did not proceed with an installation. b.) When I choose the CD/DVD icon labeled EFI Boot, I'm dropped to a GRUB prompt. c.) When I choose the Fedora icon labeled EFI Boot, I'm dropped to a GRUB prompt. d.) When I choose the last CD/DVD icon labeled EFI Boot, a Mac OS login window appears and the computer appears to be booting from the hard drive, not the DVD at all. On a 2011 Macbook Pro, there are only three new boot options when the DVD is present with behaviors 1a, 1b, and 1c. (Icon 1d is not presented.) In any case, only the "Windows" option, which results in a CSM-BIOS mode boot, produces a booted system from which Fedora can be installed. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Torvalds:requiring root password for mundane things is moronic
passwd keeps complaining "The password fails the dictionary check - it is too simplistic" for fake words NOT in the dictionary but otherwise too simple for passwd's approval system. I'm using the F17 alpha LiveCD and I'm just testing. I want a SIMPLE password and it won't let me use anything I can remember. I have to write down a temp password to do TESTING? This behavior is so completely asinine, it's like I have a f'n security mom parenting my password selection. I don't know who thinks it's their business to programmatically prevent me from choosing dogcrap as a password, but it's really irritating. Oh and the password is hullop130. Nice thwart of an annoying, USELESS behavior, huh? Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Torvalds:requiring root password for mundane things is moronic
On Mar 5, 2012, at 8:37 PM, Chuck Anderson wrote: > On Mon, Mar 05, 2012 at 08:35:11PM -0700, Chris Murphy wrote: >> passwd keeps complaining "The password fails the dictionary check - >> it is too simplistic" for fake words NOT in the dictionary but >> otherwise too simple for passwd's approval system. > > I think you can just ignore passwd's warning in this case, it doesn't > stop you from going ahead and using the simple password (unless > something changed in F17). Aha. So if I use passwd with liveuser, it says after three tries: passwd: Have exhausted maximum number of retries for service And does not change the passwd. But if I su to root, it still complains once, but does change the password after the Retype entry. NEVERTHELESS. It's idiotic babysitting. And stupid that I need root to do this mundane task. I wonder how many developer man hours were required for this functionality. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Torvalds:requiring root password for mundane things is moronic
On Mar 7, 2012, at 6:29 AM, Miloslav Trmač wrote: > > UNIX didn't have these defaults originally; they were added in the > 90's only after real-world experience has shown that these policies > are necessary (and they have been pretty much unchanged for the last > 10-15 years, AFAIK). It's a philosophical conversation that's probably out of scope for this list, but this amounts to baby sitting stupid people. The first thing such a person must accept as true, is that it's necessary to parent morons by second guessing their choices. I think that in and of itself is radically moronic. It says it's OK for complete strangers to hassle other people about their passwords, not even knowing the context. It's a shake down, and it's how we've arrived at an INSANE password paradigm where we routinely can't choose long memorable passwords, and are instead often forced to choose short 12-15 character passwords that mandate a certain quantity of numerical and special characters. They're difficult to remember, ensuring it will be written down, likely in some unencrypted file, and actually increases the statistical likelihood of a compromise. > > (and FWIW, regarding the "hullop130" password, a quick grep shows that > "hullo" is in the dictionary, and cracklib may have additional rules > or ways to arrive at the password from a different dictionary word). Ok so in other words, this is a 5 year old baby sitter and is marginally competent at the intended task from the outset. I get a time to crack between 101 seconds and 32000 years. The computer in question is used only for testing. The single drive was wiped using the ATA ESE command before I started, so there literally is nothing useful on this computer, but setting the password was like getting sand in body orifices. I su'd to root and changed the password to hello, and now I feel much better. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: phoronix benchmarks ext4 vs. btrfs
On Mar 7, 2012, at 2:31 PM, drago01 wrote: > "Assuming you are talking about a desktop system just buy a ssd and > never worry about I/O ever again." Well, most of my colleagues and customers with desktop systems have rather extreme storage requirements. Individual files multi gigabyte composited image files. So an SSD is nice for speed, but cost prohibitive for everything to be stored on SSD. What they need is a file system that puts hot files on the SSD and cold files on HDD. I think there is btrfs code being worked on to do just that. I don't know if it's any more or less difficult to do this on other filesystems. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: phoronix benchmarks ext4 vs. btrfs
On Mar 7, 2012, at 3:01 PM, Michael Cronenworth wrote: > Yes, such a feature was submitted[1], but it has never been committed by > Chris AFAIK. There is also a OS-agnostic method of this. Seagate XT drives > use a small SSD as a cache. Then there is also a Windows method with Intel's > SSD Cache using a dedicated SSD as only a cache. Either way gives you a > similar result. I think I'd rather see a portion of the SSD be a discrete device so that the system and application scratch/swap can be pointed to it - rather than as cache. I'm not sure that this data would always stay hot enough to be assured of being in an SSD cache, whereas a discretely defined device would. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: phoronix benchmarks ext4 vs. btrfs
On Mar 7, 2012, at 3:31 PM, drago01 wrote: > On Wed, Mar 7, 2012 at 11:14 PM, Chris Murphy wrote: >> >> On Mar 7, 2012, at 3:01 PM, Michael Cronenworth wrote: >>> Yes, such a feature was submitted[1], but it has never been committed by >>> Chris AFAIK. There is also a OS-agnostic method of this. Seagate XT drives >>> use a small SSD as a cache. Then there is also a Windows method with >>> Intel's SSD Cache using a dedicated SSD as only a cache. Either way gives >>> you a similar result. >> >> I think I'd rather see a portion of the SSD be a discrete device so that the >> system and application scratch/swap can be pointed to it - > > Swap? Really? That is a waste of (expensive) disk space. There is no > point on having swap on SSD if you have another disk around. You > wouldn't notice any speed difference if your system starts swapping > you are in serious trouble (i.e everything crawls) the best fix here > is to just buy RAM which is *very* cheap now days. You're probably right that system swapping is a situation to be avoided. But I can imagine runaway situations that might be more easily recovered from with swap on SSD, just because everything won't come to a complete crawl. As for application scratch, absolutely SSD should be an option when working on very large files. While not a default or routine dependency, one shouldn't have to suffer with HDD scratch when SSD scratch could be available. A typical pro laptop will max out at 16GB of RAM, and heavy duty Photoshop users can occasionally and not unreasonable bust that limit and need scratch. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: phoronix benchmarks ext4 vs. btrfs
On Mar 7, 2012, at 3:58 PM, drago01 wrote: > > It will come to a complete crawl which was exactly my point, faster > storage does not really help you in that situation. Umm, that would seem to be fundamentally broken. I certainly haven't had this experience on Mac OS X in cases where it has started producing swap files. Much slower, yes. Complete crawl, definitely not. And that's to HDD, not even SDD. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FAT and HFS/HFS+ file system resizing restored in parted-3.1
On Mar 3, 2012, at 1:27 AM, Jim Meyering wrote: > FYI, I released parted-3.1 yesterday, > >http://thread.gmane.org/gmane.comp.gnu.parted.bugs/10790 > > In addition to pretty many bug fixes, > >This is to announce parted-3.1, a bug fix release that also reintroduces >a minimal subset of the file system resizing capability that was removed >in 3.0. It adds a new, separate library, libparted-fs-resize, that >provides for resizing of FAT and HFS/HFS+ file systems. FYI, there is a possible problem resizing certain JHFS+/JHFSX volumes. Currently the code fails if the jhdr_header size is something other than sector size. When volume size is > 1TiB, depending on the version of Apple's Disk Utility used, the jhdr_header size won't be 512 bytes, is instead 4096 bytes. Details here: http://lists.apple.com/archives/filesystem-dev/2012/Feb/msg1.html Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: phoronix benchmarks ext4 vs. btrfs
I'm not sure how useful 'time' is as a benchmark for file copies. But that's what I used getting copy time for a folder containing 325 ~7.2MB files (DNGs) totaling 2.3G. First I copied the files to tmpfs, and made all copies from that to the destination. Destination device and partition is always the same, only file system differs. I used default mkfs and mount options. 1st copy is the first copy after mounting the newly created file system. Delay between copies varied somewhat, between 15-30 seconds. The one anomaly is the 3rd ext4 copy. Maybe it wasn't quite done writing out the 2nd copy? Compared to btrfs and XFS, there was a lot of intermittent disk activity well after the copy had finished - over 1 minute. I'm not sure what it was doing, but was consistent for all of its copies. Copies were not overwrites, but into a separate directory. btrfs average real21.45s xfs average real 22.81s ext4 average real 29.31 Anyway, I only did this because having used btrfs moderately for a while now, it doesn't seem as slow as the various benchmarks keep making it out to be. This test may be meaningless as I'm not sure if the termination of the cp command is an appropriate metric at all. And the actual time between copies being variable might also pollute the result. However, except for the 3rd ext4 copy, there's pretty reasonable consistency. detail: 1st copy to btrfs real0m22.881s user0m0.028s sys 0m3.993s - 2nd copy to btrfs real0m20.793s user0m0.024s sys 0m3.899s 3rd copy to btrfs real0m21.641s user0m0.024s sys 0m3.882s -- 4th copy to btfs real0m20.502s user0m0.030s sys 0m5.068s = 1st copy to xfs real0m23.969s user0m0.022s sys 0m6.877s --- 2nd copy to xfs real0m23.452s user0m0.027s sys 0m6.989s --- 3rd copy to xfs real0m21.243s user0m0.031s sys 0m6.838s --- 4th copy to xfs real0m22.589s user0m0.030s sys 0m6.617s == 1st copy to ext4 real0m28.181s user0m0.026s sys 0m11.510s - 2nd copy to ext4 real0m27.321s user0m0.021s sys 0m12.208s --- 3rd copy to ext4 real0m35.036s user0m0.026s sys 0m12.441s -- 4th copy to ext4 real0m26.719s user0m0.035s sys 0m11.511s -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: phoronix benchmarks ext4 vs. btrfs
On Mar 8, 2012, at 11:43 PM, Adam Williamson wrote: > On Thu, 2012-03-08 at 22:19 -0700, Chris Murphy wrote: >> I'm not sure how useful 'time' is as a benchmark for file copies. > > Don't file transfers get cached and return to a console as 'complete' > long before the data is ever written, sometimes? Free memory was 7.4G before setting up the 3G tmpfs. And 161K was free after the first copy. So caching is applicable. I could maybe make a 6G or 7G tmpfs and fill that with files and see what happens. As it was, kswapd0 was extremely active, although I don't know why, certainly no swap should have been needed. Or if there's a way to disabling this caching... This was 3.3.0-0.rc3.git7.2.fc17.x86_64. > Some of the above is wonky personal observation and some of it is > probably cargo culted, but... In all three cases there was solid disk activity well after cp terminated. Timing it consistently isn't as straightforward, but btrfs and XFS were both very close at ~14 seconds solid activity after cp terminated, and no subsequent activity. ext4 post cp termination was amorphous, and lasted much longer. I think sustained testing, with a much larger number/size of files, would effectively make caching a non-factor in the results so I may give that a try. Something like 6-7G's worth of files, and initiate the four copies sequentially using &. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: phoronix benchmarks ext4 vs. btrfs
On Mar 9, 2012, at 12:10 AM, Matthias Runge wrote: > On 09/03/12 07:43, Adam Williamson wrote: >> Don't file transfers get cached and return to a console as 'complete' >> long before the data is ever written, sometimes? > > I've learned a long time ago, if you want to get near real numbers, you > have > to write data at least three times larger than memory size to get > around file system caching. I guess, that's still valid. OK well if I'm going to use real files, and I don't want disk read performance to be a factor in this, I kinda need to put the source files into a ramdisk. So if it's 3x of cache, out of 7.4G free, a 6G ramdisk would be at least 3x that of what remains for use as cache and should qualify? Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: phoronix benchmarks ext4 vs. btrfs
On Mar 9, 2012, at 12:30 AM, Matthias Runge wrote: >> > if your file system places data inefficiently on disk/storage, you want > to measure this, too. If you're comparing file system speed, I think, > you should measure the whole thing and be sure to create comparable > data. The source files are on a jhfs+ volume. I'm disinterested in disk to disk copy. And I'm disinterested in comparing jhfs+ to other file system copies. I'm wondering how a system pushing data from memory to disk. > > You can't really control, how your file system cache is filled. > Although I must say, measuring a the whole effort a few times > consecutively provides more reliable numbers (caution: but no > disk speed measurement). I can probably control it to some degree if there isn't much free memory left, by creating a large ramdisk, that will end up as file system cache. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How can we make F17 be able to boot on Macs (with or without reFit)
On Feb 28, 2012, at 12:53 PM, Matthew Garrett wrote: > Yes. I'm mostly working on the netinst isos, and right now if you take > that and dd it onto a USB stick, then insert that and hold down alt on > boot, you'll get a Mac install. Unfortunately, alpha ended up getting > built with a grub that dies on any Macs that don't have built-in > ethernet, so you may have some problems with that. The alpha kernel also > has a bug that seems to trigger on Macs that results in incredible > slowness. But other than that! Fixed kernel is in the archive now, and > I've just commited a fix for the grub bug. Fedora-17-Beta-TC1-x86_64-netinst.iso. I'm getting the same problems as with alpha ISO. Burned to DVD -- Macbook Pro 4,1 (2008) Four additional CD/DVD icon options labeled as: Windows, EFI Boot, EFI Boot, EFI Boot *2nd EFI Boot option has a custom Fedora logo icon, not generic CD/DVD icon. Windows=Boots CSM/BIOS mode successfully EFI Boot= Grub prompt, no menu *EFI Boot= Grub prompt, no menu EFI Boot= Boots Mac OS X Macbook Pro 8,2 (2011) Three additional CD/DVD icon options labeled as: Windows, EFI Boot, EFI Boot *2nd EFI Boot option has a custom Fedora logo icon, not generic CD/DVD icon. Windows=Boots CSM/BIOS mode successfully EFI Boot= Grub prompt, no menu *EFI Boot= Grub prompt, no menu dd to USB stick -- Macbook Pro 4,1 (2008) Three additional USB icon options labeled as: EFI Boot, EFI Boot, EFI Boot *2nd icon is a custom Fedora logo icon, not generic USB icon. EFI Boot= Grub menu, loads from stick for ~45 seconds then reboots machine *EFI Boot= Grub prompt, no menu EFI Boot= Grub menu, loads from stick for ~45 seconds then reboots machine Macbook Pro 8,2 (2011) Three additional CD/DVD icon options labeled as: EFI Boot, EFI Boot, EFI Boot *2nd icon is a custom Fedora logo icon, not generic USB icon. EFI Boot= Grub menu, loads from stick for ~6 seconds, then beeping, must force shutdown. *EFI Boot= Grub prompt, no menu EFI Boot= Grub menu, loads from stick for ~6 seconds, then beeping, must force shutdown. Further, upon completion of CSM-BIOS installation, Fedora isn't bootable by default because a hybrid MBR hasn't been created, requiring manual post install work to make it bootable. Same situation as F16. https://bugzilla.redhat.com/show_bug.cgi?id=746901 Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How can we make F17 be able to boot on Macs (with or without reFit)
On Mar 13, 2012, at 7:10 AM, Matthew Garrett wrote: > On Tue, Mar 13, 2012 at 03:06:31AM -0600, Chris Murphy wrote: > >> EFI Boot= Grub prompt, no menu > > Can you type "root" and see what it says, followed by "findiso" and then > "root"? USB stick: grub> root (hd0,2,a): Filesystem type unknown, partition type 0x0 grub> findiso grub> root (hd0): Filesystem type is iso9660, using whole disk DVD: grub> root (hd0,2,a): Filesystem type unknown, partition type 0x0 grub> findiso grub> root (fd256): Filesystem type is iso9660, using whole disk > >> EFI Boot= Grub menu, loads from stick for ~45 seconds then reboots machine > > That'll be a kernel bug of some description... > >> EFI Boot= Grub menu, loads from stick for ~6 seconds, then beeping, must >> force shutdown. > > This too. Can you try adding "noefi" to the kernel command line for > both? Makes no difference in either case. Same result. This is inserted after 'rd.dm=0'. > > CSM boots aren't expected to work in the slightest. But it does work. All the way to anaconda and installation. It's the EFI options that aren't working so far. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How can we make F17 be able to boot on Macs (with or without reFit)
Detail version of previous post's in-line summary results. Burned to DVD -- Macbook Pro 4,1 (2008) Four additional CD/DVD icon options labeled as: Windows, EFI Boot, EFI Boot, EFI Boot *2nd EFI Boot option has a custom Fedora logo icon, not generic CD/DVD icon. 1. Windows= Boots fine, all the way to anaconda. 2. EFI Boot= Grub prompt, no menu. grub> root (hd0,2,a): Filesystem type unknown, partition type 0x0 grub> findiso grub> root (fd256): Filesystem type is iso9660, using whole disk 3. *EFI Boot= Grub prompt, no menu grub> root (hd0,2,a): Filesystem type unknown, partition type 0x0 grub> findiso grub> root (fd256): Filesystem type is iso9660, using whole disk 4. EFI Boot= Boots Mac OS X. Macbook Pro 8,2 (2011) Three additional CD/DVD icon options labeled as: Windows, EFI Boot, EFI Boot *2nd EFI Boot option has a custom Fedora logo icon, not generic CD/DVD icon. 1. Windows=Boots CSM/BIOS mode successfully, to anaconda. 2. EFI Boot= Grub prompt, no menu grub> root (hd0,2,a): Filesystem type unknown, partition type 0x0 grub> findiso grub> root (fd256): Filesystem type is iso9660, using whole disk 3. *EFI Boot= Grub prompt, no menu grub> root (hd0,2,a): Filesystem type unknown, partition type 0x0 grub> findiso grub> root (fd256): Filesystem type is iso9660, using whole disk dd to USB stick -- Macbook Pro 4,1 (2008) Four additional CD/DVD icon options labeled as: Windows, EFI Boot, EFI Boot, EFI Boot *2nd EFI Boot option has a custom Fedora logo icon, not generic CD/DVD icon. 1. EFI Boot= Grub menu, loads from stick for ~45 seconds then reboots machine. When inserting noefi as kernel parameter, there is no change in behavior. FYI I'm inserting it right after 'rd.dm=0'. 2. *EFI Boot= Grub prompt, no menu grub> root (hd0,2,a): Filesystem type unknown, partition type 0x0 grub> findiso grub> root (hd0): Filesystem type is iso9660, using whole disk 3. EFI Boot= Grub menu, loads from stick for ~45 seconds then reboots machine When inserting noefi as kernel parameter, there is no change in behavior. Macbook Pro 8,2 (2011) Three additional CD/DVD icon options labeled as: EFI Boot, EFI Boot, EFI Boot *2nd icon is a custom Fedora logo icon, not generic USB icon. 1. EFI Boot= Grub menu, loads from stick for ~6 seconds, then beeping, must force shutdown. With noefi as kernel parameter, no change in behavior. 2. *EFI Boot= Grub prompt, no menu grub> root (hd0,2,a): Filesystem type unknown, partition type 0x0 grub> findiso grub> root (hd0): Filesystem type is iso9660, using whole disk 3. EFI Boot= Grub menu, loads from stick for ~6 seconds, then beeping, must force shutdown. With noefi as kernel parameter, no change in behavior. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How can we make F17 be able to boot on Macs (with or without reFit)
On Mar 13, 2012, at 2:07 PM, Matthew Garrett wrote: > > You pointed out that CSM installs don't work - the partition table is > entirely inappropriate for them. We're not planning on fixing that. CSM boot from install media does work. CSM installations don't reboot successfully, without manual creation of a hybrid MBR. While I understand the reluctance to support hybrid MBR, that is how Apple supports Windows CSM installations. I don't know which is more difficult, squashing the myriad VBIOS bugs with Apple EFI booting, or tolerating hybrid MBRs. Even with successful livecd-iso-to-disk USB stick boots in EFI, both of my test computers have outstanding video bugs that translate into no GUI. By successful, I mean the kernel, initrd, and services load - except for X and gnome/kde. I can ssh in and interact text only. https://bugzilla.redhat.com/show_bug.cgi?id=765954 https://bugzilla.redhat.com/show_bug.cgi?id=751147 Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How can we make F17 be able to boot on Macs (with or without reFit)
On Mar 13, 2012, at 3:37 PM, Matthew Garrett wrote: > Yes, and support for handling and managing hybrid MBRs is difficult. > Apple can manage it by simply constraining it to a very simple case. > Create more partitions and disk utility stops wanting to be your friend. > Trying to handle hybrid media in the larger number of storage cases we > have to support is a non-starter. Perhaps it's unreasonable to try to handle the larger number of storage cases with Apple hardware, at least in the short/medium term. Limiting the possible cases, it's at least possible to have a functioning system, with a GUI, using CSM-BIOS+hybrid MBR. With a wider set of cases, I have effectively a useless system in all such cases with EFI, as I have no graphics with either test hardware. And one of them I have neither graphics nor text with built-in display, I can only interact via ssh - requiring a 2nd system to do so. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17-alpha: UI unusable
On Mar 15, 2012, at 5:20 PM, Gerry Reno wrote: > > Can someone point out what is needed here or do I just file bug reports? I'd suggest installing something more recent, like F17 Beta TC1. http://dl.fedoraproject.org/pub/alt/stage/17-Beta.TC1/ Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17-alpha: UI unusable
On Mar 15, 2012, at 5:43 PM, Gerry Reno wrote: > Ok, I'll give that a try. > > Thanks. I suggest netinst.iso or livecd, and enable all the repos in anaconda, so that your installation is current from the first boot. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Chromium
On Mar 18, 2012, at 12:01 PM, Mike Chambers wrote: > Installed from spot's personal repo, seems it don't get on the internet > at all in F17. In F16 it worked fine (not sure if same version). > > Any ideas or problems with anyone else? No. I'm using F17 beta TC1, KDE, x86_64. I have manually added the google yum repo. To install I used: yum install google-chrome-beta which installed version 18.0.1025.108-127110. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17-alpha: UI unusable
On Mar 18, 2012, at 3:23 PM, Gerry Reno wrote: > Question then would be, can I do a yum upgrade to go from F16 to F17 or > F18 if things aren't fixed for F17? Might work. Not tested. What you're after is preupgrade. http://fedoraproject.org/wiki/Upgrading -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F17 Beta TC2, No Network Available, fail
Fedora-17-Beta-TC2-x86_64-DVD.iso It appears with TC2 that Updates and Test Updates repos are enabled by default. When the computer or VM do not have an internet connection, the installation hangs after disk partitioning/formatting. If the ethernet interface is disconnected (no cable) then I get a message: "No Network Available" Some of your software repositories require networking, but there was an error enabling the network on your system. If I make an network+internet connection, it proceeds, and I see all three repo options enabled by default: disk, Test Updates, and Updates. Surely after having downloaded 2.3G, this is not the intended behavior and is a fail. It's acting like a netinst.iso. But I don't see a bug filed against it yet. FWIW this is burned to a DVD or assigning the .iso to a VM's CD/DVD device. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
XFS rootfs required?
It's not an option with Fedora-17-Beta-TC2-x86_64-DVD.iso. I don't see anything listed in alpha, beta, or final release criteria that requires it, but it's been a past option. Summary is that mkfs.xfs isn't present on the DVD media, at least for x86_64. Bug here: https://bugzilla.redhat.com/show_bug.cgi?id=804779 For General Tests, Final release level, I see an XFS test case here: https://fedoraproject.org/wiki/QA:Testcase_anaconda_xfs_rootfs_on_disk_partition Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2015-07-01)
On Thu, Jul 2, 2015 at 9:45 AM, Stephen Gallagher wrote: > On Thu, 2015-07-02 at 10:33 -0500, Michael Catanzaro wrote: >> On Thu, 2015-07-02 at 09:55 +0200, Tomas Hozza wrote: >> > * AGREED: Netizen is not approved as spin. We approve the option >> > to >> > have netizen as optional suite in anaconda. Please work with >> > Workstation WG. (+7, 0, -0) (thozza, 18:48:50) >> >> Hi, maybe there was some misunderstanding about the Workstation >> installer, but we don't allow configuration of package selection. >> Users >> are expected to use GNOME Software once the system is up and running. > > There were two combined statements there. The first was that we would > consider making certain netizen-oriented options available at install > -time. The second is that we would prefer to see tooling and > configuration done inside the Workstation, KDE (and other?) > environments rather than as a separate spin. The Workstation live installer doesn't have any installation options. The UI isn't even present in the installer. It's a single payload, all or nothing. It would have to be done as a group in GNOME Software. The Workstation network installer has installation options. -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary/Minutes from today's FESCo Meeting (2015-07-01)
On Tue, Jul 7, 2015 at 3:18 AM, Tomas Hozza wrote: > > > On 02.07.2015 17:56, Chris Murphy wrote: >> The Workstation live installer doesn't have any installation options. >> The UI isn't even present in the installer. It's a single payload, all >> or nothing. It would have to be done as a group in GNOME Software. > > How is the Live installer different from the network installer? Is it > just some configuration thing, or are those completely different > installers? It looked like regular Anaconda last time I installed > Workstation. It's Anaconda in both cases, but the hub UI choices and installation methods are totally different. Netinstall (and DVD for server) the main hub shows Installation Source and Software Selection. Those spokes do not exist with Workstation (live media). In the background anaconda calls rsync for Workstation live installation, not dnf or rpm, so RPMs aren't actually installed. > I'm just trying to understand if you don't want to give the user the > option to choose the installation options from live CD on purpose (due > to user experience or such) or if there is some real issue? Well I think the installer is 90x more complicated than it needs to be for ordinary mortal users as it is. They don't have the familiarity with the software or knowledge to know what they should avoid. The very fact things are easily available through exploration causes problems. So I'd say it's both a real issue that lives are installed using rsync so to then switch to RPM installation afterward adds complexity to the software installation process both at the backend as well as additional UI options. The list of installation options on netinstall and DVD is, well it's out of control again. There must be over 100 possible installation combinations now. The advantage of network installation is there's a net reduction in download usage. With live, the user downloads 1.5GB, about 90% of which gets overwritten with updates after Fedora is about 3+ months out the door. Where DVD installations I see as pointless since everything on it is obsolete in short order. Note: Every product has a netinstaller, which are in effect all the same except their default package set selection. Then there are the primary product medias: Cloud has its images, Server has a DVD, Workstation has live media. And spins are (all? and entirely) based on live media. -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Hosting End-Of-Life Fedora Base images?
Isn't it true the install media ISOs are available indefinitely? And if so the security cat is already out of the bag, so that's not a very good argument. I'd say if we wanted to do something better it would be an image that's usable for both VM and containers, and would be the state of that version at the time it went EOL, i.e. it has all available updates baked into it. And then de-emphasize the original ISO as the way to run older versions of Fedora. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADS-UP] Please test kdbus in Rawhide!
On Thu, Jul 30, 2015 at 12:05 PM, Stephen Gallagher wrote: > For folks not keen to jump headfirst into Rawhide, is it expected that > this should work on Fedora 23 or Fedora 22 if one installs only the > kernel and systemd packages from Rawhide? That might make people more > comfortable trying it out (and get you more feedback), if so. I think this is in systemd 222 which is in Fedora 23, because kdbus is API stable in systemd 221. ? -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
"install devtools" in F22 live boot, device-mapper implosion
User over on users@ list reports booting Fedora 22 Workstation (live media), and doing: # dnf install "Developer Tools" Implodes. I've reproduced the problem, and the gist is that there's a dm snapshot that's too small for this task, it gets full quickly, the file system face plants, and the kernel oopses. No recovery is possible. Long version [1]. Question 1: Should this work better and be a supported use case? Question 2: If so how to fix it? Change the configuration for a bigger snapshot? Or use thin provisioning snapshot? Or overlayfs? I haven't tested livecd-iso-to-disk --overlay-size-mb option, but I give it better than even odds that for the baremetal case it will work and might be a suitable work around. Thoughts? [1] If a bug should be filed, let me know what to file it against. I have no idea what's responsible for the configuration of the install media's live environment itself. # dmsetup status live-base: 0 12582912 linear live-osimg-min: 0 12582912 snapshot 3664/3664 24 live-rw: 0 12582912 snapshot 230544/1048576 912 # dnf group install "Development Tools" ## I allow metadata to download. Total metadata downloaded 41MB (stable branch) and 13MB (updates branch). # dmsetup status [root@localhost ~]# dmsetup status live-base: 0 12582912 linear live-osimg-min: 0 12582912 snapshot 3664/3664 24 live-rw: 0 12582912 snapshot 484016/1048576 1896 So the snapshot is filling up. Continue with download and install of packages, while continue to check dmsetup status and eventually I get to this: [root@localhost ~]# dmsetup status live-base: 0 12582912 linear live-osimg-min: 0 12582912 snapshot 3664/3664 24 live-rw: 0 12582912 snapshot 691048/1048576 2704 [root@localhost ~]# dmsetup status live-base: 0 12582912 linear live-osimg-min: 0 12582912 snapshot 3664/3664 24 live-rw: 0 12582912 snapshot 703536/1048576 2752 [root@localhost ~]# dmsetup status live-base: 0 12582912 linear live-osimg-min: 0 12582912 snapshot 3664/3664 24 live-rw: 0 12582912 snapshot 716320/1048576 2800 [root@localhost ~]# dmsetup status live-base: 0 12582912 linear live-osimg-min: 0 12582912 snapshot 3664/3664 24 live-rw: 0 12582912 snapshot 716400/1048576 2800 [root@localhost ~]# dmsetup status live-base: 0 12582912 linear live-osimg-min: 0 12582912 snapshot 3664/3664 24 live-rw: 0 12582912 snapshot 716464/1048576 2800 [root@localhost ~]# dmsetup status live-base: 0 12582912 linear live-osimg-min: 0 12582912 snapshot 3664/3664 24 live-rw: 0 12582912 snapshot Invalid [root@localhost ~]# dmesg -bash: /usr/bin/dmesg: Input/output error Separately I had a journalctl -f running and it captures [ 928.709182] localhost kernel: device-mapper: snapshots: Invalidating snapshot: Unable to allocate exception. And then a long pile of ext4 errors. -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Is it time to allow Chromium in Fedora?
On Tue, Aug 11, 2015 at 12:41 PM, Gerald B. Cox wrote: > https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries Meanwhile, on OS X I was already given notification of Firefox being updated to 40.0.0 just a bit ago. And while I see Firefox 40.0 in koji, there are no Bodhi entries for it, so it's not in any repo. So I don't really buy any of the security arguments of either "no bundled libraries" or the FF exception to it. The delay appears to be packaging itself. Mozilla produces an OS X and Windows specific packages, and they update themselves rather than going through the OS update system. This doesn't happen on Linux, where it's expected Firefox gets updated by the distro repo and packaging system. Yet I see a Linux tar.bz2 for Firefox at downloads.mozilla.org so I wonder why that binary doesn't just run unmodified anywhere and I'm waiting for 40.0 to show up in Bodhi? -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Is it time to allow Chromium in Fedora?
On Tue, Aug 11, 2015 at 1:18 PM, Josh Stone wrote: > On 08/11/2015 12:12 PM, Chris Murphy wrote: >> Yet I see a Linux tar.bz2 for Firefox at downloads.mozilla.org so I >> wonder why that binary doesn't just run unmodified anywhere and I'm >> waiting for 40.0 to show up in Bodhi? > > If you don't see the value of distro integration and testing, then by > all means, go use mozilla's binaries. I do not see the value in manually checking koji for Firefox updates and then manually downloading and installing them. That's just not going to happen by pretty much anybody. I have u-t enabled, I do testing, this update is not in u-t yet. If I knew Mozilla's Linux binaries provided its own update mechanism and notification, yes I would do exactly that. And I'd still ask what the benefit is of duplicating this effort? It sounds like it's not actually a benefit, rather it's "because packaging". -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 kernel bug affecting LVM
On Sat, Aug 29, 2015 at 2:05 PM, Richard W.M. Jones wrote: > > I discovered an easily reproducible bug in Rawhide back in June which > affects LVM: > > https://bugzilla.redhat.com/show_bug.cgi?id=1237136 > > This breaks many LVM commands, eg. 'lvmchange -a ..' which is used > during boot. > > The same bug has now started to affect Fedora 23 because of the > backporting of the buggy kernel version to F23. > > I think this should be a blocker for the F23 release. How do I make > it so? Determine what release criteria the behavior violates. I'm not thinking of one off hand, if it's not breaking the installer in some way, or ability to boot the system. It's a bad bug but that doesn't necessarily mean it's a blocker. https://qa.fedoraproject.org/blockerbugs/ login, and then click on Propose and fill out the form. -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Oops on i686, 4.2.0-0.rc8, was: Summary/Minutes from...
On Sun, Aug 30, 2015 at 12:39 PM, Richard W.M. Jones wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=1258223 I have i686 hardware (ancient Dell laptop) running 4.2.0-0.rc8.git0.1.fc23.i686 for over 24 hours with some heavy btrfs + rsync stuff, and no oopses. What would I need to run to try to reproduce? And is there a meaningful difference this is an fc23 kernel, not fc24? -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Bad default error policy causes printing issues and BIG usability issues
On Mon, Aug 31, 2015 at 3:37 PM, Germano Massullo wrote: > Il 06/12/2014 19:29, valent.turko...@gmail.com ha scritto: >> Who is responsible for user experience of Fedora desktop? To whom >> should I point this issue to? > https://fedoraproject.org/wiki/QA > you could also fill a bugreport against CUPS component in > https://bugzilla.redhat.com/ > I agree with you. I migrated some offices to Fedora and sometimes I > receive phone calls about printing troubles. When I go personally to > check what is wrong I often saw a big CUPS queue and the printer in pause Like I mentioned today in the bug report, I think there's more going on here. Issue 1 is whether non-admins can create/delete/modify state of printers (queues); Issue 2 is more challenging, more information is needed on the various failures that seem to be more common on Linux than on OS X, both of which use CUPS. I don't know if there's usually enough information for CUPS to put a job on hold, rather than the queue. Some logic would need to be present or you get situations where jobs vanish because the queue isn't on hold and the printer isn't receiving data for some reason. There was a period on OS X where something similar happened, and new jobs printed just silently built-up or just vanished; but this behavior was replaced quite a long time ago when at print time the user gets an information dialog that the print queue is currently stopped, and asks if they want to add the job to the queue rather than print (because printing is offline). At least that way the user gets the notification that the print queue is stopped. -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: A backup service using fuse, sqlite and btrfs.
I have a better chance of seeding clouds to make rain than read code to get the answers to these questions, but I tried anyway. - Is this a versioning system, or is it both a versioning system and a backup? Backup implies copying data to a separate device. - If it's a backup, does it depend on the source being Btrfs? Or just the destination? Or both? - Do you envision Fedora Server and Fedora Workstation components, to achieve a sort of turn key + integrated Fedora solution for network backups? - Does this apply to just user data, or system settings as well, or the entire installation? --- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
grub2 wiki page
Can someone double check this before I make the change? https://fedoraproject.org/wiki/GRUB_2 1. Under "Install the bootloader files" grub2-efi-modules shouldn't be listed. An unsuspecting user who then uses grub2-install as they once did on BIOS systems will blow away the signed grubx64.efi file and boot will fail on Secure Boot enabled systems. 2. Also under "install the bootloader files" it lists the shim package, but this should be shim-signed in order to include the shim.efi that's been signed by the Microsoft signing service. The shim package only contains an unsigned shim. So the revised commands are: yum install grub2-efi shim-signed yum reinstall grub2-efi shim-signed Thanks, -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 cloud image (and, for that matter, minimal anything) bloat
On Mon, Sep 21, 2015 at 2:37 PM, Matthew Miller wrote: > On Mon, Sep 21, 2015 at 03:39:46PM -0400, Josh Boyer wrote: >> It's worth pointing out that your griping about grub2 "growth" seems >> misleading. The sizes of the grub2 packages did not change between >> F22 and F23. What seems to have happened is that the cloud images >> added the grub2 packages, which weren't there in F22. > > Sorry, yeah -- that griping is not out of context in the Cloud WG where > I also posted this, but is here. Grub2 has the huge virtue of *It > Actually Works*, a claim which currently none of the competition can > make. For the cloud image, extlinux actually works. The problem pops up with any image intended for baremetal whre UEFI Secure Boot support is needed, and right now GRUB2 does and extlinux doesn't, so any "atomic" image would need GRUB2. > But *that* said, the current packaging means that grub2 adds 70MB on > disk — about 12% of the entire cloud image. I'm not saying grub2 is > evil, just that this is a big portion of the gain and is worth > attacking in order to reverse it. I talked briefly to Peter Jones and > he says there's quite a bit which can be done there, if going back to > extlinux doesn't seem like a viable option. These are needed on BIOS systems grub2-tools is 7MiB grub2 is 3.8MiB These are needed on UEFI systems shim-signed is 633KiB grub2-efi is 837KiB So, I'm not sure where 70MB is coming from. All four are needed for the hybrid BIOS+UEFI supported media. So yeah I'd say it can shrink quite a bit. -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: grub2 wiki page
On Mon, Sep 21, 2015 at 11:51 PM, Yaakov Selkowitz wrote: > On Mon, 2015-09-21 at 19:20 -0600, Chris Murphy wrote: >> 2. Also under "install the bootloader files" it lists the shim >> package, but this should be shim-signed in order to include the >> shim.efi that's been signed by the Microsoft signing service. The shim >> package only contains an unsigned shim. > > Incorrect. The shim *SRPM* produces shim-unsigned, while the > shim-signed SRPM produces the shim binary package. I know, extremely > confusing, but it's shim you want. OK got it, thanks. -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
kernel reports package temperature above threshold, cpu clock throttled, mce event logged
Starting with kernel 3.9, I get frequent messages "CPU5: Package temperature above threshold, cpu clock throttled" followed by "CPU5: Package temperature/speed normal" and occasionally: kernel: mce: [Hardware Error]: Machine check events logged mcelog[581]: Hardware event. This is not a software error. This happens on three different Mac models, each running OS X and Fedora. They all get way hotter, run fans much faster, running Linux than OS X. I've had one of those models die inexplicably while it was exceptionally hot, but since it can't be booted at all now I can't say whether there's cause-effect or it's just coincidence. Since I'm down to just one Mac at the moment, I'm reluctant to do any further baremetal Linux testing until I better understand what these messages mean. https://bugzilla.redhat.com/show_bug.cgi?id=924570 ## my original bug on this from over a year ago https://bugzilla.redhat.com/show_bug.cgi?id=1050106 ## recent bug that has different diagnostic info Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
making custom kernels easier to build
Since it came up at Flock: if it's possible to incorporate this recent experiencing testing Btrfs patches it'd be nice. Two patches listed here, one is based on Btrfs integration branch, the other based on 3.16.0. I didn't realize the original patch was based on integration branch, which is apparently why it kept failing to apply with rpmbuild (and hence patch) on kernel-3.16.0-1.fc21.src.rpm. I'm told in this email that git am would have sorted this out for me. (?) http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg36299.html Request 1: if there's a more tolerant patch applying method with git that could be incorporated, even if it's just a step that converts the patch so that rpmbuild/patch will eat it, that would be nice. But if it requires a local git clone of upstream's dev branch, then ignore this part because I'm not going to do that. I'd sooner ask for a patch that applies onto something I'm actually going to build. Request 2: patches to just get picked up by dropping them somewhere, like rpmbuild/SOURCES/*.patch always get picked up and applied, rather than requiring two manually entered entries in kernel.spec per patch. Thanks, Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: making custom kernels easier to build
On Aug 11, 2014, at 3:28 PM, Chris Murphy wrote: > Since it came up at Flock: if it's possible to incorporate this recent > experiencing testing Btrfs patches it'd be nice. > > Two patches listed here, one is based on Btrfs integration branch, the other > based on 3.16.0. I didn't realize the original patch was based on integration > branch, which is apparently why it kept failing to apply with rpmbuild (and > hence patch) on kernel-3.16.0-1.fc21.src.rpm. I'm told in this email that git > am would have sorted this out for me. (?) > > http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg36299.html > > Request 1: if there's a more tolerant patch applying method with git that > could be incorporated, even if it's just a step that converts the patch so > that rpmbuild/patch will eat it, that would be nice. But if it requires a > local git clone of upstream's dev branch, then ignore this part because I'm > not going to do that. I'd sooner ask for a patch that applies onto something > I'm actually going to build. > > Request 2: patches to just get picked up by dropping them somewhere, like > rpmbuild/SOURCES/*.patch always get picked up and applied, rather than > requiring two manually entered entries in kernel.spec per patch. Request 3: Current instructions call for use of yum, yumdownloader, and yum-builddep. Can it be done entirely with dnf? I'm not sure what the dnf equivalent is for yumdownloader or yum-builddep. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Systemd boot issue
On Sep 9, 2014, at 7:46 AM, P J P wrote: > Is there a way to debug what Systemd is doing after printing above message?? http://fedoraproject.org/wiki/How_to_debug_Dracut_problems http://freedesktop.org/wiki/Software/systemd/Debugging/ In such a case I always use rd.break to hopefully get a dracut prompt if the initramfs is failing. If that doesn't work and you still get a hang, then you'll need to read about rd.break= and setting it for a point prior to the failure to isolate. rd.debug will include a huge pile of everything the initramfs is doing, you might avoid this until you know whether it's the initramfs or systemd unit or service giving a problem. systemd.log_level=debug will produce quite a bit of systemd debug text. When I'm impatient I used both debug options at the same time, but it makes boot much slower. If you manage to get to a shell, journalctl -b -l is helpful since it's available in very early boot. Another possibility is if you can boot single user (emergency.target) successfully and enable the systemd early debug shell. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Systemd boot issue
On Sep 10, 2014, at 2:28 AM, P J P wrote: > Hi, > >> On Wednesday, 10 September 2014 12:28 PM, poma wrote: >> dr. acut? > > Can't say for sure. I added "rdshell rd.debug" parameters to the boot command > line, again it throws a long list of debug messages from - > /lib/dracut-lib.sh@xxx. Messages are about trying to setup > /etc/sysconfig/network-scripts and dhclient(8) configurations it seems. It > has snippets like > > for f in '"/$_dir"/*.sh' > '[' -e //lib/dracut/hooks/cleanup/10-kill-dhclient.sh ']' > . //lib/dracut/hooks/cleanup/10-kill-dhclient.sh > > for f in '/tmp/dhclient.*.pid' > '[' -e '/tmp/dhclient.*.pid ' ']' > continue > ... > /bin/dracut-pre-pivot@29(): exit 0 > systemd-journald[2842]: Received SIGTERM > systemd-journal (2842) used greatest stack depth: 12920 bytes left > > Note:- Systemd(1)/dracut(8) debug logs are serious information overload. They > zoom past through the screen inundating it with thousands of lines, you can > not even see them all. What's the point? Anything that passes by almost certainly worked correctly so you don't need to see it. It's where it gets stuck that this level of verbosity can be useful. > > Anyway…any clue? Well I have no idea what's on the screen at the time of the hang. Maybe a cell phone photo would be useful. Or maybe you should use the debug kernel which was one of Paul Wouters suggestions. Or you could go out on a limb and see if the problem is happening with 3.17rc4 non-debug which is http://koji.fedoraproject.org/koji/buildinfo?buildID=575871 There are lots of kernels. Unless you really want to do kernel troubleshooting, you might just pick a kernel that works. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Systemd boot issue
On Sep 11, 2014, at 2:51 AM, P J P wrote: > Hello Chris, > >> On Wednesday, 10 September 2014 9:15 PM, Chris Murphy wrote: >> Well I have no idea what's on the screen at the time of the hang. Maybe a >> cell phone photo would be useful. Or maybe you should use the debug kernel >> which >> was one of Paul Wouters suggestions. Or you could go out on a limb and see >> if >> the problem is happening with 3.17rc4 non-debug which is >> http://koji.fedoraproject.org/koji/buildinfo?buildID=575871 >> >> There are lots of kernels. Unless you really want to do kernel >> troubleshooting, >> you might just pick a kernel that works. > > Yes, I've resorted to 3.15 for now. Will look at 3.16 again later, got a > sosreport yesterday by trying 3.16 on a F20 VM. If you can reproduce this hang in a VM things are much easier to troubleshoot by setting up a serial console; and then booting the VM with params: rd.debug rdudevdebug systemd.log_level=debug systemd.log_target=console console=ttyS0,38400 That'll be extremely verbose, but at least you can scroll. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Improving the offline updates user experience
On Sep 12, 2014, at 9:47 AM, Richard Hughes wrote: > The *only* way to do this > securely and safely in the system we have now is in a clean pre-boot > environment, Mostly clean post-boot environment, with the system we have now? > What we could do is do updates on shutdown by basically killing > everything except PID 1, and then restart everything, but even then > that relies on no systemd or kernel updates being present. Even if the system is fully rebooted once, after the update is done in a post-boot environment, it's half the reboots needed now. One step up from this would be a way for packages to contain metadata indicating they need a reboot after an update; if none require it, then isolate graphical.target rather than a reboot. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Decision on Fedora Product branding: Fedora $PRODUCT 21 vs Fedora 21 $PRODUCT
On Oct 21, 2014, at 9:36 AM, Matthew Miller wrote: > On Tue, Oct 21, 2014 at 08:28:16AM -0400, Stephen Gallagher wrote: >> A few specific comments that have been made on the Board ticket (to >> avoid rehashing them). >> >> * "Fedora Server 21" sounds like we've had 21 releases of Fedora Server >> and we certainly haven't. >> * Should we start all of the Products at version 1 and say "built on the >> Fedora 21 platform"? > > My opinion is that since we've decided on a unified lifecycle and > release process for now, we should reflect that in the names, so: > > Fedora 21 Cloud > Fedora 21 Server > Fedora 21 Workstation Yes. Since people have a tendency to shorten, I think we'll see "F21C, F21S, F21W" as a result. That's probably better than "FC21" for cloud where it's confused with .fc21 in all of our RPMS, and even vernacular people still interchange F20 and FC20 calling back to Fedora Core days. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewalld enable by default in Fedora 22
On Thu, Feb 26, 2015 at 4:19 PM, Carlos Morel-Riquelme wrote: > I install F22 workstation today and well firewalld is enable by default. So > the disable firewall in F21 is out ? It's enabled by default in Fedora 21 Workstation also. No change. # firewall-cmd --list-all FedoraWorkstation (default, active) interfaces: eth0 virbr0 sources: services: dhcpv6-client mdns samba-client ssh ports: 1025-65535/udp 1025-65535/tcp masquerade: no forward-ports: icmp-blocks: rich rules: -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCo Meeting Minutes (2015-03-04)
On Thu, Mar 5, 2015 at 8:41 AM, Adam Jackson wrote: > On Thu, 2015-03-05 at 00:45 +0100, Kevin Kofler wrote: >> Adam Jackson wrote: >> > * #1412 anaconda password change is causing consternation among the user >> > community please review this policy decision (ajax, 18:24:10) >> > * AGREED: FESCo would like anaconda to turn back on the "double-done" >> > option for Fedora 22. >> >> Thanks! >> >> > Better solutions should be investigated for F23. (ajax, 18:43:33) >> >> What better solutions? What password I pick should be none of the >> installer's business. > > False. It's entirely reasonable for a product to mandate an appropriate > security policy, Ajax, when you say things like this, this is what it sounds like "Hey, nice football you have there. Guess what? I'm gonna TAKE THAT BALL FROM YOU!!" I consider this an invitation to scrimmage. How serious does a random person take a game? You don't really know how seriously they take it, do you? How dirty will they get? Is mud OK? Cuts and scrapes? Elbows to the face? This is why there are rules so both parties know how bad it could get in advance, and know whether the game is worth playing or not. There is no actual game here, because it hasn't been played in something like 30 years. The user has the ball when it comes to their devices. It's completely ceded, the ship has sailed, no one touches this in any meaningful way. The most significant change to password enforcement in this time? Mobile. No lock even required. How about websites? They have a ball sharing program. The rules are clearly stated in advance. I cede that the site has a lot to lose in reputation if my account is breached, and even my friends, family, and the site's customers can be at risk too. So even if I don't like all the rules, I tacitly accept the ultimate authority, and the higher password burden. Their system isn't really my device after all is it? My device? I have the ball. You wanna try and take it away from me? *grin* I'm not daring you or anything. This wasn't my idea. I really don't want to fight. But when you say "appropriate" as an adjective, I hear it as a verb which means to take something away without my permission. And since this game hasn't, to my knowledge, ever been played before, what are the rules? How vicious will it get? Are you really prepared to find out? How well do you take elbows to the face? I think I can take them pretty well. Do you not see the escalating can of worms, just by the choice of language you've selected? It's asking for a fight whether you recognize it or not, whether you intend it or not. Maybe you're just confused. Maybe Anaconda thought I really wasn't that attached to the ball, because they don't get outdoors all that much. But it was all just a simple misunderstanding. No harm done! I think Fedora users are more well grounded than their Windows and OS X counterparts. Apple, Microsoft, Google, they haven't dared to look the user in the eye and suggest the ball isn't theirs when it comes to their own device. Bet they've looked into it. If they were to do what Anaconda just did (and, that's twice now), I'd expect entire new categories of profanity being invented overnight. I'd expect those companies would prefer a zombie apocalypse, hindsight being 20/20 and all. So. Ajax. I see you looking at my ball. Now I understand for legacy/historical reasons, the installer sets the password as a practical matter because there hasn't been a first boot setup program that does this. That's entirely different from a minimum password quality enforcement policy. The best we can do in the area of passwords is make them unnecessary; second best is something like an OpenSCAP application that can run on any DE that helps the sysadmin (who by in large is the single user for the system) do a better job setting strong passwords and disabling risky services, etc. But right now Fedora is being really dissonant, because we're suggesting a fight with the user after decades of giving up on that battle. Really? Why now? Meanwhile, Fedora enables sshd on Server by default. That's opt out, not opt in. By making sshd disabled by default it puts in on par with the password: both become opt in, both states are transparent to the user. You do not get to hand waive about risky services that are silently enabled by default while blaming the user (for their password as well as not disabling a service they didn't know was on in the first place). OK please stop looking at my ball, you're making me nervous. We do have serious problems, and we really need a big picture OS overview for making secure systems the default, and more easily hardening them further. But right or wrong, i
Re: FESCo Meeting Minutes (2015-03-04)
On Fri, Mar 6, 2015 at 7:15 AM, Adam Jackson wrote: > So this entire thing is about you reading as a verb something clearly > syntactically an adjective? I'm not sure how I can respond to that. Do you acknowledge it's a historical fact that the user password for a local device has been exclusively user domain? If no, give counterfactual examples. You said a product can properly mandate otherwise. Where does the authority or sanction come from to do this? Just by saying it is so, and then just by doing it? -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCo Meeting Minutes (2015-03-04)
On Fri, Mar 6, 2015 at 11:07 AM, Stephen John Smoogen wrote: >> Do you acknowledge it's a historical fact that the user password for a >> local device has been exclusively user domain? If no, give >> counterfactual examples. >> > > You need to dial back the dialogue a bit. The original email came across as > an out of control rant that lost me after the third sentence. If instead of > trying to win "Flame of the Day" award and being less metaphorical and more > factual.. it might go a long way to having a conversation versus a man and a > soap box in a park. That the metaphor doesn't work for you is fine. However, while you castigate the method, you ignore the questions seeking out the facts = that which is not in dispute. >> >> You said a product can properly mandate otherwise. Where does the >> authority or sanction come from to do this? Just by saying it is so, >> and then just by doing it? >> >> > > It is a two way street. You own the device. They make the OS. Each is their > own 'ball' if I am using your original metaphor appropriately. Each sees the > other as the field the ball gets played on. If you don't like the field that > your ball is playing on you are free to ask for something to be changed. If > it doesn't get changed you can go find another field to play on. And vice > versa. Your version is not at all the direction I was going in. But I'll go along with your version No other field (OS) asserts any concern for what ball (password) I bring. Any ball shape and size is accepted. Suddenly, one field's referee asserts rules that only particular ball sizes and shapes are allowed. The rules aren't actually specified anywhere, I must show the ball and the referee either accepts or rejects it on a pass fail basis. The minimum ball size and acceptable shapes aren't stated in advance. I merely get binary feedback. By iterating, and making some assumptions, I can infer the requirement means I can bring a large box instead of a ball. And after I pass the referee, I can remove my ball from the box and use it on the field. Ergo, I'm simply being harassed. I can't take the referee seriously at all, just appease his demand. Next, the referee asks for a field wide enforcement of his rule that no one clearly understands or agrees with; and none of the field managers (product working groups) even asked for the rule in the first place. > I am not saying this is the best way to handle things, but when everyone > seems that the only way to communicate is jumping up and down on a soap box > claiming the other side is completely in the wrong.. "how to handle things > better" has long been thrown out. Fedora has a rather Socratic mechanism for avoiding this. Twice now, Anaconda hasn't voluntarily submitted to this process on the same issue of password UI behavior. And therefore a heated debate was inevitable in my opinion. Anaconda has made an unasked for and abrupt change without having met a reasonable burden of proof for the claim this is necessary, again this is two for two. Then, as now, in over 100 emails, there are no proponents for the change outside Anaconda. And now, no proponents of the change by any product working groups. Leading a present or future conversation on platform security policy should probably not lead with "we can take your ball away anytime we want." I estimate it's in the vicinity of distinctly unhelpful for positively progressing the conversation. I'm open to suggestions. -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
