Re: Adding Fedora15 to F16alpha grub2 menu {solved}

[Adam Williamson]

On Thu, 2011-08-25 at 21:27 -0400, Scott Robbins wrote:
> On Thu, Aug 25, 2011 at 07:05:55PM -0600, Peter G.  wrote:
> > Adam Williamson wrote:
> > 
> > > did you run 'update_grub'?
> > 
> > no I didn't. first I heard of it. that might 
> > explain it. but I learned something and I think I 
> > prefer the custom.cfg method, anyway :-)
> 
> Note the earlier exchange of emails.  update_grub is an Ubuntu command.

In my defence, I don't run Ubuntu or anything evil like that. I just
cargo-cult things I vaguely remember from Google searches. That's much
better, right?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

grub2 weirdness

[Rob Healey]

Greetings:

For once I am not writing regarding an issue that I am having with Fedora!
 Yeah for me...

I am just curious about one thing...

1) I loaded my box from the F16-Alpha x86_64 Desktop live cd...
2) disabled updates-testing repo
3) complete update using only Fedora
4) enabled updates-testing repo
5) complete update using both
6) install edora-release-rawhide
7) complete update using rawhide only

When I boot my computer, it shows the list of kernels that are installed and
could be used...  I take the default of kernel-3.1.0-rc3.git0.0.fc17.x86_64!
 Grub2 tells me that I am booting from kernel-3.0.1-3.fc16.x86_64 ...

I am just curious as of why the discrepancy?

-- 
Sincerely yours,
Rob G. Healey

"Always surround yourself with people that inspire you to
greatness!"
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Adding Fedora15 to F16alpha grub2 menu

[Adam Williamson]

On Thu, 2011-08-25 at 19:13 -0600, Peter G. wrote:
> Tom H wrote:
> 
> > The default Fedora install, up to now, has been to have a separate
> > "/boot" in order to use LVM for "/". That's one reason and there are
> > others (for example, some people don't mount "/boot" at boot; they
> > only mount it to update the kernel and the boot config and then
> > unmount it).
> 
> I never figured out a use for LVM, either ;-) 

The biggest use is very easy resizing of partitions, without data loss.

> I think I read it's going bye-bye, isn't 
> it? Something about btrfs making it irrelevant?

In the long term, yeah, btrfs will have support for everything that
makes LVM (and soft RAID, in fact) interesting. Probably be F18 before
we really stop using LVM and RAID separately from the filesystem by
default, though (that's just a WAG).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

[Test-Announce] 2011-08-26 @ 17:00 UTC - F16 Beta Blocker Bug Review #1

[Adam Williamson]

# F16 Beta Blocker Review meeting #1
# Date: 2011-08-26
# Time: 17:00 UTC [1] (13:00 EDT, 10:00 PDT, 10:00 MST)
# Location: #fedora-bugzappers on irc.freenode.net

The first Beta blocker review meeting starts at 17:00 UTC in
#fedora-bugzappers.  We'll do a first run through the proposed Beta
blockers and nice-to-haves.  An updated list of blocker bugs is
available at
https://fedoraproject.org/wiki/Current_Release_Blockers. We'll be
reviewing the bugs to determine ...

  1. Whether they meet the Beta release criteria [2] and should stay
 on the list
  2. Whether they are getting the attention they need

For guidance on Blocker and Nice-to-have (NTH) bugs, refer to
https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process and
https://fedoraproject.org/wiki/QA:SOP_nth_bug_process . For the blocker
review meeting protocol, see
https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting .

Thanks,

Adam

[1] https://fedoraproject.org/wiki/Infrastructure/UTCHowto
[2] https://fedoraproject.org/wiki/Fedora_16_Beta_Release_Criteria
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Adding Fedora15 to F16alpha grub2 menu {solved}

[Scott Robbins]

On Thu, Aug 25, 2011 at 07:05:55PM -0600, Peter G.  wrote:
> Adam Williamson wrote:
> 
> > did you run 'update_grub'?
> 
> no I didn't. first I heard of it. that might 
> explain it. but I learned something and I think I 
> prefer the custom.cfg method, anyway :-)

Note the earlier exchange of emails.  update_grub is an Ubuntu command.
In Fedora, changes are done by running grub2-mkconfig -o
/boot/grub/grub.cfg

However, like you, I prefer the custom.cfg since it avoids having to run
a command after a change.
> 

-- 
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6

Spike: A, my head. I think I'm sobering up. It's horrible. 
Ah... God... I wish I was dead. 
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Adding Fedora15 to F16alpha grub2 menu

[Peter G.]

Tom H wrote:

> The default Fedora install, up to now, has been to have a separate
> "/boot" in order to use LVM for "/". That's one reason and there are
> others (for example, some people don't mount "/boot" at boot; they
> only mount it to update the kernel and the boot config and then
> unmount it).

I never figured out a use for LVM, either ;-) I think I read it's going 
bye-bye, isn't 
it? Something about btrfs making it irrelevant?

And I don't know why you wouldn't want to mount /boot at boot. But I am just 
running a 
home desktop and a laptop computer :-) Nothing quirky, just what a man needs to 
be on 
the web.

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Adding Fedora15 to F16alpha grub2 menu {solved}

[Peter G.]

Peter G.  wrote:

> Adam Williamson wrote:
> 
>> did you run 'update_grub'?
> 
> no I didn't. first I heard of it. that might
> explain it. but I learned something and I think 
I
> prefer the custom.cfg method, anyway :-)
> 

I don't seem to have that program, or if I do, 
it's not in my/root's path.

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Adding Fedora15 to F16alpha grub2 menu {solved}

[Peter G.]

Adam Williamson wrote:

> did you run 'update_grub'?

no I didn't. first I heard of it. that might 
explain it. but I learned something and I think I 
prefer the custom.cfg method, anyway :-)

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Release criteria: kickstart

[Jóhann B. Guðmundsson]

On 08/26/2011 12:00 AM, Adam Williamson wrote:
> On Thu, 2011-08-25 at 23:54 +, "Jóhann B. Guðmundsson" wrote:
>
>> I'm still on the opinion that we should not be adding an ks testing to
>> the alpha criteria.
>>
>> Cant we just create a set of most commonly ks use cases in ks files for
>> releng and they can use pungi to test it with and post the result
>> somewhere online with pass/fail more of an autoqa task and say all those
>> must pass before beta?
>>
>> Where does the need for those ks testing suddenly come from and why do
>> we need to have those ks test involved in alpha?
> sorry, I skipped over Smooge's mention of Alpha. I was aiming for Beta,
> not Alpha. I think Smooge's minimal 'does a stock install ks file work'
> would be fine as a Beta test.

Given that this is something we should be able to automate and more of a 
task/project for autoqa I dont think we should be limiting ourself with 
minimal install and aim for more extensive tests than minimal I'm pretty 
sure Anaconda team and probably various other project members would also 
like to upload a .ks file somewhere and that file be put in a queue and 
the test ks process would process that queue on an x interval or simply 
test give pass or fail if fail, save logs post somewhere, delete file(s) 
and process next ks .

JBG
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Release criteria: kickstart

[Adam Williamson]

On Thu, 2011-08-25 at 23:54 +, "Jóhann B. Guðmundsson" wrote:

> I'm still on the opinion that we should not be adding an ks testing to 
> the alpha criteria.
> 
> Cant we just create a set of most commonly ks use cases in ks files for 
> releng and they can use pungi to test it with and post the result 
> somewhere online with pass/fail more of an autoqa task and say all those 
> must pass before beta?
> 
> Where does the need for those ks testing suddenly come from and why do 
> we need to have those ks test involved in alpha?

sorry, I skipped over Smooge's mention of Alpha. I was aiming for Beta,
not Alpha. I think Smooge's minimal 'does a stock install ks file work'
would be fine as a Beta test.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Adding Fedora15 to F16alpha grub2 menu {solved}

[Adam Williamson]

