> > 3) /usr/bin/liveinst fails with an error report of
> > missing /usr/bin/hal-lock
>
> Oooh, bad anaconda, depending on hal. No cookie for you. Fileabug!
What would be even more useful would be suggesting what we should be
doing to replace the usage of /usr/bin/hal-lock.
- Chris
--
test maili
> For grub to load the f15 TC1 initrd I clocked a time of 87 seconds.
> First time I encountered this I thought my computer hang, so I
> rebooted.
>
> Is this normal behaviour? If so I suggest looking into this to see
> if it is possible to minimize load time.
Are you talking about during install
> 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.
It's worked fine for me in all systems tested.
- Chris
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/
> >> A propos of this, does anaconda warn you may be doing something silly if
> >> you create a separate /usr partition in custom partitioning? Should it?
> >
> > If /usr as a separate partition has always worked and doesn't now, it
> > should probably throw up a warning, no?
>
> At least Disk Dru
> > So, we have the choice of waiting for all blockers to be resolved before
> > we do the next compose, which might take a while, or doing a TC2 with
> > the most critical fixes in. What approach do people think we should
> > take? Would a TC2 have any value or should we just clean up all the
> >
> > I checked in with the kind folks in #anaconda ... for fresh Fedora 16
> > installations, only grub2 will be used.
>
> Then there needs to be an option to install no bootloader. There's no excuse
> for making anything so poorly documented the default anything, much less an
> only anything.
I
> Are there any new grub2-related kickstart settings for the bootloader
> line in kickstart?
No, there have been no changes to the bootloader command for grub2.
Should there be?
- Chris
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/lis
> OT for this thread but for the record regarding kickstart
> documentation: the "part biosboot --fstype=biosboot --size=1"
> kickstart entry to create a bios_grub partition on a GPT disk isn't
> yet documented on the kickstart fp.o page.
There's still some discussion on whether we're going to req
> kickstart is a very broad area; you can write extremely complex
> kickstart files that do a lot of stuff. So broadly what we'd need to do
> is define a subset of kickstart functionality that we expect to work,
> and then possibly divide that up by release phase (so some stuff must
> work by Beta,
> Does this entry in the anaconda changelog really mean what I think it does:
>
> "/ must be on a partition or LV that will be formatted. Reusing an
> existing / is not allowed."
> --
> https://fedoraproject.org/wiki/Anaconda/Changes#Fedora_15_to_Fedora_16_.28as_of_anaconda-16.14.3-1.29
It means
> Ah only for fresh installs. Well that makes sense. I wasn't reading it
> for upgrades too, which would have caused a problem or two.
I've updated the wiki page to clarify this.
- Chris
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/li
> > > 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.
Looking at the patch, this appears to only affect interactive installs -
not kickstart.
> So does anaconda expose the f
> If the installer is sufficiently aggressive about warning clueless
> users to let it reformat / unless they really, really know what
> they're doing, then people who choose still not to reformat / and
> end up with a broken system have only themselves to blame, and their
> bugs can justifiably an
> As others have pointed out. Anaconda should remove whatever it needs
> to remove in order to install what it needs to install.
>
> This is not an impossible or even particularly hard problem to
> solve. It is merely a problem that no one has taken the time to
> solve, with the result that RPM wi
> And yet several people here on your volunteer test team, the people
> who are willing and able to use new releases early so that problems
> are fleshed out and can be addressed before release, have stated
> that they use this ability on a regular basis and would be pained to
> see it go.
>
> A r
> "The installed system must run normally if the user chooses to install
> without SELinux"
>
> There is no test case for this now.
>
> I have one note on this. There is used noselinux option, but it doesn't work
> now. I filled bug [2] there is another option with the same effect -
> selinux=
> "The installer must be able to handle the failure and report the issue. The
> installer must be also able to access debug mode."
Debug mode is intended to be used by developers to test and fix
anaconda. I don't think this belongs in test criteria.
- Chris
--
test mailing list
test@lists.fedo
> Just kidding ... sort of.
>
> I'm willing to bet that I wouldn't be getting a "NameError: global name
> 'BRFSError' is not defined" traceback if it were. (BTRFSError anyone?)
>
> Bugzilla at https://bugzilla.redhat.com/show_bug.cgi?id=794504.
You know, redoing it in Haskell really would solve
> Is this due to Anaconda's constant rewrite every release cycle that
> this happens?
anaconda does not do a constant rewrite every release cycle.
- Chris
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
> No packages need to be installed, everything is right there in the
> install environment. In the window with the traceback, there's a
> 'debug' option that will drop you into PDB (I haven't looked at the
> code, but it probably calls pdb.post_mortem() with the exception
> object). See http://docs
> Idea: the installer branches just from the beginning:
>
> -Easy install (only installs Gnome)
>
> -Advanced install (shows a big warning screen about installng multiple
> DEs, could be confusing, not recommended for newcomers, your pet could
> die, etc etc ).
>
> bingo, both sides pleased.
>
> I think it's much simpler: Just revert the DE radio buttons to the original
> checkboxes, so people can choose more than one, and if someone does that, pop
> up
> a warning.
We are trying to keep the number of spurious dialogs and confirmations
to a minimum, as we've gotten many complaints over
> Well, there's an obvious counterpoint there...*only* half of all people
> pick live images to use for installations, despite the fact they're a
> smaller and more convenient format. Did you consider the possible
> reasons why half of all people continue to choose to download the DVD
> (even thoug
> >(3) The time for making major design decisions was the first half of
> >2011, when we started talking about this.
>
> And now is too soon to put it on F19's table?
We're not going to redesign the new UI again around the concept of
advanced vs. normal users. There may be certain places where w
> Doesn't pickup the inst.repo from the command line
I just tested this and it worked. Got more data to share?
> using f17:
> doesn't ask/set root password
And it won't. We're going to set the first created user up as the
admin, so that's how that will happen.
> doesn't correctly conf
> In every instance, the fascist new Anaconda installs without
> reporting errors.
What are you even talking about?
- Chris
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
> Probably talking about the new Anaconda-UI?
But it's not in rawhide yet.
- Chris
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
> Not kidding, but neither does avoid equal refuse. Plus, all modern
> standards-compliant browsers read the CSS the same, so it isn't "my"
> browser that decides it should make text smaller than my
> personalized personal computer preference, or low contrast. It's
> just following so-called "sugge
> I wouldn't be hugely worried about waiving rescue mode for Alpha, but as
> others have said, it's more problematic if it's not going to come back
> for Beta or at least Final. Has Chris said anything about that?
My focus has been on getting a graphical UI ready to meet the alpha
criteria, plus s
> 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.
What we're talking about for storage here is:
(1) The filtering UI isn't going to be th
> 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, hard
> But it won't help you much, there is a problem
> within anaconda, which should be fixed, so this TC is not working.
And it certainly won't be fixed if you don't tell us what the problem
is.
- Chris
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.or
> 1) Installation end up with a screen -
> http://ompldr.org/vZjNhdw/QEMU_001.png
Okay, this is hiding the real error message. I've got a fix for it
committed and I'll be doing another build for f18-branch later today.
> 2) # anaconda
> Traceback (most recent call last):
> File "/sbin/anaconda
> I looked under "Installation Source"
> and there is a box "Don't install the latest available software updates.
> Install
> the default versions provided by the install source above." which is unchecked
> by default. I checked the box, but still get the same errors, so it's not
> working.
That
> I am experiencing a few issues with the disk partitioning using
> anaconda on F18 Alpha TC3. This is what I am seeing,
Custom partitioning is still under construction.
> * Once a partition is created, I am unable to change the partition
> size. I am having to delete the partition and recreate i
> > I have edited /etc/inittab to change :3: to :5: in the
> > one line in there, but that didn't change anything.
> > (Apparently it picked runlevel 3 as the default because
> > X wouldn't work in the installer and I had to use VNC).
> >
>
> That wont work inittab is slowly being deprecated add 1
> > c) The GUI install wouldn't work, but I fell back to text install.
> > >
> > > d) I was disappointed that it would not let me select the packages
> > >to install (I want KDE not Gnome)
> > >
> > Need the full install for that, LiveCD is GNOME.
> >
>
> I was using the 'full install'.
The k
As you know, we've got this automated storage test system for anaconda
now. I've got enough tests to cover all the partitioning parts of the
Fedora test matrix (except for resizing, which kickstart cannot
express). You can see the list of tests for yourself here:
http://git.fedorahosted.org/
> Given my rough ride when testing anaconda with multiple partitions with
> multiple different file systems types is there a test case that covers
> that?
>
> For examples creates 15 different partitions with separated mount points
> on different files system types?
I don't have such a test ye
> yeah, I agree this would be useful: we have a fairly ambitious final
> release criterion that basically states that any failure to install to a
> valid partition table (where the /boot and / are big enough, obviously)
> with supported partition types is a release blocker. So we should have
> some
> I don't really have any more suggestions at this time but I'd be
> extremely interested in a training session on how to write test cases
> and once I learn I'd be willing to help contribute a bit. I don't know
> that I'll be able to make it to FUDCon but if the session is done there
> I'm certain
> > Install / to a LV over raid10 after first reducing the LVs in the VG to
> > gain the space, /boot on an available partition, mount all other LV
> > distros and their /boot partitions, mount all other non-LV partitions.
>
> Chris: Another case that would need partition resize kickstart suppor
> I think you may have stated this already, which of the manual
> installation validation storage tests [1] are now automated using your
> unittests?
Under "Install Variations & General Tests", all the Partitioning area
except for QA:Testcase_Anaconda_autopart_(shrink)_install is now
automated. I
> One thing I look for with different storage devices is that they display
> differently in the anaconda UI. Likely not something we can test with
> your framework.
We can't do this today. However, a dogtail script is just another
method of automating an installation. Perhaps we could finally g
> Normal startup of the 386 DVD results in a blank screen.
> Starting with VESA driver gets to unhandled exceptions
> in the hard drive setup. First try was with OpenSUSE
> installed. Second try was after the partition table had
> been zeroed out with fdisk.
Please try reporting bugs with data
> There's a kernel panic in the first stage of anaconda in x86_64 boot.iso
> (probably in other x86_64 images as well):
>
> Bug 621775 - kernel panic- not syncing: VFS : unable to mount root fs on
> unknown-block(9,2)
anaconda hasn't even started running at this point, so it's a little
disingenuo
> As before, no text mode option is displayed.
Text mode is gone, gone, gone. No option for it will be displayed.
- Chris
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
> > Text mode is gone, gone, gone. No option for it will be displayed.
>
> Passing 'text' option to kernel seems to work fine. What did I not catch?
If you know the secret, you can get to it. But we don't go out of the
way to broadcast it.
- Chris
--
test mailing list
test@lists.fedoraproject
48 matches
Mail list logo
