Re: Heads up - Anaconda 22.17 will enforce 'good' passwords
Once upon a time, Adam Williamson said: > There's no policy (AFAIK) on what is and is not a Change. FESCo has > the power to effectively declare something to be a Change (and thus > subject to review and so forth) if it decides to do so, but there's > nothing beyond that. And as I said to otherChris, 'without open > discussion' is just plainly false. There's a ton of 'open discussion', > spread across three mailing lists. There was discussion about a different proposal on devel, apparently discussion about this change by anaconda devs, and then the announcement here that the change had been made (no discussion until after the fact, and all "discussion" about not liking the decision being largely met with a response of "too bad"). It is not reasonable to expect everybody interested in Fedora to subscribe to the anaconda developer list (which isn't even a Fedora list, but a Red Hat list); there are dozens of Fedora mailing lists, and the vast majority of people cannot keep up with all of them. > Eh, that seems like a pointlessly loaded question. I mean, in a sense, > sure, they always have. They *write the installer*. That's always > going to involve some degree of 'determining system policy', if you > interpret that phrase broadly enough. What do you want, every anaconda > commit to go through a committee review phase? Hyperbole much? The majority of anaconda commits don't make significant changes to installed system policy. When they do, they tend to be discussed (not just announced) on other lists. For example, see the recent thread about /boot and /var and mkfs. Somebody _asked_ if that would be a big deal, people spoke up, and the input was accepted and the change modified. > And 'recourse' seems like such a weird word that, again, I don't > really know how to reply to it. You can discuss the decision, in a > respectful fashion, here or on devel@ or on anaconda-devel-list at . You > can take it up with FESCo. You could also, of course, wait more than > one lousy day to give the devs a chance to reply before whipping up a > storm of righteous indignation, but so often that seems too much to > ask? Again, "be excellent to each other"? This change was _announced_ here, not discussed (and some responses make it sound like it is not open to discussion). There was no real justification for the change in the announcement, except for a vague "better security" bit. That will almost always cause a negative response from people that disagree. -- Chris Adams -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Heads up - Anaconda 22.17 will enforce 'good' passwords
Once upon a time, Adam Williamson said: > It's not actually something that is part of the Change's scope, but an > alternative way to try and achieve the same goal: the overall thought > process was "well, what the Change proposer really wants is to reduce > the likelihood of compromise via password access to the root account, So, why didn't this change have to go through a proposal? The original change was rejected (which should show there is disagreement about this), so such a change should not just be pushed without open discussion. If there is disagreement about this change, is there no recourse? Or do anaconda devs get to determine system policy now on their own? -- Chris Adams -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: what in fedora rawhide replaces "pdftk" for extracting pages from PDF file?
Once upon a time, Robert P. J. Day said: > wait, hang on, that will extract every single page into its own PDF > file -- can i not ask for a range of pages to be extracted into a > single file? is there an option i'm overlooking? You could use a combination of pdftops (from poppler), psselect (from psutils), and ps2pdf (from ghostscript). I think they should even work in a pipeline, like (to get pages 1,3,5): pdftops foo.pdf - | psselect -p1,3,5 | ps2pdf - foo-pages1,3,5.pdf -- Chris Adams -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Fedora 20 Swastika
Once upon a time, Michał Piotrowski said: > I think that for a sake of everyone who can see a swastika on this > wallpaper, just change it to something else. I disagree. There will _always_ be somebody that can find fault with anything (especially something as subjective as artwork); you can't just throw away somebody's work because somebody sees something they don't like. I just see a slanted "H", which I presume to be the intent. -- Chris Adams -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Moving away from reporting to RH bugzilla and adopting pure upstream reporting mantra.
Once upon a time, Jonathan Kamens said: > Rather, it feels to me like > you've already made up your mind and are just putting on a show of > listening to other people's opinions before going ahead and doing > what you wanted to do all along. If you have read Jóhann's previous posts, he believes that Fedora should be completely separated from Red Hat. Though he has not mentioned it in this discussion, I believe that is what is driving his desire to stop using RHBZ (even if there is no satisfactory replacement). -- Chris Adams -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Windows 8 EFI unbootable after F19-TC1 installation.
Once upon a time, John Reiser said: > As a diagnostic, please run "efibootmgr --verbose" and post the output. > This will show what fedora thinks is the boot order and parameters > for EFI booting. That probably won't work for the original poster; installing from PXE will result in a system that boots from BIOS, and you can't see the EFI info from a BIOS boot. -- Chris Adams -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18, F19 webalizer problem?
Once upon a time, Jonathan Kamens said: > This, however, is fine: > > [ "$WEBALIZER_CRON" != yes ] > > because the quotes ensure that the statement will be evaluated with an > expression to the left of the != even if the expression is just an empty > string. > > This is fine too: > > [ z$WEBALIZER_CRON != zyes ] > > because if the variable is empty, the expression to the left will be "z" > rather than an empty string. The reason some use a combination of quotes and a leading character is for testing user-provided input. It shouldn't matter in this case, but it is just a little bit more defensive programming. The problem if you are testing a user-provided variable is that they could give input that starts with a dash, a close bracket, etc., and that would screw up the test. Putting a character at the start protects against that. Also, always quoting the variable is good programming practice; it could have whitespace in it, in which case the non-quoted version would expand to multiple tokens (and again break). So, still today, the best defensive way is: [ "z$WEBALIZER_CRON" != zyes ] -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Updates for f19?
Once upon a time, Bruno Wolff III said: > Is there an estimate on when updates will be getting merged into the > release again. There are some packages that have pending requests for > stable that are not in the test repo. This includes the postgresql > security update (that had stable karma before it was pulled into a test > repo) and a bunch of kde stuff that was in the test repo but isn't now. It looks like development/19 just got updated. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Another UEFI testing request
Once upon a time, Chris Adams said: > The system is a Zotac Zbox nano AD10. I downloaded the image from the > above URL and put it on an SD card and did a UEFI boot. I don't have > anything current on the drive, so I chose not to preserve anything. I > tried a minimal install; no problems up to the bootloader, which gave me > an "unknown error". I had time to try this again (if it still matters). When installing the bootloader failed, I switched over to a console and poked around. I do see this in the /tmp/anaconda-tb-xxx file (I assume this is the problem): 20:27:54,549 WARNING kernel:[ 2404.617141] efivars: set_variable() failed: status=8009 This is with the Alpha-TC5 netinst boot image (installer kernel 3.9.0-0.rc4.git10.1.fc19.x86_64), using a local mirror of current development/19 and updates/testing/19. I am running the latest BIOS on my Zbox. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Another UEFI testing request
Once upon a time, Adam Williamson said: > Hi folks - thanks for helping out with the last UEFI testing request, it > was very helpful. If we could impose again, it would be really helpful > if anyone with a UEFI-capable system could try a UEFI native install of > Alpha RC3: > > https://dl.fedoraproject.org/pub/alt/stage/19-Alpha-RC3/ > > and report your results. We are hopeful that the major bugs that > affected previous builds are resolved, and many or most UEFI installs > should succeed at this point. If you try, please report whether you got > a successful installation, and if not, what problem you ran into. Bug > reports for problems are of course welcome. Thanks! I tried a UEFI install, but it failed at installing the bootloader. The system is a Zotac Zbox nano AD10. I downloaded the image from the above URL and put it on an SD card and did a UEFI boot. I don't have anything current on the drive, so I chose not to preserve anything. I tried a minimal install; no problems up to the bootloader, which gave me an "unknown error". Also, I tried to report the failure to BZ or save it, and I got another "unknown error". -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: p7zip-plugins and rar extraction.
Once upon a time, Kevin Martin said: > What is the reason that rar archive extraction support is not included in the > 7z.so in the p7zip-plugins rpm? In the p7zip SRPM SPEC file: # RAR sources removed since their license is incompatible with the LGPL In a package review attempt for "unrar": https://bugzilla.redhat.com/show_bug.cgi?id=319831#c25 I spoke via email to Eugene Roshal about this issue. He was unaware that clamav had used derived code from their implementation in clamav, under the GPL license, and stated that he did not grant them permission to do so. He said that the only way he was willing for such code to be used was with a clause like the following: "The unRAR sources cannot be used to re-create the RAR compression algorithm, which is proprietary. Distribution of modified unRAR sources in separate form or as a part of other software is permitted, provided that it is clearly stated in the documentation and source comments that the code may not be used to develop a RAR (WinRAR) compatible archiver." Unfortunately, such a restriction conflicts directly with the GPL, and is a showstopper. This code cannot go into Fedora as is. All RAR v3.x support would need to be stripped out, before it could be considered. Given that most RAR files are RAR v3, that severely limits the usefulness of this application. Basically, the only documentation of the file format is in the unrar source code, and it is under a non-free license. I don't think anyone has tried to reverse engineer it to make a clean-room implementation. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: UEFI testing of F19 Alpha RC2 requested
Once upon a time, Adam Williamson said: > https://dl.fedoraproject.org/pub/alt/stage/19-Alpha-RC2/ I'll give this a test (I've got one older UEFI system that wouldn't work with F18 anyway). One question: can I just download the netinst and point it at a local development/19 mirror, or do I need to download the full DVD? Alternately: is it sufficient to just boot from the images in my local development/19 mirror (so I don't have to download anything new)? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18 doesn't see full laptop screen resolution
Once upon a time, Adam Jackson said: > If I can abuse this thread for design discussion for a moment, what if > instead of the grub editor horrorshow for things like this, we had a > list of debugging tickboxes you could check that appended the right > thing to kcmdline (and just remember the defaults for them across > boots). That way you're not writing two boot stanzas for every kernel, > and it's more obvious that: > > [X] Disable accelerated graphics > > is something you should just uncheck. That would be nice. Another useful option would be rescue/single-user mode. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Fedora 18 Beta Test Compose 1 (TC1) Available Now!
Once upon a time, "Jóhann B. Guðmundsson" said: > The one in the installer should simply be removed since experienced > users/administrators configure ntp after install or in their kickstart > file and firstboot takes care of the rest. No, the installer _should_ allow you to set the clock (or offer to use NTP if network is available). Otherwise, if the clock is off, you end up with a confusing system. You _must_ set the timezone if the system clock is not UTC (which is still the most common case and will be for the forseeable future). There are many timestamps used during install (config file modification times, RPM database has package install times, etc.), and it is dumb that the installer essentially treats these as random numbers. At a minimum, the installer should at least _show_ what it thinks the time is after setting the timezone. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: When will the mirrors be updated?
Once upon a time, Stephen John Smoogen said: > On 20 September 2012 10:12, Chuck Forsberg WA7KGX N2469R > wrote: > > yum update is up to rc6 on the kernel, but > > > > mirrors1.kernel.org::fedora/development/18/x86_64/os > > > > is only at rc2. When will the development tree be updated? > > mirroring is a pull technology not a push technology. EG we can update > all we want but it is up to the mirror to pull the data down to their > servers. In cases where a mirror is way behind you need to contact the > mirror administrators and let them know. Yeah, you say "mirrors" and then list one. Looking into it more though, the problem appears to be that you are looking in the wrong place. I have kernel-3.6.0-0.rc6.git0.2.fc18 in updates/testing/18, not development/18 (which IIRC is normal post-Alpha). My mirror synced that a couple of days ago (Sep 18 20:15 UTC). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: New Anaconda - BACK, BACK, BACK...
Once upon a time, Dan Vratil said: > For me "Back" is associated more with "revert" or "undo" action. I think the > button should say something like "Back to menu" or even better "Save and > return to menu" so that even "dumb average computer guy" can understand that > he/she won't lost the settings made on the current page. Or in other words, > it > should somehow indicate that it's a confirmation of the changes. Maybe "Continue"? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [criteria update] Anaconda and network-attached storage devices
Once upon a time, Petr Schindler said: > Because of changes in new anaconda [1] and after short discussion with > Chris Lumens, I propose to remove this final criterion [2]: > > 'The installer must be able to complete an installation using any > network-attached storage devices (e.g. iSCSI, FCoE, Fibre Channel)' > > Reason (according to Chris): (This feature) will not be supported for this > release, > but will be back for F19. There's simply not the time to do this. I understand anaconda is undergoing a significant and needed rewrite, but is it wise to ship a release with a whole lot of installer functionality removed? Maybe F18 should wait until anaconda is ready. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [criteria update] Rescue mode
Once upon a time, Petr Schindler said: > Because of changes in new anaconda [1] and after short discussion with > Chris Lumens, I propose to remove this beta criterion [2]: > > 'The rescue mode of the installer must be able to detect and mount > (read-write and read-only) LVM, encrypted, and RAID (BIOS, hardware, and > software) installations' > > Reason (according to Chris): There's been no work done on rescue mode > and it is highly unlikely that it does anything at all right now. You've proposed removing rescue mode criteria from both alpha and beta; is there going to be any requirement for a functional rescue mode for this release? That's a pretty critical thing to have completely missing from a release; things that occasionally happen such as a broken boot loader would render an install virtually unrecoverable for many users. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: yum update failed today with....
Once upon a time, Kevin Martin said: > Transaction Check Error: > file /usr/bin from install of > google-chrome-unstable-20.0.1115.1-133713.x86_64 conflicts with file from > package > filesystem-3.1-1.fc18.x86_64 It looks like a bunch of the common directories have been changed to read-only in the filesystem package (haven't seen any notice/discussion about that, but maybe I missed it). The other issue would be: why is google-chrome-unstable (wherever you are getting that from) packaing the /usr/bin directory? It shouldn't do that. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Move from /media to /run/media/$USER
Once upon a time, Steven Stern said: > On 04/13/2012 12:25 PM, John Reiser wrote: > > On 04/13/2012 06:48 AM, Bill Nottingham wrote: > >> Release notes seem fine. Basically, removable media mounted in the > >> user's session are now mounted in a user-specific directory. > > > > There's still a problem: cold-plugged media, or even warm-plugged media. > > Cold-plugged (before boot) should be mounted under /media as soon as > > udisks2 runs. > > Warm-plugged (after boot but before login) probably should be, too, > > although there's room for discussion regarding /media/ versus > > /run/media/$next_console_login/, particularly for multi-seat > > operation > > (Plugable.com, etc.), but particularly including login on either text or > > graphical > > local console. > > > > However, they aren't recognized [mounted] at all (not even upon subsequent > > graphical > > login), and this is bad. See > > https://bugzilla.redhat.com/show_bug.cgi?id=722712 > > where there is some argument whether udisks2 or gvfs should bear the blame. > > > > It can be handy to have a "permanently" mounted CD/DVD or USB2.0 flash > > device. > > > This behavior messes up a bunch of scripts I've written that assume the > external USB drive "MyBackupDrive" will be hooked up as > "/media/MyBackupDrive" no matter who's logged in when it's plugged in. > Phooey. Yeah, is there a way to disable this behavior? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Install Fedora Button for LiveCD
Once upon a time, Matthias Clasen said: > That really depends on what use cases we see for our live cds. In my > view, there's really only two: > > The primary use for a live cd is to install. That's the primary use of the install media. The primary use of the live media is to boot a live system. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Notice: IPv6 breaking issues tentatively considered blocker for F17
Once upon a time, Adam Williamson said: > To be more precise...DHCPv6 is blocked. So I guess if you used a static > network config it would work. DHCPv6 is not the only way to configure dynamic IPv6; my home network is using SLAAC. IMHO that will probably be more common in home and other small networks. The only thing I'd be missing for v6-only would be the ability to set an equivalent for "next-server" for PXE booting, but I don't think the PXE stacks support v6 anyway, so it's a moot point. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Grub2 mkconfig
Once upon a time, Adam Williamson said: > On Thu, 2012-02-23 at 09:40 -0600, Chris Adams wrote: > > That's what I used to do, but it didn't work for me with F16 and GRUB2. > > I get a warning that I shouldn't install GRUB2 to a partition and then > > an error about there not being enough space. > > You can use --force to make grub2 install to a partition. If I run "grub2-install /dev/sda6", I get: /sbin/grub2-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea.. /sbin/grub2-setup: error: embedding is not possible, but this is required for cross-disk install. --force makes no difference. /dev/sda6 is actually part of a software RAID1; "grub2-install /dev/md3" segfaults. Somebody else has already put this in BZ as 788830. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Grub2 mkconfig
Once upon a time, Michael Schwendt said: > Is it a single /boot partition shared by multiple dists? > If so, that has always been just an ugly work-around to escape from having > to repartition. I prefer individual partitions for each dist plus > installing each dist's boot loader in the partition's boot sector and > chainloading them from GRUB (which still works with GRUB2). That's what I used to do, but it didn't work for me with F16 and GRUB2. I get a warning that I shouldn't install GRUB2 to a partition and then an error about there not being enough space. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Release criteria proposal: 'support' /boot on RAID
Once upon a time, Ian Pilcher said: > On 11/15/2011 04:20 PM, Adam Williamson wrote: > > "The installer must be able to create and install to software, hardware > > or BIOS RAID-0, RAID-1 or RAID-5 partitions" > > > > Mo has already written up a test case for /boot on RAID which we can use > > to test this in future. > > > > Any thoughts, modifications, objections? Thanks! > > You probably want to be clear that /boot is RAID-1 only (unless grub2 > has *really* come a long way). That limitation is specific to Linux-md I believe; doesn't grub uses the BIOS to access the drive(s)? If so, I think BIOS-RAID (and of course hardware RAID) should be transparent and work fine. Old-grub also didn't support newer Linux-md metadata formats, so that should be explicitly mentioned (I don't know about grub2). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Partition labels containing a slash in their names
Once upon a time, John Wendel said: > But, a partition label isn't a filename, is it? Just curious. No, but the entries in /dev/disk/by-label are. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: / must be on a partition or LV that will be formatted. Reusing an existing / is not allowed.
Once upon a time, David Lehman said: > I didn't realize lvm guarantees all lvs are allocated from adjacent > extents. When extents are available, they are allocated sequentially as you create LVs. There's no guarantee (since the extents could be fragmented if you have created and removed LVs), but on an empty VG, you'll get them that way. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: / must be on a partition or LV that will be formatted. Reusing an existing / is not allowed.
Once upon a time, David Lehman said:
> Ah, yes. Same bug for partitions. Presumably also for raid.
Oh, you said it worked for you. What version were you testing?
> anaconda-16.18-1 added support for specifying reserved space in a _new_
> vg for snapshots or whatever. I'm adding it to the wiki options page
> now. The new options are both to the volgroup command:
>
> --reserved-space= (reserved space in mb)
> --reserved-percent= (reserved percentage of vg space)
Go to know.
> Why do you care about the ordering of the LVs?
Because ordering affects performance. For example, I set up a separate
LV "queue" for the mail queue on a mail server; I also have a separate
LV for /usr/local ("usrl", grows to fill the VG, minus space for
snapshots) and /var ("var", where the logs live). Anaconda orders LVs
alphabetically (last time I checked), which could put the mail queue and
mail logs at nearly opposite ends of the disk.
> > Anaconda also doesn't allow custom RAID configuration options, such as
> > metadata versions, chunk size, bitmaps, creation of RAID with missing
> > devices (or IIRC RAID1 with 1 drive) for later expansion.
>
> We do create bitmaps where they make sense when creating md arrays since
> around F13.
That covers one option.
I don't necessarily expect anaconda to expand to cover all the available
options, but at the same time, anaconda shouldn't prevent admins from
using the available options via %pre.
--
Chris Adams
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Re: / must be on a partition or LV that will be formatted. Reusing an existing / is not allowed.
Once upon a time, David Lehman said: > You found a bug. We don't honor fsprofile when --useexisting is passed > to the logvol command. If you file a bug it can be fixed pretty easily. > Or, if you just let anaconda create your logical volumes for you you > won't hit the bug. I wondered if that was the problem. However, I also don't see my test settings applied to /boot. > Out of curiosity, why are you doing the partitioning and lvm stuff in % > pre? Anaconda doesn't give any controls of ordering or layout of LVs. For example, I use LVM snapshots for backups. I create the LVs with a little empty space at the end to use for the snapshot (so it stays close to the original data). I also then need to leave a certain amount (that I figure in percent) of the VG free for snapshot space. I've also used mirrored LVs for some setups in the past. I actually did that with a crazy hack that involved bind mounting a wrapper script over lvcreate (so I didn't do partitioning/LV setup in %pre). :-) The ordering wouldn't be hard to handle in anaconda, but the other things would be tricky. I guess if anaconda had ordering controls, I could use a bunch of scratch LVs in between each "real" LV (and then delete the scratch LVs in %post). That might also work to reserve space for snapshots. Anaconda also doesn't allow custom RAID configuration options, such as metadata versions, chunk size, bitmaps, creation of RAID with missing devices (or IIRC RAID1 with 1 drive) for later expansion. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: / must be on a partition or LV that will be formatted. Reusing an existing / is not allowed.
Once upon a time, David Lehman said: > I just tried it and it worked fine. If you put your ks.cfg and > the /tmp/storage.log from your install somewhere I can take a look and > tell you what went wrong. Okay, I'm probably doing it wrong then. Here's my simplified ks.cfg. It is a simplified example of partitioning and setting up LVM in %pre (this example obviously doesn't do anything special, but I have actual kickstarts that do), but I switched to letting anaconda make the filesystems. I set a couple of simple ext4 options that stand out clearly after the fact. Looking at program.log, the "-T myopt" didn't get passed to mke2fs. If you still want the storage.log (i.e. I'm not doing something obviously wrong), I'll send it to you off-list (it is 83K). repo --name="Fedora 16 Beta" --baseurl=http://mirror.hiwaay.net/pub/fedora/linux/releases/test/16-Beta/Fedora/x86_64/os/ rootpw testpw sshpw --username=root testpw --plaintext network --device=eth0 --bootproto dhcp lang en_US.UTF-8 install text skipx halt selinux --permissive keyboard us timezone --utc America/Chicago auth --useshadow --passalgo=sha512 firewall --disabled # See BZ 720027 bootloader --location=mbr --append="rd.plymouth=0 console=tty0 console=ttyS0,115200" part /boot --onpart=vda1 --fstype=ext4 --fsprofile=myopt part pv.1 --onpart=vda2 --noformat volgroup fdev pv.1 --noformat logvol / --vgname=fdev --name=root --fstype=ext4 --useexisting --fsprofile=myopt logvol swap --vgname=fdev --name=swap --fstype=ext4 --useexisting %packages --nobase @ Core --nodefaults yum %end %pre --erroronfail set -e cat >> /etc/mke2fs.conf < Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: / must be on a partition or LV that will be formatted. Reusing an existing / is not allowed.
Once upon a time, David Lehman said: > I will be fixing kickstart when I get the chance to make this > requirement consistent. If your root filesystem is ext[234], see 'man > mke2fs.conf' and create yourself a profile in %pre which you can then > specify when defining your root filesystem (--fsprofile). Is fsprofile supposed to work on F16-Beta? I just tried it with a simple kickstart, and it appears to have been ignored. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: / must be on a partition or LV that will be formatted. Reusing an existing / is not allowed.
Once upon a time, clum...@redhat.com said: > > Hmm, that might be unfortunate. We use a fresh kickstart onto an > > existing / partition; will it still work to specify > > > > part / --onpart /dev/sda3 --noformat > > > > in the kickstart file? Or is this blocked as well? > > That's going to be blocked as well, since you're doing the same thing as > interactive but through kickstart. So does anaconda expose the full set of mkfs options, since you are now artificially restricting running mkfs in %pre? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: / must be on a partition or LV that will be formatted. Reusing an existing / is not allowed.
Once upon a time, Adam Williamson said: > Yes, that is what it means. We can't sensibly expect to be able to > reliably install to a root partition with data on it. Does this affect kickstart installs? I have some kickstarts that manually create filesystems in %pre to get specific mkfs options (that anaconda doesn't support). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Heads up: impending IPv6 Test Day
Once upon a time, Josh Stone said: > On 06/21/2011 05:54 AM, Andreas Schwab wrote: > > David Woodhouse writes: > > > >> And curl is just broken for numeric IPv6 addresses completely: > >> > >> [dwmw2@i7 activesyncd]$ curl http://[2001:8b0:10b:1:21d:7dff:fe04:dbe2]/ > >> curl: (3) [globbing] error: bad range specification after pos 9 > > > > $ curl http://\\\[2001:8b0:10b:1:21d:7dff:fe04:dbe2\\\]/ > > > "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd";> > > Or "curl -g" to disable globbing... It still can't handle link-local addresses: $ curl -g 'http://[fe80::230:48ff:fe41:51d5%br0]/' curl: (6) Could not resolve host: [fe80::230:48ff:fe41:51d5%br0]; Cannot allocate memory Lynx and Elinks make the request OK but includes the '%br0' in the Host: header, which lighttpd (at least) answers with "400 Bad Request". Firefox works (it strips the %br0 from the address before putting it in the Host: header). It would appear that the CLI/terminal web client support for IPv6 link-local addresses is lacking. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: freopen() broken in Fedora 15
Once upon a time, Chuck Forsberg WA7KGX N2469R said:
> The standard IO freopen function stopped working on or about
> the time I installed 64 bit Fedora 15 on the omen.com server.
>
> The attached program is derived from the 1977 Bill Joy version.
> It does not display any text when compiled and run under 64 bit
> F 15 clean install and updated as of today.
>
> The workaround is to rewrite the program to eliminate the use
> of freopen.
The problem is that file descriptors and file streams are being mixed
(and without proper includes).
> #ifndef lint
> static char *sccsid = "@(#)head.c 4.1 (Berkeley) 10/1/80";
> #endif
> #include
> #include
> #include
> #include
> #include
> close(0);
close() is defined in unistd.h, not included above. It operates on file
descriptors.
> if (freopen(argv[0], "r", stdin) == NULL) {
freopen() operates on file streams. The underlying library routine will
allocate a file descriptor, but that is transparent to the caller.
Mixing access on descriptors and streams is bad and I believe undefined
behavior, especially closing a descriptor out from under a stream. It
may have worked before, but that's not guaranteed by anything.
In any case, the close(0) is unnecessary, as the whole point of
freopen() is that it will close the existing stream (and internally-used
descriptor) as necessary (which may or may not be descriptor 0).
In short: the code you sent is broken - fix it.
--
Chris Adams
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Re: glibc-headers-2.13.90-10.x86_64 missing /usr/include/rpc/netdb.h
Once upon a time, Brian Millett said: > What?? Investigation shows that it used to be there but is now gone! The glibc-headers-2.13.90-10 changelog includes: - Update from master - Obsolete RPC implementation in libc I don't know if this is supposed to mean that something else obsoleted the RPC implementation, or if glibc devs decided RPC was obsolete, or what. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Well, I've tried GNOME 3 now...
Once upon a time, Adam Williamson said: > It's only people who are coming from an existing desktop - like GNOME 2 > - for which they already know all the shortcuts who are getting > frustrated, because they've changed, and now some of that knowledge you > built up doesn't apply any more, and you know you 'should' be able to do > certain things faster (because you could before) but you don't know how > to (because the shortcuts have changed). I think the problem is that people think GNOME 2 -> GNOME 3 is an upgrade of the interface, not a radical change. GNOME 3 is not GNOME 2 improved, it is something different (it might have been less confusing if it wasn't called GNOME 3, but since the shell isn't the whole project, that obviously wouldn't work). People don't like radical change when they're expecting an upgrade (look at MS Office going to the "ribbon" interface). MS Windows hasn't really changed the basic user interface since Windows 95. I haven't used a Mac in a while, but it is my understanding that their interface hasn't really changed that much over time either. Both have certainly evolved, adding new features and such, but they haven't had a radical departure in basic functionality from one release to the next. If the GNOME 3 shell had been a new development (especially under a different name), with the existing interface continuing as well, I don't think there would have been anything like as many complaints, and the new interface could "sink or swim" on its own merits. However, in the Open Source world, that requires people to step up to continue maintaining the old interface, and that's a lot of work (I'm a system admin, not a GUI developer; my personal web pages tend to be plain black text on a plain white background). While some interesting things have come out of the big changes in both GNOME and KDE over the years, when the big changes land, they tend to frustrate existing users. IMHO this is a big thing that has killed the perpetual "year of the Linux desktop" hopes. But what do I know; when I do have to use Windows, I still set it up in the "Windows Classic" theme so I get a plain interface that still looks largely like Win95. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Applets
Once upon a time, Jason D. Clinton said: > I appreciate how you clipped out the part where I said it's on the drawing > board but it didn't make it in time. What do you want us to do? Human > cloning is, sadly, illegal, and thus we only have the resources that we > have. I understand it is on the drawing board. I specifically tried to avoid any criticism of the developers or their work. I understand that the major changes are a big job and time is limited. However, IMHO, GNOME Shell isn't "feature complete" until it is ready to replace all the common uses of its predecessor, and applets are a major part of the desktop (again IMHO). If GNOME Shell isn't feature complete, then it shouldn't be made the default in Fedora 15. New features are supposed to be roughly feature complete by Alpha, and F15 Alpha is almost here. It also appears there is a lack of configuration tools (just from messages on this list about using gconf to change things), which again would seem to be a regression to me. Lack of a "reboot" button or menu option is also something that should be addressed. If a replacement for applets (and porting or reimplementing of the commonly-used applets) isn't going to be implemented before F15 Alpha, then IMHO the "fallback" mode should still be the default for F15, per the GNOME 3 feature page contingency plan. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Applets
Once upon a time, Jason D. Clinton said: > Patches welcome. Alternatively, you could pay someone to write it who > already isn't spending every spare, waking moment working on getting GNOME 3 > ready. Your email isn't particularly helpful though. Your email isn't particularly helpful either. How about patches to not include something that isn't done (as far as replacing useful functionality of the predecessor) as the primary desktop in Fedora? Would you welcome that? Not everybody can develop, and not all developers can really work on something like GNOME. That doesn't mean their input should be ignored or criticized. I hadn't really had a chance to look at GNOME 3.0 and the GNOME Shell until the graphics test days this week. Based on that short look, I'll either skip F15 and wait for further development, or switch to XFCE or some other environment. There seem to be a number of things missing from the new environment, and when the response to pointing out the missing functionality is essentially "send patches or shut up", my response tends towards "fine, I'll go somewhere else". -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] Fedora 15 Alpha TC2 Available Now!
Once upon a time, Orion Poplawski said: > On 02/15/2011 10:40 AM, Felix Miata wrote: > > On 2011/02/15 08:36 (GMT-0500) James Laska composed: > > > >> Good-bye install.img, hello initrd.img! > > > >> https://fedoraproject.org/wiki/Anaconda/Features/UnifiedInitrd > > > >> The installer no longer needs to locate where install.img is (network, > >> DVD, HD). The content previously included in the stage#2 install.img > >> file, is now included in the initrd.img. > > > > And goodbye to my to my customary installation method of loading > > installation > > kernel and initrd from my many little 200M /boot partitions that don't have > > room for being made larger. Good thing the two files needn't be located the > > same place, but it makes keeping track of where they are more complex. I > > guess I can use home's root or give home's root an install dir, and put even > > kernel there too. Or, maybe on my user/local partition. Or, on a FAT or NTFS > > partition?!?!? > > Hm, yeah, this is going to break koan as well, isn't it for systems with > small > /boot filesystems. Hmm, also what does this do to PXE booting. IIRC there is a (relatively low) limit on the size of the initrd loaded by pxelinux. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Grrr... modprobe.conf
Once upon a time, David Woodhouse said: > Why on earth would that be critical? The firewall is just a band-aid. If > it does anything useful, your system was broken (or infected) already. There are still a number of network daemons that don't have any practical IP ACL setup. TCP wrappers only kicks in after the socket is open, which is often not what you want. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: heads-up: upstart reversion coming soon
Once upon a time, Rahul Sundaram said: > * since s-c-services uses chkconfig, chkconfig needs to be hooked up to > systemctl IMHO this just needs to be the common-use cases for chkconfig (on, off, --list). The --add, --del, --level, and other options are not things that most sysadmins use (or should use, there are some that use --del instead of off and are suprised when the service comes back on an update). I think "service" should also be hooked up so that it continues to work for all services (this may be done already, but I've been out of town and busy with a couple of projects and unable to test lately). Again, the common uses (start, stop, restart, condrestart, reload, status) should be sufficient. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: heads-up: upstart reversion coming soon
Once upon a time, Micha³ Piotrowski said: > Please point me to a similar document written for Upstart. Please stop comparing everything to what was done for Upstart. That was done in a different set of circumstances, and for almost everything, Upstart was done in a backwards compatible manner. Upstart-specific setups were discouraged (in part because of documentation), so Upstart was never much more than a different program to manage a sysv-init setup. Requirements are an evolving thing as people learn from the past. Responding to every request with a comparison to what was done with Upstart is pointless and irritating. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Updates Lessons
Once upon a time, Kevin Fenzi said: > As part of FESCo implementing the Boards updates vision, I've been > looking at trying to document issues in updates and lessons we can > learn from them. > > I have a preliminary page up at: > > https://fedoraproject.org/wiki/Updates_Lessons > > If testing folks could look at adding any more serious issues they have > found there as we move forward we can try and improve our tooling and I'm not sure if this meets what you are looking for, but I just found that updating Horde in EPEL (and Fedora) from version 3.2.x to 3.3.x is broken. The UPGRADING file says that you have to run scripts/upgrades/2008-08-29_fix_mdb2_sequences.php but it requires PEAR MDB2_Schema package installed. That isn't even packaged for Fedora (and then of course EPEL). There isn't really a way to test for this, but it probably should be noted that software upgrade instructions should at least be read, and hopefully tested. There are a number of things that I can think of that this applies to, such as Horde (and other Horde pieces like IMP), RT, and Mediawiki (there are often manual upgrade steps required for these packages). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: QA recommendations for F-14
Once upon a time, Adam Jackson said: > Do people really not do VNC installs? On a server? Sometimes. On a desktop or notebook? Nope, never. I only have one desktop on my desk, so how would I connect to VNC? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