On Thu, 2011-08-25 at 18:54 -0400, Scott Robbins wrote:
> On Thu, Aug 25, 2011 at 03:16:25PM -0700, Adam Williamson wrote:
> > On Thu, 2011-08-25 at 12:21 -0600, Petrus de Calguarium wrote:
> > > Petrus de Calguarium wrote:
> > > 
> > 
> > did you run 'update_grub'? it seems to be needed after changing grub2
> > config. just like lilo! ahh, the good old days.
> 
> You mean the command detailed in the Ubuntu docs that doesn't seem to
> exist in F16?   Someone better get on the Fedora QA guys about
> that...oh...wait   :)
> 
> 
> Hopefully, soon Fedora will have its own docs, detailing the
> differences.  Unless a change is made, an F16 64 bit on a VM
> installed today does not have an update-grub, (by any name, such as
> update_grub, update-grub2, or whatever.)
> 
> 
> No, Petrus had the command correctly, grub2-mkconfig -o
> /boot/grub/grub.cfg  (And Petrus, thanks for the tip about making a
> custom.cfg, which does, as you pointed out, avoid the need to run a
> command.

ah. can you tell I didn't actually do much to grub2 yet? =) fortunately
it worked okay in all my tests.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Release criteria: kickstart

[Adam Williamson]

On Thu, 2011-08-25 at 16:49 -0600, Stephen John Smoogen wrote:

> Well I was trying to suggest something that wasn't handy-wavy. At some
> point a set of criteria are going to be needed for what is expected
> out anaconda at the minimum. From that criteria a set of test
> kickstarts can be built. If they dont' work then you have a blocker.
> Is that better?

Ah, I see - absolutely, when it comes to *test cases*, indeed the way to
test it is going to be to have kickstarts in the test cases. I just tend
to think first about defining the criteria, then writing the test cases.
Sorry I didn't quite grok you!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Release criteria: kickstart

[Jóhann B. Guðmundsson]

On 08/25/2011 10:49 PM, Stephen John Smoogen wrote:
> On Thu, Aug 25, 2011 at 16:20, Adam Williamson  wrote:
>> On Thu, 2011-08-25 at 14:35 -0600, Stephen John Smoogen wrote:
>>> On Thu, Aug 25, 2011 at 14:25, Chris Lumens  wrote:
> 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, the rest by Final, for e.g.)
>
> anaconda devs following this list, do you have any existing expectations
> as to what level of kickstart functionality ought to be in place for
> releases, and when you think would be appropriate?
>
> So far it seems everyone more or less agrees that it should be possible
> to do at least a basic unattended kickstart install by Beta.
 You're right, kickstart is incredibly broad.  I don't think we could
 ever hope to come up with criteria to cover all of it.  I guess the best
 we can do is define criteria in terms of something else we already have.
>>> I would go for the classical kickstart test for Alpha:
>>>
>>> Does it take a minimal kickstart and build a default system. The
>>> minimal being the exact stuff that would be created if a person just
>>> clicked through a release.
>> Oh, I like that. That's very good.
>>
>>> For Beta
>>>
>>> Take these X broken kickstarts, does it bail at the appropriate places.
>>> Take these Y working kickstarts, does it work.
>>> Where Y is a set of items that can be tested on say a KVM or a
>>> "default" desktop defined somewhere.
>> I'm not so keen on that; it's a bit specific. One of my fetishes with
>> the criteria is to keep them generic so they don't have to keep being
>> changed all the time; I wouldn't want a criterion to rely on some
>> specific kickstart file we keep lying around somewhere.
> Well I was trying to suggest something that wasn't handy-wavy. At some
> point a set of criteria are going to be needed for what is expected
> out anaconda at the minimum. From that criteria a set of test
> kickstarts can be built. If they dont' work then you have a blocker.
> Is that better?
>

I'm still on the opinion that we should not be adding an ks testing to 
the alpha criteria.

Cant we just create a set of most commonly ks use cases in ks files for 
releng and they can use pungi to test it with and post the result 
somewhere online with pass/fail more of an autoqa task and say all those 
must pass before beta?

Where does the need for those ks testing suddenly come from and why do 
we need to have those ks test involved in alpha?

JBG
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Adding Fedora15 to F16alpha grub2 menu {solved}

[Scott Robbins]

On Thu, Aug 25, 2011 at 03:16:25PM -0700, Adam Williamson wrote:
> On Thu, 2011-08-25 at 12:21 -0600, Petrus de Calguarium wrote:
> > Petrus de Calguarium wrote:
> > 
> 
> did you run 'update_grub'? it seems to be needed after changing grub2
> config. just like lilo! ahh, the good old days.

You mean the command detailed in the Ubuntu docs that doesn't seem to
exist in F16?   Someone better get on the Fedora QA guys about
that...oh...wait   :)


Hopefully, soon Fedora will have its own docs, detailing the
differences.  Unless a change is made, an F16 64 bit on a VM
installed today does not have an update-grub, (by any name, such as
update_grub, update-grub2, or whatever.)


No, Petrus had the command correctly, grub2-mkconfig -o
/boot/grub/grub.cfg  (And Petrus, thanks for the tip about making a
custom.cfg, which does, as you pointed out, avoid the need to run a
command.


-- 
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6

Kendra: I call it Mr. Pointy.
Buffy: You named your stake?
Kendra: Yes.
Buffy: Remind me to get you a stuffed animal.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Release criteria: kickstart

[Stephen John Smoogen]

On Thu, Aug 25, 2011 at 16:20, Adam Williamson  wrote:
> On Thu, 2011-08-25 at 14:35 -0600, Stephen John Smoogen wrote:
>> On Thu, Aug 25, 2011 at 14:25, Chris Lumens  wrote:
>> >> 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, the rest by Final, for e.g.)
>> >>
>> >> anaconda devs following this list, do you have any existing expectations
>> >> as to what level of kickstart functionality ought to be in place for
>> >> releases, and when you think would be appropriate?
>> >>
>> >> So far it seems everyone more or less agrees that it should be possible
>> >> to do at least a basic unattended kickstart install by Beta.
>> >
>> > You're right, kickstart is incredibly broad.  I don't think we could
>> > ever hope to come up with criteria to cover all of it.  I guess the best
>> > we can do is define criteria in terms of something else we already have.
>>
>> I would go for the classical kickstart test for Alpha:
>>
>> Does it take a minimal kickstart and build a default system. The
>> minimal being the exact stuff that would be created if a person just
>> clicked through a release.
>
> Oh, I like that. That's very good.
>
>> For Beta
>>
>> Take these X broken kickstarts, does it bail at the appropriate places.
>> Take these Y working kickstarts, does it work.
>> Where Y is a set of items that can be tested on say a KVM or a
>> "default" desktop defined somewhere.
>
> I'm not so keen on that; it's a bit specific. One of my fetishes with
> the criteria is to keep them generic so they don't have to keep being
> changed all the time; I wouldn't want a criterion to rely on some
> specific kickstart file we keep lying around somewhere.

Well I was trying to suggest something that wasn't handy-wavy. At some
point a set of criteria are going to be needed for what is expected
out anaconda at the minimum. From that criteria a set of test
kickstarts can be built. If they dont' work then you have a blocker.
Is that better?

-- 
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Let us be kind, one to another, for most of us are fighting a hard
battle." -- Ian MacLaren
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #237: tests to verify that torrents and mirrors contain signed checksum files

[Fedora QA]

#237: tests to verify that torrents and mirrors contain signed checksum files
---+
  Reporter:  robatino  |   Owner: 
  Type:  task  |  Status:  new
  Priority:  major |   Milestone: 
 Component:  Wiki  | Version: 
Resolution:|Keywords: 
---+
Comment (by adamwill):

 sounds reasonable - to go with the other 'image sanity' tests, right?

 would it also be good to file tickets with rel-eng to improve their
 process here?

 thanks!

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: F16 Alpha GRUB install failure

[Adam Williamson]

On Thu, 2011-08-25 at 15:59 -0500, David Lehman wrote:
> On Thu, 2011-08-25 at 22:56 +0200, Michael Schwendt wrote:
> > Between TC1 and release of F16 Alpha, something must have changed to the
> > worse with regard to installing GRUB to a partition's primary sector.
> > Partitioning hasn't changed. TC1 managed to install GRUB to /dev/sda3.
> > Anaconda now reports failure to install, and I've found this on virtual
> > console:
> > 
> >   /usr/sbin/grub2-setup: warn: Attempting to install GRUB to a
> >   partitionless disk or to a partitionj. This is a BAD idea..
> > 
> >   /usr/sbin/grub2-setup: warn: Embedding is not possible. GRUB can only be
> >   installed in this setup using blocklists. However, blocklists are
> >   UNRELIABLE and their use is discouraged..
> > 
> >   /usr/sbin/grub2-setup: error: will not proceed with blocklists.
> > 
> > Bug or feature?
> 
> Both? https://bugzilla.redhat.com/show_bug.cgi?id=728742

Also see:

https://fedoraproject.org/wiki/Common_F16_bugs#grub2-partition-fail
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Release criteria: kickstart

[Adam Williamson]

On Thu, 2011-08-25 at 14:35 -0600, Stephen John Smoogen wrote:
> On Thu, Aug 25, 2011 at 14:25, Chris Lumens  wrote:
> >> 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, the rest by Final, for e.g.)
> >>
> >> anaconda devs following this list, do you have any existing expectations
> >> as to what level of kickstart functionality ought to be in place for
> >> releases, and when you think would be appropriate?
> >>
> >> So far it seems everyone more or less agrees that it should be possible
> >> to do at least a basic unattended kickstart install by Beta.
> >
> > You're right, kickstart is incredibly broad.  I don't think we could
> > ever hope to come up with criteria to cover all of it.  I guess the best
> > we can do is define criteria in terms of something else we already have.
> 
> I would go for the classical kickstart test for Alpha:
> 
> Does it take a minimal kickstart and build a default system. The
> minimal being the exact stuff that would be created if a person just
> clicked through a release.

Oh, I like that. That's very good.

