It entirely depends on the device you can only export sdcards as block storage.
For devices like the galaxy nexus and nexus 7 that only have internal storage
you can only use mtp or ptp I've found that digikam does a horrible job of
trying to pull photos when in ptp mode.
Simone Caronni wrote:
> On 17 Sep 2012 16:15, "Richard W.M. Jones" wrote:
> > (3) I don't use it any more. I just gave up trying to get files off
> > Android tablets. WTF don't they support USB mass storage like every
> > other thing out there?
I have a few devices, up to android 2.3.x block storage was the default,
On Mon, Sep 17, 2012 at 9:15 AM, Richard W.M. Jones wrote:
>
> I've orphaned this package. There are various
> reasons for this:
>
> (1) It's buggy: https://admin.fedoraproject.org/pkgdb/acls/bugs/mtpfs
>
> (2) Upstream is not responsive. The weight of developer effort seems
> to have moved to s
illa.redhat.com/show_bug.cgi?id=841260#c1
> >
> > (3) I don't use it any more. I just gave up trying to get files off
> > Android tablets. WTF don't they support USB mass storage like every
> > other thing out there?
>
> My understanding is that its so both the
gt; Android tablets. WTF don't they support USB mass storage like every
> other thing out there?
My understanding is that its so both the phone and computer can read/write
to the filesystem at the same time. It was needed to be able to move apps
to secondary storages amongst other th
I've orphaned this package. There are various
reasons for this:
(1) It's buggy: https://admin.fedoraproject.org/pkgdb/acls/bugs/mtpfs
(2) Upstream is not responsive. The weight of developer effort seems
to have moved to several alternative projects, and it's probably
worthwhile adopting one of
On Wed, 2012-05-16 at 00:10 -0300, Paulo César Pereira de Andrade wrote:
> 2012/5/15 Adam Williamson :
> > On Tue, 2012-05-15 at 23:47 -0300, Paulo César Pereira de Andrade wrote:
> >> I know I got what I deserved by attempting to "fix" by hand the move
> >> from / to /usr, just did need to boot fr
2012/5/15 Adam Williamson :
> On Tue, 2012-05-15 at 23:47 -0300, Paulo César Pereira de Andrade wrote:
>> I know I got what I deserved by attempting to "fix" by hand the move
>> from / to /usr, just did need to boot from the fedora16 dvd, mount lvm
>> root and finish my "fix"; brain fart, and cycli
On Tue, 2012-05-15 at 23:47 -0300, Paulo César Pereira de Andrade wrote:
> I know I got what I deserved by attempting to "fix" by hand the move
> from / to /usr, just did need to boot from the fedora16 dvd, mount lvm
> root and finish my "fix"; brain fart, and cyclic dep on moving /lib64
> to /usr/
I know I got what I deserved by attempting to "fix" by hand the move
from / to /usr, just did need to boot from the fedora16 dvd, mount lvm
root and finish my "fix"; brain fart, and cyclic dep on moving /lib64
to /usr/lib64 and then a symlink, leaving it with all binaries failing
due to missing /
On 03/21/2012 04:21 PM, Gerry Reno wrote:
> On 03/21/2012 03:40 PM, Josh Boyer wrote:
>
>> On Wed, Mar 21, 2012 at 2:53 PM, Gerry Reno wrote:
>>
>>
>>> From xen-devel list.
>>>
>>> How can I downgrade my Fedora 16 kernel to get around this kernel bug
>>> identified by Konrad?
>>>
>>> Yu
On 03/21/2012 03:40 PM, Josh Boyer wrote:
> On Wed, Mar 21, 2012 at 2:53 PM, Gerry Reno wrote:
>
>> From xen-devel list.
>>
>> How can I downgrade my Fedora 16 kernel to get around this kernel bug
>> identified by Konrad?
>>
>> Yum does not list any other kernels other than 3.2.10.
>>
> Un
On Wed, Mar 21, 2012 at 15:31:01 -0400,
Gerry Reno wrote:
On 03/21/2012 03:24 PM, Bruno Wolff III wrote:
On Wed, Mar 21, 2012 at 14:53:27 -0400,
Gerry Reno wrote:
From xen-devel list.
How can I downgrade my Fedora 16 kernel to get around this kernel bug
identified by Konrad?
Yum does no
On Wed, Mar 21, 2012 at 2:53 PM, Gerry Reno wrote:
> From xen-devel list.
>
> How can I downgrade my Fedora 16 kernel to get around this kernel bug
> identified by Konrad?
>
> Yum does not list any other kernels other than 3.2.10.
Unless you've done something odd, the previous 2 kernels should st
On 03/21/2012 03:24 PM, Bruno Wolff III wrote:
> On Wed, Mar 21, 2012 at 14:53:27 -0400,
> Gerry Reno wrote:
>> From xen-devel list.
>>
>> How can I downgrade my Fedora 16 kernel to get around this kernel bug
>> identified by Konrad?
>>
>> Yum does not list any other kernels other than 3.2.10.
>
On Wed, Mar 21, 2012 at 14:53:27 -0400,
Gerry Reno wrote:
From xen-devel list.
How can I downgrade my Fedora 16 kernel to get around this kernel bug
identified by Konrad?
Yum does not list any other kernels other than 3.2.10.
Normally you will have three install and can just pick another w
From xen-devel list.
How can I downgrade my Fedora 16 kernel to get around this kernel bug
identified by Konrad?
Yum does not list any other kernels other than 3.2.10.
Original Message
Subject:Re: [Xen-devel] Fedora 16 w/encrypted filesystem: unable to
boot Xen
On Sat, Feb 4, 2012 at 12:53 PM, Jef Spaleta wrote:
> On Fri, Feb 3, 2012 at 5:10 PM, darrell pfeifer wrote:
>> If you continue to repeat the "eating babies" myth then it will become
>> self-fulfilling.
>
> I would humbly suggest that use of future tense is that sentence is
> overly optimistic an
On Sun, 05 Feb 2012 05:34:39 +0100
Michel Alexandre Salim wrote:
> For those of us early testers, is it now safe to remove the usrmove
> repository and re-enable Rawhide? Or should we wait until F17 get
> branched and grab the fedora-release RPM that points to the branched
> repositories?
Rawhid
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/04/2012 11:43 PM, Kevin Fenzi wrote:
> On Fri, 3 Feb 2012 17:47:10 -0800 darrell pfeifer
> wrote:
>
>> On Fri, Feb 3, 2012 at 17:15, Adam Williamson
>> wrote:
>>
>>> On Fri, 2012-02-03 at 16:27 -0800, darrell pfeifer wrote:
As far as I'v
On Sat, Feb 4, 2012 at 16:27, Harald Hoyer wrote:
> Am 04.02.2012 02:47 schrieb "darrell pfeifer" :
>
> > c) the switch was pulled at a time when the main people who made the
> change were available rather than known to be away at a conference
> >
>
> We are reading, we have laptops, we can fix t
Am 04.02.2012 02:47 schrieb "darrell pfeifer" :
> c) the switch was pulled at a time when the main people who made the
change were available rather than known to be away at a conference
>
We are reading, we have laptops, we can fix things what's your problem?
--
devel mailing list
devel@lists
On Fri, 3 Feb 2012 17:47:10 -0800
darrell pfeifer wrote:
> On Fri, Feb 3, 2012 at 17:15, Adam Williamson
> wrote:
>
> > On Fri, 2012-02-03 at 16:27 -0800, darrell pfeifer wrote:
> > > As far as I've seen on the list, the /usr move stuff was supposed
> > > to be confined by tagging to f17-usermo
On Fri, Feb 03, 2012 at 05:53:04PM -0800, Adam Williamson wrote:
> On Fri, 2012-02-03 at 17:47 -0800, darrell pfeifer wrote:
> >
> >
> > On Fri, Feb 3, 2012 at 17:15, Adam Williamson
> > wrote:
> > On Fri, 2012-02-03 at 16:27 -0800, darrell pfeifer wrote:
> > > As far as I've see
On Fri, Feb 3, 2012 at 5:10 PM, darrell pfeifer wrote:
> If you continue to repeat the "eating babies" myth then it will become
> self-fulfilling.
I would humbly suggest that use of future tense is that sentence is
overly optimistic and is misleading. I think that sentence above reads
more accura
Am 03.02.2012 11:33, schrieb Kay Sievers:
> On Fri, Feb 3, 2012 at 11:25, Frank Murphy wrote:
>> On 02/02/12 18:47, Kay Sievers wrote:
>>>
>>> The former dracut ‘usrmove’ module has been renamed to ‘convertfs’. We
>>> need to carry that option for quite some time through future releases
>>
>> Does
Am 04.02.2012 03:50, schrieb Adam Williamson:
> On Fri, 2012-02-03 at 18:10 -0800, darrell pfeifer wrote:
>
>> If you want to respect people who are testing, then maybe there is
>> something better than "we don't have to exercise any care and we don't
>> care, wink, wink, grin."
>>
>>
>> There isn
On Sat, Feb 4, 2012 at 2:50 AM, Adam Williamson wrote:
> On Fri, 2012-02-03 at 18:10 -0800, darrell pfeifer wrote:
>
>> If you want to respect people who are testing, then maybe there is
>> something better than "we don't have to exercise any care and we don't
>> care, wink, wink, grin."
>>
>>
>>
On Fri, 2012-02-03 at 18:10 -0800, darrell pfeifer wrote:
> If you want to respect people who are testing, then maybe there is
> something better than "we don't have to exercise any care and we don't
> care, wink, wink, grin."
>
>
> There isn't anything in my request that seems difficult to do.
On Fri, Feb 3, 2012 at 17:53, Adam Williamson wrote:
> On Fri, 2012-02-03 at 17:47 -0800, darrell pfeifer wrote:
> >
> >
> > On Fri, Feb 3, 2012 at 17:15, Adam Williamson
> > wrote:
> > On Fri, 2012-02-03 at 16:27 -0800, darrell pfeifer wrote:
> > > As far as I've seen on the lis
On Fri, 2012-02-03 at 17:47 -0800, darrell pfeifer wrote:
>
>
> On Fri, Feb 3, 2012 at 17:15, Adam Williamson
> wrote:
> On Fri, 2012-02-03 at 16:27 -0800, darrell pfeifer wrote:
> > As far as I've seen on the list, the /usr move stuff was
> supposed to
> > be con
On Fri, Feb 3, 2012 at 17:15, Adam Williamson wrote:
> On Fri, 2012-02-03 at 16:27 -0800, darrell pfeifer wrote:
> > As far as I've seen on the list, the /usr move stuff was supposed to
> > be confined by tagging to f17-usermove so it wouldn't affect rawhide
> > until the big switch was pulled.
>
On Fri, 2012-02-03 at 16:27 -0800, darrell pfeifer wrote:
> As far as I've seen on the list, the /usr move stuff was supposed to
> be confined by tagging to f17-usermove so it wouldn't affect rawhide
> until the big switch was pulled.
Yes. We just pulled the big switch. :)
--
Adam Williamson
Fedo
On Fri, 3 Feb 2012 16:49:12 -0800
darrell pfeifer wrote:
> On Fri, Feb 3, 2012 at 16:33, Jason L Tibbitts III
> wrote:
>
> > > "dp" == darrell pfeifer writes:
> >
> > dp> As far as I've seen on the list, the /usr move stuff was
> > dp> supposed to be confined by tagging to f17-usermove so i
On Fri, Feb 3, 2012 at 16:33, Jason L Tibbitts III wrote:
> > "dp" == darrell pfeifer writes:
>
> dp> As far as I've seen on the list, the /usr move stuff was supposed to
> dp> be confined by tagging to f17-usermove so it wouldn't affect rawhide
> dp> until the big switch was pulled.
>
> Well
> "dp" == darrell pfeifer writes:
dp> As far as I've seen on the list, the /usr move stuff was supposed to
dp> be confined by tagging to f17-usermove so it wouldn't affect rawhide
dp> until the big switch was pulled.
Well, yes, but the big switch has actually been pulled.
- J<
--
devel ma
2 Packages
Total size: 2.0 M
Is this ok [y/N]: y
Downloading Packages:
Running Transaction Check
ERROR You need to update rpm to handle:
rpmlib(X-CheckUnifiedSystemdir) is needed by filesystem-3-2.fc17.x86_64
RPM needs to be updated
You could try running: rpm -Va --nofiles
On Fri, Feb 3, 2012 at 11:25, Frank Murphy wrote:
> On 02/02/12 18:47, Kay Sievers wrote:
>>
>> The former dracut ‘usrmove’ module has been renamed to ‘convertfs’. We
>> need to carry that option for quite some time through future releases
>
> Does this mean that ‘convertfs’ will be build into dra
On 02/02/12 18:47, Kay Sievers wrote:
The former dracut ‘usrmove’ module has been renamed to ‘convertfs’. We
need to carry that option for quite some time through future releases
Does this mean that ‘convertfs’ will be build into dracut-*?
Does the user\tester have to keep doing "--force --ad
lib → /usr/lib
> /lib64 → /usr/lib64
>
> Some reasoning behind this change is outlined here:
> http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
>
> The official Fedora 17 feature page is here:
> https://fedoraproject.org/wiki/Features/UsrMove
>
> The
On 02/02/12 12:42, Rex Dieter wrote:
Would the /usrmove script
replace the hardlink with the softlink?
no.
-- rex
Thanks Rex,
Unfortunatly I'm not a scripter.
--
Regards,
Frank Murphy, friend of fedoraproject
UTF_8 Encoded
--
devel mailing list
devel@lists.fedoraproject.org
https://adm
Frank Murphy wrote:
> On 27/01/12 13:10, Harald Hoyer wrote:
>> Hello Testers and rawhide Users,
>>
>> Fedora 17 will locate the entire base operating system in /usr. The
>> directories /bin, /sbin, /lib, /lib64 will only be symlinks:
>> /bin → /usr/bin
>> /sbin → /usr/sbin
>> /lib → /usr/li
On 27/01/12 13:10, Harald Hoyer wrote:
Hello Testers and rawhide Users,
Fedora 17 will locate the entire base operating system in /usr. The directories
/bin, /sbin, /lib, /lib64 will only be symlinks:
/bin → /usr/bin
/sbin → /usr/sbin
/lib → /usr/lib
/lib64 → /usr/lib64
if before the
On 02/01/2012 06:38 PM, Bill Nottingham wrote:
Panu Matilainen (pmati...@laiskiainen.org) said:
To-be-installed files obviously have no on-disk fingerprints, so it
wont work for initial installation. So yes, those "fake" compatibility
provides are needed. Strictly speaking, compatibility provide
Panu Matilainen (pmati...@laiskiainen.org) said:
> >>>To-be-installed files obviously have no on-disk fingerprints, so it
> >>>wont work for initial installation. So yes, those "fake" compatibility
> >>>provides are needed. Strictly speaking, compatibility provides would
> >>>be needed for ALL the
Once upon a time, Genes MailLists said:
> Just asking - does a bind mount of /bin instead of a soft link help?
That doesn't affect RPM database and yum metadata issues.
--
Chris Adams
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's eno
On 02/01/2012 04:41 PM, Chris Adams wrote:
Once upon a time, Emanuel Rietveld said:
On 02/01/2012 01:32 PM, Panu Matilainen wrote:
To-be-installed files obviously have no on-disk fingerprints, so it
wont work for initial installation. So yes, those "fake" compatibility
provides are needed. Str
On 02/01/2012 09:41 AM, Chris Adams wrote:
> Once upon a time, Emanuel Rietveld said:
>> On 02/01/2012 01:32 PM, Panu Matilainen wrote:
>>> To-be-installed files obviously have no on-disk fingerprints, so it
>>> wont work for initial installation. So yes, those "fake" compatibility
>>> provides
Once upon a time, Emanuel Rietveld said:
> On 02/01/2012 01:32 PM, Panu Matilainen wrote:
> >To-be-installed files obviously have no on-disk fingerprints, so it
> >wont work for initial installation. So yes, those "fake" compatibility
> >provides are needed. Strictly speaking, compatibility prov
On 02/01/2012 01:32 PM, Panu Matilainen wrote:
To-be-installed files obviously have no on-disk fingerprints, so it
wont work for initial installation. So yes, those "fake" compatibility
provides are needed. Strictly speaking, compatibility provides would
be needed for ALL the moved files, not j
On 01/31/2012 11:30 PM, James Antill wrote:
On Tue, 2012-01-31 at 15:58 -0500, Bill Nottingham wrote:
James Antill (ja...@fedoraproject.org) said:
[root@nostromo ~]# mv /bin /cow
[root@nostromo ~]# /cow/ln -s /cow /bin
[root@nostromo ~]# rpm -qf /cow/bash
bash-4.2.20-1.fc16.x86_64
[root@nostrom
Le Mar 31 janvier 2012 21:32, James Antill a écrit :
> Also, even if someone could fix rpm to work this out, making this work
> at the yum layer is _much_ harder ... because the repodata does not
> currently specify that /path/to/blah is a regular file or a symlink (and
> if it's a symlink, what
On Wed, 2012-02-01 at 02:38 +0100, Kay Sievers wrote:
> > Installation fails at partitioning stage, with udisksd hitting "Error
> > opening /etc/crypttab file: Failed to open file '/etc/crypttab': No such
> > file or directory (g-file-error-quark, 4)"
> >
> > The file /etc/crypttab indeed doesn't
On Tue, Jan 31, 2012 at 23:36, Adam Williamson wrote:
> On Tue, 2012-01-31 at 14:23 -0800, Adam Williamson wrote:
>> On Fri, 2012-01-27 at 14:10 +0100, Harald Hoyer wrote:
>> > Hello Testers and rawhide Users,
>> >
>> > Fedora 17 will locate the entire base operating system in /usr. The
>> > dire
On Tue, 2012-01-31 at 14:23 -0800, Adam Williamson wrote:
> On Fri, 2012-01-27 at 14:10 +0100, Harald Hoyer wrote:
> > Hello Testers and rawhide Users,
> >
> > Fedora 17 will locate the entire base operating system in /usr. The
> > directories
> > /bin, /sbin, /lib, /lib64 will only be symlinks:
On Fri, 2012-01-27 at 14:10 +0100, Harald Hoyer wrote:
> Hello Testers and rawhide Users,
>
> Fedora 17 will locate the entire base operating system in /usr. The
> directories
> /bin, /sbin, /lib, /lib64 will only be symlinks:
> /bin → /usr/bin
> /sbin → /usr/sbin
> /lib → /usr/lib
> /lib64 →
On Tue, 2012-01-31 at 15:58 -0500, Bill Nottingham wrote:
> James Antill (ja...@fedoraproject.org) said:
> > > [root@nostromo ~]# mv /bin /cow
> > > [root@nostromo ~]# /cow/ln -s /cow /bin
> > > [root@nostromo ~]# rpm -qf /cow/bash
> > > bash-4.2.20-1.fc16.x86_64
> > > [root@nostromo ~]# rpm -qf /
Bill Nottingham (nott...@redhat.com) said:
> > Good to see everyone still doesn't read what I write.
> >
> > As I said, rpm _does something_ to make the above work for -qf (the
> > above even works if you inside /cow ... as long as the /bin symlink
> > exists!).
> > However, it _does not_ work
James Antill (ja...@fedoraproject.org) said:
> > [root@nostromo ~]# mv /bin /cow
> > [root@nostromo ~]# /cow/ln -s /cow /bin
> > [root@nostromo ~]# rpm -qf /cow/bash
> > bash-4.2.20-1.fc16.x86_64
> > [root@nostromo ~]# rpm -qf /bin/bash
> > bash-4.2.20-1.fc16.x86_64
> >
> > rpm should already han
On Tue, 2012-01-31 at 11:03 -0500, Bill Nottingham wrote:
> Miloslav Trmač (m...@volny.cz) said:
> > > To be precise:
> > >
> > > [root@nostromo ~]# mv /bin /cow
> > > [root@nostromo ~]# /cow/ln -s /cow /bin
> > > [root@nostromo ~]# rpm -qf /cow/bash
> > > bash-4.2.20-1.fc16.x86_64
> > > [root@nos
On Tue, 2012-01-31 at 10:52 -0500, Bill Nottingham wrote:
> Bill Nottingham (nott...@redhat.com) said:
> > Miloslav Trmač (m...@volny.cz) said:
> > > On Tue, Jan 31, 2012 at 1:06 AM, Martin Langhoff
> > > wrote:
> > > >> But you can add:
> > > >>
> > > >> Provides: /bin/foo
> > > >
> > > > Ugh!
What would be the pros/cons of a bind mount instead of a soft link for
/bin et al?
gene
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Fri, 2012-01-27 at 14:10 +0100, Harald Hoyer wrote:
> Add f17-usrmove in the file /etc/yum.repos.d/f17-usrmove.repo
> [f17-usrmove]
> name=Fedora $releasever - $basearch
> failovermethod=priority
> baseurl=http://koji.fedoraproject.org/repos/f17-usrmove/latest/$basearch
> enabled=1
> metad
On Tue, 2012-01-31 at 11:03 -0500, Bill Nottingham wrote:
> Miloslav Trmač (m...@volny.cz) said:
> > > To be precise:
> > >
> > > [root@nostromo ~]# mv /bin /cow
> > > [root@nostromo ~]# /cow/ln -s /cow /bin
> > > [root@nostromo ~]# rpm -qf /cow/bash
> > > bash-4.2.20-1.fc16.x86_64
> > > [root@nos
On Tue, Jan 31, 2012 at 11:03 AM, Bill Nottingham wrote:
> Miloslav Trmač (m...@volny.cz) said:
> When calculating local on-system provides, it should - in fact, I'd be
> surprised if it doesn't. Admins sometimes move directories around and
> replace them with symlinks.
Well, that's a very differ
prised if it doesn't. Admins sometimes move directories around and
replace them with symlinks.
Is the statement that it won't take it into account for an initial install
transaction?
(The solution then would be to merely not change the packaging outside of
the filesystem package.)
Bill
--
On Tue, Jan 31, 2012 at 4:52 PM, Bill Nottingham wrote:
> Bill Nottingham (nott...@redhat.com) said:
>> Miloslav Trmač (m...@volny.cz) said:
>> > On Tue, Jan 31, 2012 at 1:06 AM, Martin Langhoff
>> > wrote:
>> > >> But you can add:
>> > >>
>> > >> Provides: /bin/foo
>> > >
>> > > Ugh! Will that
Bill Nottingham (nott...@redhat.com) said:
> Miloslav Trmač (m...@volny.cz) said:
> > On Tue, Jan 31, 2012 at 1:06 AM, Martin Langhoff
> > wrote:
> > >> But you can add:
> > >>
> > >> Provides: /bin/foo
> > >
> > > Ugh! Will that be needed that across the distro for a release or two?
> >
> > h
Miloslav Trmač (m...@volny.cz) said:
> On Tue, Jan 31, 2012 at 1:06 AM, Martin Langhoff
> wrote:
> >> But you can add:
> >>
> >> Provides: /bin/foo
> >
> > Ugh! Will that be needed that across the distro for a release or two?
>
> http://pkgs.fedoraproject.org/gitweb/?p=coreutils.git;a=commitdif
Miloslav Trmač wrote:
> http://pkgs.fedoraproject.org/gitweb/?p=coreutils.git;a=commitdiff;h=09220fef36dcc2fe06bd858578119872f889c7e2
>
> As you say, ugh!.
Yeah, this is awful!
Can't you push more strongly in FESCo for a revote? This "feature" really needs
to be reconsidered, and hopefully thro
On Tue, Jan 31, 2012 at 1:06 AM, Martin Langhoff
wrote:
>> But you can add:
>>
>> Provides: /bin/foo
>
> Ugh! Will that be needed that across the distro for a release or two?
http://pkgs.fedoraproject.org/gitweb/?p=coreutils.git;a=commitdiff;h=09220fef36dcc2fe06bd858578119872f889c7e2
As you say
On Jan 30, 2012 5:37 PM, "James Antill" wrote:
> > > For a trivial example -- if package A depends on /bin/foo, will yum &
> > > rpm be satisfied with /usr/bin/foo?
> >
> > Assuming /bin -> /usr/bin link is packaged, yes.
>
> No, not in any meaningful way, although I assume all of the problems
>
On Mon, 2012-01-30 at 15:47 -0500, Bill Nottingham wrote:
> Martin Langhoff (martin.langh...@gmail.com) said:
> > On Fri, Jan 27, 2012 at 8:10 AM, Harald Hoyer wrote:
> > > Fedora 17 will locate the entire base operating system in /usr. The
> > > directories
> > > /bin, /sbin, /lib, /lib64 will
Martin Langhoff (martin.langh...@gmail.com) said:
> On Mon, Jan 30, 2012 at 3:47 PM, Bill Nottingham wrote:
> > Assuming /bin -> /usr/bin link is packaged, yes.
>
> Wow, it follows the symlink created by a 3rd package.
Technically, the link doesn't even need to be packaged; as long as /bin
exis
On Mon, Jan 30, 2012 at 3:47 PM, Bill Nottingham wrote:
> Assuming /bin -> /usr/bin link is packaged, yes.
Wow, it follows the symlink created by a 3rd package.
clever,
m
--
martin.langh...@gmail.com
mar...@laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get d
Martin Langhoff (martin.langh...@gmail.com) said:
> On Fri, Jan 27, 2012 at 8:10 AM, Harald Hoyer wrote:
> > Fedora 17 will locate the entire base operating system in /usr. The
> > directories
> > /bin, /sbin, /lib, /lib64 will only be symlinks:
> > /bin → /usr/bin
>
> Interesting!
>
> Do we
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/30/2012 09:34 AM, Frank Murphy wrote:
> On 30/01/12 14:28, Daniel J Walsh wrote:
>>>
>> Yes grep autorelabel /usr/lib/dracut/modules.d/30usrmove/*
>> /usr/lib/dracut/modules.d/30usrmove/usrmove-convert.sh:echo "Set
>> autorelabel flag."
>> /u
On Fri, Jan 27, 2012 at 8:10 AM, Harald Hoyer wrote:
> Fedora 17 will locate the entire base operating system in /usr. The
> directories
> /bin, /sbin, /lib, /lib64 will only be symlinks:
> /bin → /usr/bin
Interesting!
Do we need to teach rpm / yum about the equivalence, when resolving
depende
On 30/01/12 14:28, Daniel J Walsh wrote:
Yes
grep autorelabel /usr/lib/dracut/modules.d/30usrmove/*
/usr/lib/dracut/modules.d/30usrmove/usrmove-convert.sh:echo "Set
autorelabel flag."
/usr/lib/dracut/modules.d/30usrmove/usrmove-convert.sh:>
"$ROOT/.autorelabel"
What about on an already done b
, kernel-devel and
> gcc from updates-testing (I have to compile acpi_call to turn off
> my new "fusion" AMD card), the upgrade went without a hitch.
>
> Answering Dan's SELinux suggestion -- I tried doing the migration
> with enforcing=0 -- at the next boot it still trie
On Fri, Jan 27, 2012 at 10:10 PM, Harald Hoyer wrote:
> Hello Testers and rawhide Users,
>
> Fedora 17 will locate the entire base operating system in /usr.
> [...]
You guys really are going to do this?
If it were I, instead of combining, I'd be working through the list of
what is where and star
Am 28.01.2012 20:49, schrieb Garrett Holmstrom:
> On 2012-01-27 5:10, Harald Hoyer wrote:
>> Any files with conflicting names, which the conversion could not resolve,
>> will
>> be backed up to files named *.usrmove~ residing in /usr/lib, /usr/lib64,
>> /usr/bin and /usr/sbin.
>
> To which file d
pgrade went without a hitch.
Answering Dan's SELinux suggestion -- I tried doing the migration with
enforcing=0 -- at the next boot it still tries to relabel the filesystem
(I aborted once and booted with selinux=0 to verify everything is
working, and am now doing the relabeling).
Does the usrmove scr
On 2012-01-27 5:10, Harald Hoyer wrote:
Any files with conflicting names, which the conversion could not resolve, will
be backed up to files named *.usrmove~ residing in /usr/lib, /usr/lib64,
/usr/bin and /usr/sbin.
To which file does the conversion script append this suffix when it
resolves a
On 01/27/2012 05:57 PM, John Ellson wrote:
On 01/27/2012 08:10 AM, Harald Hoyer wrote:
Hello Testers and rawhide Users,
Fedora 17 will locate the entire base operating system in /usr. The
directories
/bin, /sbin, /lib, /lib64 will only be symlinks:
/bin → /usr/bin
/sbin → /usr/sbin
/lib
On 01/28/2012 06:48 AM, Josh Boyer wrote:
On Fri, Jan 27, 2012 at 5:57 PM, John Ellson wrote:
Another issue is that I have:
/bin/sh: error while loading shared libraries: libc.so.6: cannot open
shared object file: No such file or directory
[1.796642] Kernel panic - not syncing: att
On Fri, Jan 27, 2012 at 5:57 PM, John Ellson wrote:
> Another issue is that I have:
>
> /bin/sh: error while loading shared libraries: libc.so.6: cannot open
> shared object file: No such file or directory
> [ 1.796642] Kernel panic - not syncing: attempted to kill init!
>
> when trying t
;
> The needed changes to implement the unified filesystem are about to land in
> rawhide soon. New installations of rawhide/Fedora 17 will install the symlinks
> right away, and no special care needs to be taken
Thanks for your work, Harald.
So, as I mentioned in another follow-up, we didn&#
On 01/27/2012 08:10 AM, Harald Hoyer wrote:
Hello Testers and rawhide Users,
Fedora 17 will locate the entire base operating system in /usr. The directories
/bin, /sbin, /lib, /lib64 will only be symlinks:
/bin → /usr/bin
/sbin → /usr/sbin
/lib → /usr/lib
/lib64 → /usr/lib64
Mostly wo
Harald Hoyer wrote:
> A screenshot of a successful conversion process is here:
> http://people.freedesktop.org/~kay/usrmove-convert-log.png
So this copies the whole affected directories and then swaps in the copy,
right? That means it needs enough disk space left in / to carry full copies
of bin
On 27/01/12 14:12, Harald Hoyer wrote:
Have you checked "enforcing=0" instead? If this worked, you'd not need
to relabel the whole system, but only the parts affected by the move. Or
so I'd like to believe ;-).
Nils
Feel free to test! :-)
Finished fist kvm_guest
selinux=1 enforcing=1
no pr
Finally my VM relabeled everything after 8 hours. Seems to work fine with
selinux enabled.
Should have booted with "enforce=0" and removed the .autorelabel creation
from the conversion script.
Will test that version on Monday.
Am 27.01.2012 14:36 schrieb "Michal Schmidt" :
> On 01/27/2012 02:10
srMove
>
> The needed changes to implement the unified filesystem are about to
> land in rawhide soon. New installations of rawhide/Fedora 17 will
> install the symlinks right away, and no special care needs to be
> taken
>
> Currently installed systems need some manual steps
Am 27.01.2012 15:03, schrieb Nils Philippsen:
> On Fri, 2012-01-27 at 14:10 +0100, Harald Hoyer wrote:
>
>> - append “selinux=0” for now, because the relabeling in a converted F16
>> system
>> does not seem to work properly at this moment
>
> Have you checked "enforcing=0" instead? If this work
On Fri, 2012-01-27 at 14:10 +0100, Harald Hoyer wrote:
> - append “selinux=0” for now, because the relabeling in a converted F16
> system
> does not seem to work properly at this moment
Have you checked "enforcing=0" instead? If this worked, you'd not need
to relabel the whole system, but only
On 27/01/12 13:10, Harald Hoyer wrote:
Update the installed initramfs image for your current kernel, and instruct
dracut to include the dracut module to convert your current filesystem:
# dracut --force --add usrmove
Is it only a one off this image?
The next update for kernel,
will know of
nt kernel, and
>> instruct dracut to include the dracut module to convert your current
>> filesystem: # dracut --force --add usrmove
>>
>> If dracut detects ‘rd.usrmove’ on the kernel command line at bootup,
>> it starts the filesystem conversion of the root filesystem
On 01/27/2012 02:10 PM, Harald Hoyer wrote:
SELinux relabelling should take effect after you rebooted your updated system
and can take a long time (at least in a VM it takes insanely long and is still
not finished). We are currently investigating, what seem to take so long, so you
might consider
te dracut
This will hit me soon automatically (as it is in rawhide proper, and I
update regularly).
> Update the installed initramfs image for your current kernel, and
> instruct dracut to include the dracut module to convert your current
> filesystem: # dracut --force --add usrmov
Am 27.01.2012 14:10, schrieb Harald Hoyer:
> ...
> Download and install the most recent dracut package from rawhide:
> # yum --enablerepo=rawhide update dracut
> ...
you should have at least: dracut-014-77.git20120126.fc17
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedorap
301 - 400 of 409 matches
Mail list logo