> For Beta
> 
> Take these X broken kickstarts, does it bail at the appropriate places.
> Take these Y working kickstarts, does it work.
> Where Y is a set of items that can be tested on say a KVM or a
> "default" desktop defined somewhere.

I'm not so keen on that; it's a bit specific. One of my fetishes with
the criteria is to keep them generic so they don't have to keep being
changed all the time; I wouldn't want a criterion to rely on some
specific kickstart file we keep lying around somewhere.

> For Final
> The above and some subset of obscure items that can be tested reliably
> somewhere that development and QA can replicate.

again, seems a bit arbitrary; what we really need is the kickstart
functionality we actually believe has to work, not an arbitrary set of
interesting bugs we happen to be able to test.

a minimal answer to this question would be fairly valid, I guess. at
least in the short term. sometimes working up criteria in response to
real-world cases - i.e. someone finds a kickstart problem, files a bug,
proposes it as blocker, we agree it should be one and work up a
criterion in response to it - has proved a decent way of doing things in
the past.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Adding Fedora15 to F16alpha grub2 menu {solved}

[Adam Williamson]

On Thu, 2011-08-25 at 12:21 -0600, Petrus de Calguarium wrote:
> Petrus de Calguarium wrote:
> 
> > I have installed F16α and with it grub2 to the MBR of /dev/sda. I am
> > experimenting happily with F16, but I am unable to add F15 to the
> > grub2 boot menu.
> > 
> > I have edited /etc/grub.d/40_custom and run grub2-mkconfig -o
> > /boot/grub2/grub.cfg, but my F15 entry never shows up in the menu,
> > even though it is in grub.cfg.
> 
> I figured out that no matter what you put into /etc/grub.d/40_custom, 
> it will never show up in the grub2 menu, even though it does show up 
> in /boot/grub2/grub.cfg. Yes, I have made sure to run restorecon on 

did you run 'update_grub'? it seems to be needed after changing grub2
config. just like lilo! ahh, the good old days.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs

[Adam Williamson]

On Thu, 2011-08-25 at 14:55 -0400, seth vidal wrote:
> On Thu, 2011-08-25 at 14:28 -0400, Dave Jones wrote:
> > On Thu, Aug 25, 2011 at 02:20:12PM -0400, seth vidal wrote:
> >  
> >  > > Dunno if that helps anybody...  never a dull moment...
> >  > 
> >  > When upgrading rawhide from X - use screen.
> > 
> > and also when upgrading from ssh.
> > 
> > things have definitely gotten a lot more fragile over the last
> > release or two.
> 
> you can disable the multilib protection with:
> 
> yum --setopt="protected_multilib=0" blah blah blah
> 
> which might help in situations where things are already deeply sideways.

worth noting for the record that, as always when using 'force' type
parameters to a package management system, when it breaks - as it
inevitably will - you get a full refund of what you paid for it, and you
get to keep both pieces. =) generally, when yum wants to do something
really funky, the solution is not 'figure out how to let yum do it' but
'figure out why yum wants to do something funky, and fix that'.

(this is obviously not aimed at seth, who knows it already, but at the
thread in general.)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs

[Adam Williamson]

On Thu, 2011-08-25 at 11:12 -0600, Jonathan Corbet wrote:
> On Wed, 24 Aug 2011 11:08:52 -0400
> Matthias Clasen  wrote:
> 
> > > Error: Protected multilib versions:
> > > gnome-panel-libs-3.1.5-2.fc16.x86_64 !=
> > > gnome-panel-libs-3.0.2-3.fc16.i686
> > >   
> > 
> > I have no idea what these errors mean or how to fix them.
> > Any advice would be appreciated. Actually, this one is kind of
> > understandable, but I have also seen 'protected multilib' stuff where
> > both sides of the != were the same arch, which left me wondering.
> 
> I've worked my way through this kind of mess a couple of times now, most
> recently yesterday.  Here's my experience:
> 
>  - Do a big rawhide update - in this case, at least two weeks worth.
> 
>  - Somewhere in the middle, while I'm not looking, the update kills the
>running session and/or X server - I come back to a login screen.  It
>used to be safe to run "yum update" from a terminal window, but,
>seemingly, not anymore.  Not really a step in the right direction. 

I don't think you could say it's ever been entirely *safe*; there's
always the potential that some update could do something to kill the
running session, and the more complex the definition of 'running
session', the more likely it is. Obviously a fat desktop on X is more
complex than a VT. I can only remember it happening to me once or twice,
but I'm not sure it's fair to say it's more likely now than in The
Golden Past.

I suspect the 'real fix' for that is to run your yum updates in a screen
session. I say 'suspect' because somehow I never quite get around to
learning how to use screen...but it seems like just the ticket, as it
would prevent the desktop going down from killing the yum update.

> What I have found in these cases is that there are *two* versions of the
> indicated library installed simultaneously (for the same architecture).
> In each case, simply removing the older version clears the problem.

What I'd actually recommend in that situation is doing 'rpm -e --justdb
--noscripts' on the 'old versions'; that will remove the entries from
RPM's database without possibly removing files that are actually part of
the newer one, or running scripts, which you don't want to happen.

In any case, that's not what's causing the 'protected multilib' thing
people are seeing in F16 now (or were yesterday), it's just an artefact
of yum trying to work around missing deps when you use --skip-broken.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Adding Fedora15 to F16alpha grub2 menu {solved}

[Tom H]

On Thu, Aug 25, 2011 at 2:21 PM, Petrus de Calguarium
 wrote:
> Petrus de Calguarium wrote:
>
>> I have installed F16α and with it grub2 to the MBR of /dev/sda. I am
>> experimenting happily with F16, but I am unable to add F15 to the
>> grub2 boot menu.
>>
>> I have edited /etc/grub.d/40_custom and run grub2-mkconfig -o
>> /boot/grub2/grub.cfg, but my F15 entry never shows up in the menu,
>> even though it is in grub.cfg.
>
> I figured out that no matter what you put into /etc/grub.d/40_custom,
> it will never show up in the grub2 menu, even though it does show up
> in /boot/grub2/grub.cfg. Yes, I have made sure to run restorecon on
> 40_custom after editing and that the permissions remain the same as
> the other files.

The standard 40_custom is:

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.

and it hasn't always worked for me. I prefer to use:

#!/bin/sh
cat 

[Fedora QA] #237: tests to verify that torrents and mirrors contain signed checksum files

[Fedora QA]

#237: tests to verify that torrents and mirrors contain signed checksum files
--+-
 Reporter:  robatino  |   Owner: 
 Type:  task  |  Status:  new
 Priority:  major |   Milestone: 
Component:  Wiki  | Version: 
 Keywords:|  
--+-
 In many of the last several releases (11, 13, 14, and now 16), at least
 some of the Alpha or Beta torrents contain only unsigned checksum files.
 This would be easy to prevent by examining the .torrent files, which
 contain file sizes (signing a checksum file adds about 1K to the size).
 Unfortunately, at present these are not made available for testing prior
 to being posted on http://torrent.fedoraproject.org , and when the problem
 is pointed out, no matter how quickly, one is told that the torrent can't
 be replaced since people are already downloading it. This makes it
 important to catch the problem in advance.

 Many (but not all) of the torrent files for the last several releases are
 still available at http://torrent.fedoraproject.org/torrents/ and
 http://torrent.fedoraproject.org/spins/ , and can be examined for example
 with gtorrentviewer. I have not checked any older than 11, and not all the
 ones after that are available, so the above list of affected releases is
 probably incomplete.

 A less serious issue is when the checksum files get signed more than once.
 For example, the checksum files for F15 Final install discs were signed
 twice, first for the torrents and again for the mirrors - see
 http://robatino.fedorapeople.org/checksums/15-Final/Fedora/ . The
 checksums are identical, and both signatures are valid, but still, it
 shouldn't happen.

 Looking at
 https://fedoraproject.org/wiki/Release_Engineering_Release_Tickets , it
 says that for Alpha and Beta, the torrents should be staged before the
 mirrors, but the reverse for Final. I've asked why on #fedora-releng but
 gotten no response yet. It says nothing about signing the checksum files,
 though the linked page
 https://fedoraproject.org/wiki/Stage_final_release_for_mirrors (under the
 section "Final") mentions it. This may explain why Alpha and Beta torrents
 are much less likely to have signed files. If possible, it would be nice
 for the order (torrents vs. mirrors) to be the same for all three, and in
 any case, the checksum files should be signed once and then used for both
 torrents and mirrors. None of this is currently documented.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Adding Fedora15 to F16alpha grub2 menu

[Tom H]

On Thu, Aug 25, 2011 at 2:14 PM, Petrus de Calguarium
 wrote:
> Tom H wrote:
>>>
>>> In the old grub, you had to explicitly state /boot.
>>>
>>> In the old grub.conf it even states:
>>>
>>> "all kernel and initrd paths are relative to /"
>>>
>>> That means everything is relative to root (/), not /boot!
>>
>> Are you referring to root=/ or the grub root?
>
> I don't have a clue what the "grub root" is or what you mean by
> "root=/", hence I cannot interpret the question.
>
>> If you have a separate "/boot" partition, the kernel and initrd are
>> relative to it.
>
> I never have a separate /boot (or /home) partition, as I have never
> managed to figure out a reason for it. It is just unnecessary
> complexity without benefit. I always have 3 versions of fedora
> installed (current, current-1 and current+1), so each has a root (/)
> partition that contains everything, the whole kit and 'kabootle'.

I mean by "grub root" the "root=(hdX,Y)" line in grub1's grub.conf and
the "set root=(hdX,Y)" and "search --no-floppy --fs-uuid --set=UUID"
lines in grub2's /grub.cfg.

The default Fedora install, up to now, has been to have a separate
"/boot" in order to use LVM for "/". That's one reason and there are
others (for example, some people don't mount "/boot" at boot; they
only mount it to update the kernel and the boot config and then
unmount it).
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Adding Fedora15 to F16alpha grub2 menu

[Tom H]

On Thu, Aug 25, 2011 at 2:52 PM, Tom Horsley  wrote:
>
> So if, for example, (hd0,0) is the grub name for
> a dedicated /boot partition, then the file names
> you use would be relative to /boot (just say /initramfs...)
>
> On the othr hand if (hd0,2) is the grub name for
> the "/" root partition, and boot is merely a subdirectory
> under root, then you say /boot/initramfs...

+1
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: F16 Alpha GRUB install failure

[David Lehman]

On Thu, 2011-08-25 at 22:56 +0200, Michael Schwendt wrote:
> Between TC1 and release of F16 Alpha, something must have changed to the
> worse with regard to installing GRUB to a partition's primary sector.
> Partitioning hasn't changed. TC1 managed to install GRUB to /dev/sda3.
> Anaconda now reports failure to install, and I've found this on virtual
> console:
> 
>   /usr/sbin/grub2-setup: warn: Attempting to install GRUB to a
>   partitionless disk or to a partitionj. This is a BAD idea..
> 
>   /usr/sbin/grub2-setup: warn: Embedding is not possible. GRUB can only be
>   installed in this setup using blocklists. However, blocklists are
>   UNRELIABLE and their use is discouraged..
> 
>   /usr/sbin/grub2-setup: error: will not proceed with blocklists.
> 
> Bug or feature?

Both? https://bugzilla.redhat.com/show_bug.cgi?id=728742


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: F16 Update Kernels fail to boot

[Tom H]

On Thu, Aug 25, 2011 at 11:14 AM, Orion Poplawski  wrote:
> On 08/25/2011 04:11 AM, Tom H wrote:
>> On Wed, Aug 24, 2011 at 6:52 PM, Orion Poplawski  wrote:
>>>
>>> Is there a way to workaround this in a kickstart file (other than running
>>> grub2-install --force (hd0,0) in %post) by using partitioning/boatloader 
>>> options?
>>
>> Just in case "(hd0,0)" isn't a typo, please note that grub2 numbers
>> partitions differently from grub1: sda1 is (hd0,1).
>
> Thanks for that.  Funny that it is still hd0 though then.

You're welcome. I presume that the grub developers just wanted to
align the partition number for the system and grub devices - and that
having a correspond to 0 or didn't really matter to them.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

F16 Alpha GRUB install failure

[Michael Schwendt]

Between TC1 and release of F16 Alpha, something must have changed to the
worse with regard to installing GRUB to a partition's primary sector.
Partitioning hasn't changed. TC1 managed to install GRUB to /dev/sda3.
Anaconda now reports failure to install, and I've found this on virtual
console:

  /usr/sbin/grub2-setup: warn: Attempting to install GRUB to a
  partitionless disk or to a partitionj. This is a BAD idea..

  /usr/sbin/grub2-setup: warn: Embedding is not possible. GRUB can only be
  installed in this setup using blocklists. However, blocklists are
  UNRELIABLE and their use is discouraged..

  /usr/sbin/grub2-setup: error: will not proceed with blocklists.

Bug or feature?
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: F16: grub2 efi version missing?

[Matthew Garrett]

On Wed, Aug 24, 2011 at 03:26:15PM +0200, Jurgen Kramer wrote:

> Any change grub2-efi will make it into F16 or is this F17 material?

F17. We need to port a pile of fixes to grub2 first.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Release criteria: kickstart

[Stephen John Smoogen]

On Thu, Aug 25, 2011 at 14:25, Chris Lumens  wrote:
>> 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, the rest by Final, for e.g.)
>>
>> anaconda devs following this list, do you have any existing expectations
>> as to what level of kickstart functionality ought to be in place for
>> releases, and when you think would be appropriate?
>>
>> So far it seems everyone more or less agrees that it should be possible
>> to do at least a basic unattended kickstart install by Beta.
>
> You're right, kickstart is incredibly broad.  I don't think we could
> ever hope to come up with criteria to cover all of it.  I guess the best
> we can do is define criteria in terms of something else we already have.

I would go for the classical kickstart test for Alpha:

Does it take a minimal kickstart and build a default system. The
minimal being the exact stuff that would be created if a person just
clicked through a release.

For Beta

Take these X broken kickstarts, does it bail at the appropriate places.
Take these Y working kickstarts, does it work.
Where Y is a set of items that can be tested on say a KVM or a
"default" desktop defined somewhere.

For Final
The above and some subset of obscure items that can be tested reliably
somewhere that development and QA can replicate.



-- 
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Let us be kind, one to another, for most of us are fighting a hard
battle." -- Ian MacLaren
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Release criteria: kickstart

[Chris Lumens]

> 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, the rest by Final, for e.g.)
> 
> anaconda devs following this list, do you have any existing expectations
> as to what level of kickstart functionality ought to be in place for
> releases, and when you think would be appropriate?
> 
> So far it seems everyone more or less agrees that it should be possible
> to do at least a basic unattended kickstart install by Beta.

You're right, kickstart is incredibly broad.  I don't think we could
ever hope to come up with criteria to cover all of it.  I guess the best
we can do is define criteria in terms of something else we already have.

So, how much of the test matrix right now is tested via kickstart files?
What other tasks do we have right now that are kickstart-based?  I know
spin composition uses some pieces of kickstart, and I know the storage
tests I wrote for autoqa use kickstart.  So right there, we have a
couple things we could base criteria on.

I guess there's also two ways you can break down kickstart - there's
syntax, and semantics.  Syntactically, the criteria should be that we
recognize all valid kickstart files.  Good luck defining what's a valid
kickstart file in terms besides "that which is accepted by pykickstart
as valid", though.  Semantics are the hard part and are what we're
really talking about here, though.

That's a lot of words to say, "I don't know".

- Chris
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Adding Fedora15 to F16alpha grub2 menu

[Petrus de Calguarium]

Scott Robbins wrote:

> Important note.  Although disk number still begins at 0, partitions 
now begin at 1.  So /dev/sda1 is now hd0,1.

Thanks for the reminder :-)

I was already aware of that, hence I set root to 0,7 (ie., sda7, or grub 
legacy hd0,6).

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Adding Fedora15 to F16alpha grub2 menu {solved}

[Petrus de Calguarium]

Scott Robbins wrote:

>> > On Thu, Aug 25, 2011 at 12:21:37PM -0600, Petrus de Calguarium 
wrote:
>> > I have edited /etc/grub.d/40_custom and run grub2-mkconfig -o
>> > /boot/grub2/grub.cfg, but my F15 entry never shows up in the 
menu, even though it is in grub.cfg.

> Interesting.  I just tested, on a virtual machine, without an actual
> O/S, (just made up one) and it showed up on my grub menu.  Is it
> possible you made a typo?

Possible? Of course... but I checked it numerous times and it all 
works when I type it by hand at the grub prompt and it also works when 
I put it into custom.cfg (copy and paste). I have also written and 
rewritten it many times, trying all of the various suggestions here in 
this thread, etc. and variations and it never appears in the grub 
menu, not even in a defective state. All my entries simply do not show 
up at all.

> (Or accidentally deleted that line they say not to delete?)

I definitely did NOT delete that line ;-)

But no matter. Editing custom.cfg is actually preferable, since you 
don't need to change those scripts under /etc/grub.d and you don't 
have to run grub2-mkconfig -o /boot/grub2/grub.cfg. And these entries 
verily do show up in the menu.

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Adding Fedora15 to F16alpha grub2 menu

[Tom Horsley]

On Thu, 25 Aug 2011 15:10:36 -0400
Scott Robbins wrote:

> Important note.  Although disk number still begins at 0, partitions now
> begin at 1.  So /dev/sda1 is now hd0,1.

My God! I won't be able to handle the partition numbers matching
in linux and grub (but that's OK I couldn't handle them not
matching either :-).
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Adding Fedora15 to F16alpha grub2 menu {solved}

[Scott Robbins]

On Thu, Aug 25, 2011 at 12:21:37PM -0600, Petrus de Calguarium wrote:
> Petrus de Calguarium wrote:
> 
> > 
> > I have edited /etc/grub.d/40_custom and run grub2-mkconfig -o
> > /boot/grub2/grub.cfg, but my F15 entry never shows up in the menu,
> > even though it is in grub.cfg.

Interesting.  I just tested, on a virtual machine, without an actual
O/S, (just made up one) and it showed up on my grub menu.  Is it
possible you made a typo?  (Or accidentally deleted that line they say
not to delete?)

-- 
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6

Willow: On the other hand, maybe Rodney just stepped out
for a smoke.
Xander: For twenty-one hours?
Willow: It's addictive, you know.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Adding Fedora15 to F16alpha grub2 menu

[Scott Robbins]

On Thu, Aug 25, 2011 at 02:52:18PM -0400, Tom Horsley wrote:
> On Thu, 25 Aug 2011 12:15:56 -0600
> Petrus de Calguarium wrote:
> 
> > How are you supposed to tell grub2 to look into the /boot directory 
> > for the kernel and initram?
> 
> OK, to inject my own ignorance into this thread:
> 
> As far as I know, the paths you tell grub should be
> relative to whatever the heck (hdX,Y) refers to
> in the disk spec.
> 
> So if, for example, (hd0,0) is the grub name for
> a dedicated /boot partition, then the file names
> you use would be relative to /boot (just say /initramfs...)

Important note.  Although disk number still begins at 0, partitions now
begin at 1.  So /dev/sda1 is now hd0,1.



-- 
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6

Faith: Isn't it crazy how slayin' just always makes you
hungry and horny?
Buffy: Well... sometimes I crave a nonfat yogurt afterwards.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs

[seth vidal]

On Thu, 2011-08-25 at 14:28 -0400, Dave Jones wrote:
> On Thu, Aug 25, 2011 at 02:20:12PM -0400, seth vidal wrote:
>  
>  > > Dunno if that helps anybody...  never a dull moment...
>  > 
>  > When upgrading rawhide from X - use screen.
> 
> and also when upgrading from ssh.
> 
> things have definitely gotten a lot more fragile over the last
> release or two.

you can disable the multilib protection with:

yum --setopt="protected_multilib=0" blah blah blah

which might help in situations where things are already deeply sideways.

-sv



-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Adding Fedora15 to F16alpha grub2 menu

[Tom Horsley]

On Thu, 25 Aug 2011 12:15:56 -0600
Petrus de Calguarium wrote:

> How are you supposed to tell grub2 to look into the /boot directory 
> for the kernel and initram?

OK, to inject my own ignorance into this thread:

As far as I know, the paths you tell grub should be
relative to whatever the heck (hdX,Y) refers to
in the disk spec.

So if, for example, (hd0,0) is the grub name for
a dedicated /boot partition, then the file names
you use would be relative to /boot (just say /initramfs...)

On the othr hand if (hd0,2) is the grub name for
the "/" root partition, and boot is merely a subdirectory
under root, then you say /boot/initramfs...
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs

[Bill Nottingham]

Jonathan Corbet (corbet...@lwn.net) said: 
>  - Somewhere in the middle, while I'm not looking, the update kills the
>running session and/or X server - I come back to a login screen.  It
>used to be safe to run "yum update" from a terminal window, but,
>seemingly, not anymore.  Not really a step in the right direction. 

There was a bug that caused dbus to get restarted when it should not
have been. I believe this is in the process of having a fix pushed.

Bill
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs

[Dave Jones]

On Thu, Aug 25, 2011 at 02:20:12PM -0400, seth vidal wrote:
 
 > > Dunno if that helps anybody...  never a dull moment...
 > 
 > When upgrading rawhide from X - use screen.

and also when upgrading from ssh.

things have definitely gotten a lot more fragile over the last
release or two.

Dave

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Adding Fedora15 to F16alpha grub2 menu {solved}

[Petrus de Calguarium]

Petrus de Calguarium wrote:

> I have installed F16α and with it grub2 to the MBR of /dev/sda. I am
> experimenting happily with F16, but I am unable to add F15 to the
> grub2 boot menu.
> 
> I have edited /etc/grub.d/40_custom and run grub2-mkconfig -o
> /boot/grub2/grub.cfg, but my F15 entry never shows up in the menu,
> even though it is in grub.cfg.

I figured out that no matter what you put into /etc/grub.d/40_custom, 
it will never show up in the grub2 menu, even though it does show up 
in /boot/grub2/grub.cfg. Yes, I have made sure to run restorecon on 
40_custom after editing and that the permissions remain the same as 
the other files.

The solution:

create a file called /boot/grub2/custom.cfg and put your custom menu 
items in that. This file is automatically read by grub2, thanks to 
/etc/grub.d/41_custom, which causes custom.cfg to be read.

This works!

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Adding Fedora15 to F16alpha grub2 menu

[Petrus de Calguarium]

Joachim Backes wrote:

> On 08/25/2011 04:36 PM, Petrus de Calguarium wrote:
>> Joachim Backes wrote:
>>
>>
>>> my grub.cfg (using chainloader) entry for F15 (after installing 
grub2
>> in
>>> F15 and installing then in F15 the grub2 bootloader to /dev/sda7):
>>>
>>> menuentry 'Fedora 15' --class fedora --class gnu-linux --class gnu
>>> --class os {
>>> set root=(hd0,7)
>>> chainloader +1
>>> }
>>>
>>
>> I never knew chainloader could be used for linux. I have seen it 
for
>> windows and for ploppy disks, but I will give it a try.
>>
> 
> Check it! I use this since some Fedora generations to run multiple
> fedoras on one hd. No problems!
> 
Sorry to say, but I got nowhere with that. Nothing happened. It is 
definitely interesting in it's perfect simplicity and would be 
preferred, if it worked, for that reason.

How are you supposed to tell grub2 to look into the /boot directory 
for the kernel and initram?

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs

[seth vidal]

On Thu, 2011-08-25 at 11:12 -0600, Jonathan Corbet wrote:
> On Wed, 24 Aug 2011 11:08:52 -0400
> Matthias Clasen  wrote:
> 
> > > Error: Protected multilib versions:
> > > gnome-panel-libs-3.1.5-2.fc16.x86_64 !=
> > > gnome-panel-libs-3.0.2-3.fc16.i686
> > >   
> > 
> > I have no idea what these errors mean or how to fix them.
> > Any advice would be appreciated. Actually, this one is kind of
> > understandable, but I have also seen 'protected multilib' stuff where
> > both sides of the != were the same arch, which left me wondering.
> 
> I've worked my way through this kind of mess a couple of times now, most
> recently yesterday.  Here's my experience:
> 
>  - Do a big rawhide update - in this case, at least two weeks worth.
> 
>  - Somewhere in the middle, while I'm not looking, the update kills the
>running session and/or X server - I come back to a login screen.  It
>used to be safe to run "yum update" from a terminal window, but,
>seemingly, not anymore.  Not really a step in the right direction. 
> 
>  - If I try to rerun the update, it will tell me to try
>yum-complete-transaction.  Each time, actually trying that leads to an
>infinite loop printing dependency information.
> 
>  - If I just run "yum update", I get the "protected multilib versions"
>message.
> 
> What I have found in these cases is that there are *two* versions of the
> indicated library installed simultaneously (for the same architecture).
> In each case, simply removing the older version clears the problem.  Once
> I've gotten past the gripes, the update actually works.
> 
> Dunno if that helps anybody...  never a dull moment...

When upgrading rawhide from X - use screen.

-sv


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Adding Fedora15 to F16alpha grub2 menu

[Petrus de Calguarium]

Tom H wrote:

>> In the old grub, you had to explicitly state /boot.
>>
>> In the old grub.conf it even states:
>>
>> "all kernel and initrd paths are relative to /"
>>
>> That means everything is relative to root (/), not /boot!
> 
> Are you referring to root=/ or the grub root?
> 

I don't have a clue what the "grub root" is or what you mean by 
"root=/", hence I cannot interpret the question.

> If you have a separate "/boot" partition, the kernel and initrd are
> relative to it.

I never have a separate /boot (or /home) partition, as I have never 
managed to figure out a reason for it. It is just unnecessary 
complexity without benefit. I always have 3 versions of fedora 
installed (current, current-1 and current+1), so each has a root (/) 
partition that contains everything, the whole kit and 'kabootle'.

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Adding Fedora15 to F16alpha grub2 menu

[Tom H]

On Thu, Aug 25, 2011 at 12:40 PM, Petrus de Calguarium
 wrote:
> Clyde E. Kunkel wrote:
>
>> As far as I know, everything is relative to /boot.  No change from old
>> grub.
>
> In the old grub, you had to explicitly state /boot.
>
> In the old grub.conf it even states:
>
> "all kernel and initrd paths are relative to /"
>
> That means everything is relative to root (/), not /boot!

Are you referring to root=/ or the grub root?

If you have a separate "/boot" partition, the kernel and initrd are
relative to it.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs

[Jonathan Corbet]

On Wed, 24 Aug 2011 11:08:52 -0400
Matthias Clasen  wrote:

> > Error: Protected multilib versions:
> > gnome-panel-libs-3.1.5-2.fc16.x86_64 !=
> > gnome-panel-libs-3.0.2-3.fc16.i686
> >   
> 
> I have no idea what these errors mean or how to fix them.
> Any advice would be appreciated. Actually, this one is kind of
> understandable, but I have also seen 'protected multilib' stuff where
> both sides of the != were the same arch, which left me wondering.

I've worked my way through this kind of mess a couple of times now, most
recently yesterday.  Here's my experience:

 - Do a big rawhide update - in this case, at least two weeks worth.

 - Somewhere in the middle, while I'm not looking, the update kills the
   running session and/or X server - I come back to a login screen.  It
   used to be safe to run "yum update" from a terminal window, but,
   seemingly, not anymore.  Not really a step in the right direction. 

 - If I try to rerun the update, it will tell me to try
   yum-complete-transaction.  Each time, actually trying that leads to an
   infinite loop printing dependency information.

 - If I just run "yum update", I get the "protected multilib versions"
   message.

What I have found in these cases is that there are *two* versions of the
indicated library installed simultaneously (for the same architecture).
In each case, simply removing the older version clears the problem.  Once
I've gotten past the gripes, the update actually works.

Dunno if that helps anybody...  never a dull moment...

jon
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Adding Fedora15 to F16alpha grub2 menu

[Clyde E. Kunkel]

On 08/25/2011 12:40 PM, Petrus de Calguarium wrote:
> Clyde E. Kunkel wrote:
>
>> As far as I know, everything is relative to /boot.  No change from old
>> grub.
>
> In the old grub, you had to explicitly state /boot.
>
> In the old grub.conf it even states:
>
> "all kernel and initrd paths are relative to /"
>
> That means everything is relative to root (/), not /boot!
>

Separate boot partition, do not use /boot

If not, then I dunno

-- 
Regards,
OldFart

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: F16: CPU peaks all 20 seconds

[Joachim Backes]

On 08/25/2011 05:52 PM, Stephen John Smoogen wrote:

On Thu, Aug 25, 2011 at 09:43, Joachim Backes
  wrote:

Hi,

in an almost empty system (only running gnome-shell), I see CPU peaks all 20
seconds (kernel-3.1.0-0.rc3.git0.0.fc16.x86_64). It seems that gnome-shell
is busy all 20 secs (similar effect like yesterday with
kernel-3.1.0-0.rc2.git7.2.fc16.x86_64 and Xorg).


What does top show at those times and what is the hardware etc.
Without that info, it could be anything from a cron job to you have
really bad drives and the 20 second sync takes a lot of CPU power to
do it correctly.


7908 backes20   0 1236m  66m  24m S  1.0  3.4   0:54.45 gnome-shell 

12842 backes20   0 15232 1316  980 R  1.0  0.1   0:00.12 top 

 7601 root  20   0  149m  10m 5232 S  0.7  0.5   1:14.37 Xorg 

   40 root  20   0 000 S  0.3  0.0   0:00.69 
kworker/u:2
1 root  20   0 37500 4808 1988 S  0.0  0.2   0:04.95 systemd 

2 root  20   0 000 S  0.0  0.0   0:00.00 kthreadd 

3 root  20   0 000 S  0.0  0.0   0:00.78 
ksoftirqd/0
6 root  RT   0 000 S  0.0  0.0   0:00.00 
migration/0
7 root  RT   0 000 S  0.0  0.0   0:00.03 watchdog/0 

8 root  RT   0 000 S  0.0  0.0   0:00.00 
migration/1
   10 root  20   0 000 S  0.0  0.0   0:00.51 
ksoftirqd/1
   12 root  RT   0 000 S  0.0  0.0   0:00.02 watchdog/1 

   13 root   0 -20 000 S  0.0  0.0   0:00.00 cpuset 

   14 root   0 -20 000 S  0.0  0.0   0:00.00 khelper 

   15 root  20   0 000 S  0.0  0.0   0:00.01 kdevtmpfs 

   16 root   0 -20 000 S  0.0  0.0   0:00.00 netns 


   17 root  20   0 000 S  0.0  0.0   0:00.02 sync_supers
   10 root  20   0 000 S  0.0  0.0   0:00.51



sudo crontab -l
no crontab for root
backes@eule [~]: crontab -l
no crontab for backes

-

I have 2 sata disks:

smartctl -x /dev/sda:

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME  FLAG VALUE WORST THRESH TYPE 
UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate 0x002f   200   200   051Pre-fail 
Always   -   0
  3 Spin_Up_Time0x0027   140   139   021Pre-fail 
Always   -   3958
  4 Start_Stop_Count0x0032   100   100   000Old_age 
Always   -   723
  5 Reallocated_Sector_Ct   0x0033   200   200   140Pre-fail 
Always   -   0
  7 Seek_Error_Rate 0x002e   200   200   000Old_age 
Always   -   0
  9 Power_On_Hours  0x0032   091   091   000Old_age 
Always   -   6616
 10 Spin_Retry_Count0x0032   100   100   000Old_age 
Always   -   0
 11 Calibration_Retry_Count 0x0032   100   100   000Old_age 
Always   -   0
 12 Power_Cycle_Count   0x0032   100   100   000Old_age 
Always   -   669
192 Power-Off_Retract_Count 0x0032   200   200   000Old_age   Always 
  -   113
193 Load_Cycle_Count0x0032   200   200   000Old_age   Always 
  -   609
194 Temperature_Celsius 0x0022   101   096   000Old_age   Always 
  -   42
196 Reallocated_Event_Count 0x0032   200   200   000Old_age   Always 
  -   0
197 Current_Pending_Sector  0x0032   200   200   000Old_age   Always 
  -   0
198 Offline_Uncorrectable   0x0030   200   200   000Old_age 
Offline  -   0
199 UDMA_CRC_Error_Count0x0032   200   200   000Old_age   Always 
  -   0
200 Multi_Zone_Error_Rate   0x0008   200   200   000Old_age 
Offline  -   0


SMART Error Log Version: 1
No Errors Logged

-

smartctl -x /dev/sdb

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME  FLAG VALUE WORST THRESH TYPE 
UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate 0x002f   200   200   051Pre-fail 
Always   -   0
  3 Spin_Up_Time0x0027   168   162   021Pre-fail 
Always   -   6600
  4 Start_Stop_Count0x0032   099   099   000Old_age 
Always   -   1191
  5 Reallocated_Sector_Ct   0x0033   200   200   140Pre-fail 
Always   -   0
  7 Seek_Error_Rate 0x002e   100   253   000Old_age 
Always   -   0
  9 Power_On_Hours  0x0032   086   086   000Old_age 
Always   -   10557
 10 Spin_Retry_Count0x0032   100   100   000Old_age 
Always   -   0
 11 Calibration_Retry_Count 0x0032   100   100   000Old_age 
Always   -   0
 12 Power_Cycle_Count   0x0032   099   099   000Old_age 
Alway

Re: Adding Fedora15 to F16alpha grub2 menu

[Petrus de Calguarium]

Clyde E. Kunkel wrote:

> As far as I know, everything is relative to /boot.  No change from old
> grub.

In the old grub, you had to explicitly state /boot.

In the old grub.conf it even states:

"all kernel and initrd paths are relative to /"

That means everything is relative to root (/), not /boot!

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

F-16 Branched report: 20110825 changes

[Branched Report]

Compose started at Thu Aug 25 13:15:36 UTC 2011

Broken deps for x86_64
--
389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires 
libnetsnmpagent.so.25()(64bit)
389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires 
libnetsnmpmibs.so.25()(64bit)
389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires libnetsnmp.so.25()(64bit)
OpenImageIO-0.10.1-2.fc15.i686 requires 
libboost_program_options-mt.so.1.46.0
OpenImageIO-0.10.1-2.fc15.i686 requires libboost_thread-mt.so.1.46.0
OpenImageIO-0.10.1-2.fc15.i686 requires libboost_python-mt.so.1.46.0
OpenImageIO-0.10.1-2.fc15.i686 requires libboost_system-mt.so.1.46.0
OpenImageIO-0.10.1-2.fc15.i686 requires libGLEW.so.1.5
OpenImageIO-0.10.1-2.fc15.i686 requires libboost_regex-mt.so.1.46.0
OpenImageIO-0.10.1-2.fc15.i686 requires libboost_filesystem-mt.so.1.46.0
OpenImageIO-0.10.1-2.fc15.x86_64 requires 
libboost_regex-mt.so.1.46.0()(64bit)
OpenImageIO-0.10.1-2.fc15.x86_64 requires 
libboost_filesystem-mt.so.1.46.0()(64bit)
OpenImageIO-0.10.1-2.fc15.x86_64 requires 
libboost_program_options-mt.so.1.46.0()(64bit)
OpenImageIO-0.10.1-2.fc15.x86_64 requires 
libboost_system-mt.so.1.46.0()(64bit)
OpenImageIO-0.10.1-2.fc15.x86_64 requires libGLEW.so.1.5()(64bit)
OpenImageIO-0.10.1-2.fc15.x86_64 requires 
libboost_python-mt.so.1.46.0()(64bit)
OpenImageIO-0.10.1-2.fc15.x86_64 requires 
libboost_thread-mt.so.1.46.0()(64bit)
acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell)
almanah-0.7.3-12.fc16.x86_64 requires libcamel-1.2.so.26()(64bit)
almanah-0.7.3-12.fc16.x86_64 requires libedataserverui-3.0.so.0()(64bit)
assogiate-0.2.1-5.fc15.x86_64 requires libgnomevfsmm-2.6.so.1()(64bit)
bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit)
cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit)
coda-backup-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit)
coda-backup-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit)
coda-backup-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires rvm-tools
coda-server-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit)
comoonics-cdsl-py-0.2-18.noarch requires comoonics-base-py
comoonics-cluster-py-0.1-24.noarch requires comoonics-base-py
contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1
contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit)
deskbar-applet-2.32.0-4.fc15.x86_64 requires libebook-1.2.so.10()(64bit)
deskbar-applet-2.32.0-4.fc15.x86_64 requires gnome-python2-applet
deskbar-applet-2.32.0-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit)
dh-make-0.55-3.fc15.noarch requires debhelper
emacs-spice-mode-1.2.25-5.fc15.noarch requires gwave
emerillon-0.1.2-17.fc16.x86_64 requires libethos-ui-1.0.so.0()(64bit)
emerillon-0.1.2-17.fc16.x86_64 requires libethos-1.0.so.0()(64bit)
evolution-mapi-3.1.3-1.fc16.i686 requires libcamel-1.2.so.27
evolution-mapi-3.1.3-1.fc16.i686 requires libcamel-provider-1.2.so.27
evolution-mapi-3.1.3-1.fc16.x86_64 requires 
libcamel-provider-1.2.so.27()(64bit)
evolution-mapi-3.1.3-1.fc16.x86_64 requires libcamel-1.2.so.27()(64bit)
exaile-0.3.2.1-1.fc16.noarch requires hal
fawkes-guis-0.4.2-4.fc16.i686 requires libgvc.so.5
fawkes-guis-0.4.2-4.fc16.i686 requires libcdt.so.4
fawkes-guis-0.4.2-4.fc16.i686 requires libgraph.so.4
fawkes-guis-0.4.2-4.fc16.x86_64 requires libgvc.so.5()(64bit)
fawkes-guis-0.4.2-4.fc16.x86_64 requires libcdt.so.4()(64bit)
fawkes-guis-0.4.2-4.fc16.x86_64 requires libgraph.so.4()(64bit)
fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires 
libboost_signals-mt.so.1.46.1()(64bit)
fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires 
libboost_thread-mt.so.1.46.1()(64bit)
fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires 
libgeos-3.2.1.so()(64bit)
file-browser-applet-0.6.6-1.fc15.x86_64 requires 
libpanel-applet-2.so.0(

Re: F16: CPU peaks all 20 seconds

[Stephen John Smoogen]

On Thu, Aug 25, 2011 at 09:43, Joachim Backes
 wrote:
> Hi,
>
> in an almost empty system (only running gnome-shell), I see CPU peaks all 20
> seconds (kernel-3.1.0-0.rc3.git0.0.fc16.x86_64). It seems that gnome-shell
> is busy all 20 secs (similar effect like yesterday with
> kernel-3.1.0-0.rc2.git7.2.fc16.x86_64 and Xorg).

What does top show at those times and what is the hardware etc.
Without that info, it could be anything from a cron job to you have
really bad drives and the 20 second sync takes a lot of CPU power to
do it correctly.

> Somebody has an explanation for that?
>
> See http://www-user.rhrk.uni-kl.de/~backes/UL/cpu.png.
>
> --
> Joachim Backes 
>
> http://www.rhrk.uni-kl.de/~backes
>
> --
> test mailing list
> test@lists.fedoraproject.org
> To unsubscribe:
> https://admin.fedoraproject.org/mailman/listinfo/test
>



-- 
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Let us be kind, one to another, for most of us are fighting a hard
battle." -- Ian MacLaren
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

F16: CPU peaks all 20 seconds

[Joachim Backes]

Hi,

in an almost empty system (only running gnome-shell), I see CPU peaks 
all 20 seconds (kernel-3.1.0-0.rc3.git0.0.fc16.x86_64). It seems that 
gnome-shell is busy all 20 secs (similar effect like yesterday with 
kernel-3.1.0-0.rc2.git7.2.fc16.x86_64 and Xorg).


Somebody has an explanation for that?

See http://www-user.rhrk.uni-kl.de/~backes/UL/cpu.png.

--
Joachim Backes 

http://www.rhrk.uni-kl.de/~backes
<>

smime.p7s
Description: S/MIME Cryptographic Signature
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: F16 Update Kernels fail to boot

[Orion Poplawski]

On 08/25/2011 04:11 AM, Tom H wrote:
> On Wed, Aug 24, 2011 at 6:52 PM, Orion Poplawski  wrote:
>> Is there a way to workaround this in a kickstart file (other than running
>> grub2-install --force (hd0,0) in %post) by using partitioning/boatloader 
>> options?
>
> Just in case "(hd0,0)" isn't a typo, please note that grub2 numbers
> partitions differently from grub1: sda1 is (hd0,1).

Thanks for that.  Funny that it is still hd0 though then.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Adding Fedora15 to F16alpha grub2 menu

[Clyde E. Kunkel]

On 08/25/2011 10:35 AM, Petrus de Calguarium wrote:
> Clyde E. Kunkel wrote:
>
>> On 08/25/2011 12:40 AM, Petrus de Calguarium wrote:
>>> 
>>> set root=(hd0,7)
>>> linux /boot/vmlinuz-2.6.40.3-0.fc15.x86_64 root=/dev/sda7 ro quiet
> etc
>>> etc etc etc etc rd.=0 etc etc etc
>>> initrd /boot/initramfs-2.6.40.3-0.fc15.x86_64.img
>>^
>>  ^
>> delete-|  (both of them)
>>
>
> I will try it. It seems odd, however.
>
> Will grub search through the root partition until if finds the kernel
> and initramfs, or does it simply assume (correctly) that they are
> located in the /boot directory?
>

As far as I know, everything is relative to /boot.  No change from old grub.

-- 
Regards,
OldFart

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: F16 not showing up in BFO images

[ajs]

Works great.

On Wed, 2011-08-24 at 14:15 -0600, Kevin Fenzi wrote:
> On Wed, 24 Aug 2011 13:41:33 -0600
> ajs  wrote:
> 
> > I followed the link from http://fedoraproject.org/get-prerelease to
> > the BFO images at http://boot.fedoraproject.org/download.
> > 
> > These images do not point to F16 alpha.  Is this a bug and if so what
> > is the Bugzilla component?
> > 
> > Manually setting the URLs worked fine and I am installing F16-Alpha
> > now.
> 
> Sorry about that. I didn't get it updated. ;( 
> 
> I have added a pre-release menu and f16 alpha on it. 
> 
> Please test and let me know if there's anything wrong with it. 
> 
> kevin
> 
> -- 
> test mailing list
> test@lists.fedoraproject.org
> To unsubscribe: 
> https://admin.fedoraproject.org/mailman/listinfo/test


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Adding Fedora15 to F16alpha grub2 menu

[Joachim Backes]

On 08/25/2011 04:36 PM, Petrus de Calguarium wrote:

Joachim Backes wrote:



my grub.cfg (using chainloader) entry for F15 (after installing grub2

in

F15 and installing then in F15 the grub2 bootloader to /dev/sda7):

menuentry 'Fedora 15' --class fedora --class gnu-linux --class gnu
--class os {
set root=(hd0,7)
chainloader +1
}



I never knew chainloader could be used for linux. I have seen it for
windows and for ploppy disks, but I will give it a try.



Check it! I use this since some Fedora generations to run multiple 
fedoras on one hd. No problems!


--
Joachim Backes 

http://www.rhrk.uni-kl.de/~backes



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

F16: login time increases extremely to almost 1 min after most recent F16 updates

[Joachim Backes]

Hi,

I installed all possible updates (selecting explicetely the packages 
because of current yum problems). Then, after rebooting, if having 
entered the password in the gdm screen, it takes at least 1 minute after 
the gnome-shell desktop is complete.


Anybody sees this too?

Kind regards

Joachim Backes 

http://www.rhrk.uni-kl.de/~backes



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Adding Fedora15 to F16alpha grub2 menu

[Petrus de Calguarium]

Joachim Backes wrote:

 
> my grub.cfg (using chainloader) entry for F15 (after installing grub2 
in
> F15 and installing then in F15 the grub2 bootloader to /dev/sda7):
> 
> menuentry 'Fedora 15' --class fedora --class gnu-linux --class gnu
> --class os {
> set root=(hd0,7)
> chainloader +1
> }
> 

I never knew chainloader could be used for linux. I have seen it for 
windows and for ploppy disks, but I will give it a try.

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Adding Fedora15 to F16alpha grub2 menu

[Petrus de Calguarium]

Clyde E. Kunkel wrote:

> On 08/25/2011 12:40 AM, Petrus de Calguarium wrote:
>> 
>> set root=(hd0,7)
>> linux /boot/vmlinuz-2.6.40.3-0.fc15.x86_64 root=/dev/sda7 ro quiet 
etc
>> etc etc etc etc rd.=0 etc etc etc
>> initrd /boot/initramfs-2.6.40.3-0.fc15.x86_64.img
>   ^
> ^
> delete-|  (both of them)
> 

I will try it. It seems odd, however.

Will grub search through the root partition until if finds the kernel 
and initramfs, or does it simply assume (correctly) that they are 
located in the /boot directory?

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: F16: Ctrl+Alt+L no more works as lock screen in gnome-shell

[Joachim Backes]

On 08/25/2011 03:46 PM, Peter Robinson wrote:

On Thu, Aug 25, 2011 at 1:58 PM, Joachim Backes
  wrote:

Hi,

since todays updates, Ctr+Alt+L no more locks the screen. Now I have to
activate the top right users menu and then press lock screen.

Anybody sees this too?


Known problem in F-15 too. Bug is
https://bugzilla.redhat.com/show_bug.cgi?id=708724

Peter


My keyboard: "germany no dead keys".

--
Joachim Backes 

http://www.rhrk.uni-kl.de/~backes



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Adding Fedora15 to F16alpha grub2 menu

[Clyde E. Kunkel]

On 08/25/2011 12:40 AM, Petrus de Calguarium wrote:
> 
> set root=(hd0,7)
> linux /boot/vmlinuz-2.6.40.3-0.fc15.x86_64 root=/dev/sda7 ro quiet etc
> etc etc etc etc rd.=0 etc etc etc
> initrd /boot/initramfs-2.6.40.3-0.fc15.x86_64.img
  ^
^
delete-|  (both of them)

-- 
Regards,
OldFart

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: F16: Ctrl+Alt+L no more works as lock screen in gnome-shell

[Peter Robinson]

On Thu, Aug 25, 2011 at 3:00 PM, Michael Schwendt  wrote:
> On Thu, 25 Aug 2011 14:46:54 +0100, PR (Peter) wrote:
>
>> On Thu, Aug 25, 2011 at 1:58 PM, Joachim Backes wrote:
>> > Hi,
>> >
>> > since todays updates, Ctr+Alt+L no more locks the screen. Now I have to
>> > activate the top right users menu and then press lock screen.
>> >
>> > Anybody sees this too?
>>
>> Known problem in F-15 too. Bug is
>> https://bugzilla.redhat.com/show_bug.cgi?id=708724
>
> Not triaged yet.
> Cannot confirm with F-15 x86_64 GNOME Shell and non-US keyboard layout.

I can confirm with a UK keyboard, want me to make note of it in the bug?

Peter
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: F16: Ctrl+Alt+L no more works as lock screen in gnome-shell

[Michael Schwendt]

On Thu, 25 Aug 2011 14:46:54 +0100, PR (Peter) wrote:

> On Thu, Aug 25, 2011 at 1:58 PM, Joachim Backes wrote:
> > Hi,
> >
> > since todays updates, Ctr+Alt+L no more locks the screen. Now I have to
> > activate the top right users menu and then press lock screen.
> >
> > Anybody sees this too?
> 
> Known problem in F-15 too. Bug is
> https://bugzilla.redhat.com/show_bug.cgi?id=708724

Not triaged yet.
Cannot confirm with F-15 x86_64 GNOME Shell and non-US keyboard layout.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: F16: Ctrl+Alt+L no more works as lock screen in gnome-shell

[Peter Robinson]

On Thu, Aug 25, 2011 at 1:58 PM, Joachim Backes
 wrote:
> Hi,
>
> since todays updates, Ctr+Alt+L no more locks the screen. Now I have to
> activate the top right users menu and then press lock screen.
>
> Anybody sees this too?

Known problem in F-15 too. Bug is
https://bugzilla.redhat.com/show_bug.cgi?id=708724

Peter
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

F16: Ctrl+Alt+L no more works as lock screen in gnome-shell

[Joachim Backes]

Hi,

since todays updates, Ctr+Alt+L no more locks the screen. Now I have to 
activate the top right users menu and then press lock screen.


Anybody sees this too?

Kind regards

Joachim Backes 

http://www.rhrk.uni-kl.de/~backes



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: F16 Update Kernels fail to boot

[Tom H]

On Wed, Aug 24, 2011 at 6:52 PM, Orion Poplawski  wrote:
> On 08/24/2011 04:31 PM, Adam Williamson wrote:
>>
>> The fact that GRUB 2 by default won't install to a partition, and will
>> only do it if you use --force, is known. It's why anaconda can't install
>> the bootloader to a partition in Alpha. That will be fixed (by using
>> --force) in Beta. The bug for anaconda is
>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=730915 .
>
> Is there a way to workaround this in a kickstart file (other than running
> grub2-install --force (hd0,0) in %post) by using partitioning/boatloader 
> options?

Just in case "(hd0,0)" isn't a typo, please note that grub2 numbers
partitions differently from grub1: sda1 is (hd0,1).
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs

[Panu Matilainen]

On 08/24/2011 08:11 PM, seth vidal wrote:
> On Wed, 2011-08-24 at 13:09 -0400, Tom Horsley wrote:
>> On Wed, 24 Aug 2011 17:26:44 +0100
>> Richard Hughes wrote:
>>
>>> I'm seriously wondering if multilib is worth all this hassle...
>>
>> Oh I've never wondered that: It has clearly never been a good
>> idea. Starting with the total lack of documentation about how
>> the heck it actually works when (for instance) multilib rpms
>> both contain /usr/bin binaries of the same name and going
>> through all the problems it causes with updates (like these).
>
> It is documented it is just confusing
>
> When you have two pkgs sharing the same binary path - the pkg in the
> preferred/compat arch for that platform has its files installed.
>
> Except when you install them in the wrong order - and then rpm will
> cough out a conflict. This, I think, has been fixed in more recent
> changes but I'm not 100% certain of that.

The conflict behavior should be consistent regardless of the order since 
rpm >= 4.6.0, ie since F10.

- Panu -
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Adding Fedora15 to F16alpha grub2 menu

[Joachim Backes]

On 08/25/2011 08:25 AM, Thomas Mittelstaedt wrote:

Am Mittwoch, den 24.08.2011, 22:40 -0600 schrieb Petrus de Calguarium:

I have installed F16α and with it grub2 to the MBR of /dev/sda. I am
experimenting happily with F16, but I am unable to add F15 to the
grub2 boot menu.

I have edited /etc/grub.d/40_custom and run grub2-mkconfig -o
/boot/grub2/grub.cfg, but my F15 entry never shows up in the menu,
even though it is in grub.cfg.

When I start the computer and select the (c)ommand line in grub, I am
able to enter:

set root=(hd0,7)
linux /boot/vmlinuz-2.6.40.3-0.fc15.x86_64 root=/dev/sda7 ro quiet etc
etc etc etc etc rd.=0 etc etc etc
initrd /boot/initramfs-2.6.40.3-0.fc15.x86_64.img

and then type boot, I am able to boot F15 without problem.

Entering the same into the grub.cfg file doesn't work.

How can I get a F15 menu entry in grub.cfg?

--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test


Well, F16 has grub2 according to your mail. I recently upgraded my main
machine to grub2 as well and I have the following entry to boot my
Fedora 15, which still has legacy grub, on a separate partition via:

### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries.  Simply
type the
# menu entries you want to add after this comment.  Be careful not to
change
# the 'exec tail' line above.

menuentry "Fedora (2.6.40-4.fc15.i686)" {
 recordfail=1
 if [ -n ${have_grubenv} ]; then save_env recordfail; fi
 insmod ext2
 set root=(hd0,3)
 search --no-floppy --fs-uuid --set
93f664e9-9013-47b4-b5d8-1239af7c0605
 linux /vmlinuz-2.6.40-4.fc15.i686 ro
root=/dev/mapper/vg_myfedora15-lv_root rd_LVM_LV=vg_myfedora15/lv_root
rd_LVM_LV=vg_myfedora15/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM
LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb quiet
 initrd /initramfs-2.6.40-4.fc15.i686.img
}


my grub.cfg (using chainloader) entry for F15 (after installing grub2 in 
F15 and installing then in F15 the grub2 bootloader to /dev/sda7):


menuentry 'Fedora 15' --class fedora --class gnu-linux --class gnu 
--class os {

set root=(hd0,7)
chainloader +1
}


This works on my box

Kind regards

Joachim Backes 

http://www.rhrk.uni-kl.de/~backes



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test