3:10 a.m.
I tried to do an identical second install on the same machine, but the
installer Anaconda gives an error about being unable to set a root
partition.
The only difference compared with the first successful install is that
there is a bit less disk free space, and of course another F25 already
installed. Previous install was about 20GB in 60GB free space. Current
failed attempt is also 20GB in remaining 35GB space.
5:42 a.m.
On Sun, 1 Jan 2017 10:10:55 +0100, Mayavimmer wrote:
I tried to do an identical second install on the same machine, but
the
installer Anaconda gives an error about being unable to set a root
partition.
The only difference compared with the first successful install is that
there is a bit less disk free space, and of course another F25 already
installed. Previous install was about 20GB in 60GB free space. Current
failed attempt is also 20GB in remaining 35GB space.
Which installation mode have you tried? Automatic partitioning or manual
partitioning setup?
6:01 a.m.
On 01/01/2017 12:42, Michael Schwendt wrote:
On Sun, 1 Jan 2017 10:10:55 +0100, Mayavimmer wrote:
> I tried to do an identical second install on the same machine, but the
> installer Anaconda gives an error about being unable to set a root
> partition.
>
> The only difference compared with the first successful install is that
> there is a bit less disk free space, and of course another F25 already
> installed. Previous install was about 20GB in 60GB free space. Current
> failed attempt is also 20GB in remaining 35GB space.
Which installation mode have you tried? Automatic partitioning or manual
partitioning setup?
Always manual.
Also note that "manual" does not seem to be very manual after all. In
previous more complicated installs it chooses put new partitions in
seemingly arbitrary empty spaces like LVMs.
And when it refuses to carry out my indications it does not give
detailed reasons why, just a generic can't do it. Very frustrating.
I have not figured out how to manually choose a partition myself.
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
8:07 a.m.
On Sun, 1 Jan 2017 13:01:03 +0100, Mayavimmer wrote:
> Which installation mode have you tried? Automatic partitioning
or manual
> partitioning setup?
Always manual.
Also note that "manual" does not seem to be very manual after all.
Better not comment on it before you are familiar with it. ;-)
If you've really entered the manual partitioning setup, you can choose
individual partitions, their mount points and reformatting option
yourself.
8:17 a.m.
On 01/01/2017 15:07, Michael Schwendt wrote:
On Sun, 1 Jan 2017 13:01:03 +0100, Mayavimmer wrote:
>> Which installation mode have you tried? Automatic partitioning or manual
>> partitioning setup?
>
> Always manual.
>
> Also note that "manual" does not seem to be very manual after all.
Better not comment on it before you are familiar with it. ;-)
If you've really entered the manual partitioning setup, you can choose
individual partitions, their mount points and reformatting option
yourself.
I tried that many times. Sometimes it works sometimes not. Very frustrating.
Why not comment? We should make light not darkness. Is there a lot of
censorship on this list too? Just preface everything with IMHO and
you're all set. IMHO.
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
8:31 a.m.
On Sun, 1 Jan 2017 15:17:43 +0100, Mayavimmer wrote:
> Better not comment on it before you are familiar with it. ;-)
> If you've really entered the manual partitioning setup, you can choose
> individual partitions, their mount points and reformatting option
> yourself.
I tried that many times. Sometimes it works sometimes not. Very frustrating.
Why not comment? We should make light not darkness.
Then how about explaining in detail what exactly you've tried? If you
tell the installer which existing partition or LV to use for the root fs,
the installer doesn't override your decision. Unless you ask the installer
to do automatic partitioning.
Is there a lot of censorship on this list too?
That's an irrational comment.
Just preface everything with IMHO and
you're all set. IMHO.
Don't let your frustration pile up so quickly. Try again, take notes
of the steps and give a more detailed description of what you've tried.
I do manual installs of Fedora alongside existing installations often,
and your description so far sounds like PEBKAC. ;-)
9:15 a.m.
On 01/01/2017 15:31, Michael Schwendt wrote:
On Sun, 1 Jan 2017 15:17:43 +0100, Mayavimmer wrote:
>> Better not comment on it before you are familiar with it. ;-)
>> If you've really entered the manual partitioning setup, you can choose
>> individual partitions, their mount points and reformatting option
>> yourself.
>
> I tried that many times. Sometimes it works sometimes not. Very frustrating.
>
> Why not comment? We should make light not darkness.
Then how about explaining in detail what exactly you've tried? If you
tell the installer which existing partition or LV to use for the root fs,
the installer doesn't override your decision. Unless you ask the installer
to do automatic partitioning.
I have tried that very thing many times. It seems to fail in complicated
situations. And it never gives much of a diagnostic message beyond "your
configuration cannot be implemented" or some such. I'll try to repeat
those experiments and give details, starting tomorrow, if I can.
> Is there a lot of censorship on this list too?
That's an irrational comment.
No, that's a question. I am new to the list and would like to know if it
works efficiently or it is a wasteland of egos like most of the
internet. Can anyone express opinions here without being shot at? I sure
hope so. In my humble opinion the F25 installer is awkward. Can I say that?
> Just preface everything with IMHO and
> you're all set. IMHO.
Don't let your frustration pile up so quickly. Try again, take notes
of the steps and give a more detailed description of what you've tried.
I do manual installs of Fedora alongside existing installations often,
I have also done many installs of other distros in mixed environments.
and your description so far sounds like PEBKAC. ;-)
I might accept that as your own opinion if you knew the actual details,
which I have not given yet, because I would have to reinstall yet again.
But all you know is that I have tried manual installation and failed.
Thus your contribution so far sounds like an ad hominem. ;-)
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
9:30 a.m.
On Sun, 2017-01-01 at 16:15 +0100, Mayavimmer wrote:
> That's an irrational comment.
No, that's a question. I am new to the list and would like to know if it
works efficiently or it is a wasteland of egos like most of the
internet. Can anyone express opinions here without being shot at? I sure
hope so. In my humble opinion the F25 installer is awkward. Can I say that?
The list policies and archives are both online, so you can verify that
moderators have a very light hand and only intervene if things
degenerate to personal insults, which is rare. Plenty of us disagree
about plenty of things, but you'll find that people are helpful when
you give enough relevant information. Saying "the installer is awkward"
is not information, it's an opinion and tells us nothing except that
you had a problem with it. I also had a problem with it about 3 years
ago but was very explicit about what was happening and no-one shot me
down.
poc
10:12 a.m.
On 01/01/2017 16:30, Patrick O'Callaghan wrote:
On Sun, 2017-01-01 at 16:15 +0100, Mayavimmer wrote:
>> That's an irrational comment.
>
> No, that's a question. I am new to the list and would like to know if it
> works efficiently or it is a wasteland of egos like most of the
> internet. Can anyone express opinions here without being shot at? I sure
> hope so. In my humble opinion the F25 installer is awkward. Can I say that?
The list policies and archives are both online, so you can verify that
moderators have a very light hand and only intervene if things
degenerate to personal insults, which is rare. Plenty of us disagree
about plenty of things, but you'll find that people are helpful when
you give enough relevant information.
Thank you for answering, that is useful.
Saying "the installer is awkward"
is not information, it's an opinion and tells us nothing except
that
you had a problem with it.
In the context of this discussion it is a useful information to say "the
installer is awkward" because it shows where I am coming from. In the
last 24 hours, as you can read in the last few posts, I have discovered
(and it is still work in progress) that:
1. The installer takes 40 minutes before it can even get going on my
machine, due to improper fscking. A bug. In the same last 24 hour I
installed Mint and Rosalinux on the same machine in 15 min. total each.
2. If you include /boot inside LVM it works, but the second F25 install
erases all previous installs from boot menu.
3. If you already have one other LVM install with some free space, the
new one forcibly grabs that free space.
4. If empty space is too low, according to unfathomable and varying
criteria (at one point I had 35GB free) it fails.
5. All the above failures without so much as a: Sorry mate, I tried
making a 10GB root partition inside /dev/sdb17 but could not because
there are only 8GB available. Instead I get something like: Your
configuration does not work, bud.
6. Etc.
So when I try to address other issues it is more efficient and
descriptive to not repeat the whole thing every time and just summarize
with "the installer is awkward". It is the context which gives meaning
to the words.
I also had a problem with it about 3 years
ago but was very explicit about what was happening and no-one shot
me
down.
Thank you, that is very useful. It's the first admission that some
problems existed at least in the past.
poc
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
9:41 a.m.
>
>> Is there a lot of censorship on this list too?
>
> That's an irrational comment.
No, that's a question. I am new to the list and would like to know if it
works efficiently or it is a wasteland of egos like most of the
internet. Can anyone express opinions here without being shot at? I sure
hope so. In my humble opinion the F25 installer is awkward. Can I say that?
This is a very helpful list, perhaps the most (along with openbox and R-help) that I have
membership too, People are different, of course, some respondents are caustic but helpful,
some are very gentle and so, some others caustic and unhelpful and some others gentle and
unhelpful.
Of course, the same goes for questioners also. Some wanting to learn and some do not even
bother acknowledging if their problem was solved or not. Of course, it does not help at
all when they do not provide any details and expect people wanting to help to divine their
issues and some even get very cross when asked otherwise.
We don't often recognize that these are volunteers and helping to the best of their
ability and resources (mostly time) that are in short supply.
But overall, a very friendly and helpful list with people willing to take the time. I
learnt linux exclusively here, though I had used linux (RH and SuSE) predating Fedora.
I might accept that as your own opinion if you knew the actual
details,
which I have not given yet, because I would have to reinstall yet again.
But all you know is that I have tried manual installation and failed.
Thus your contribution so far sounds like an ad hominem. ;-)
See above. Note also, that the written word is not always the same as in contextual
conversation, so with that I would not be quick to judge.
Ranjan
10:16 a.m.
On 01/01/2017 16:41, Ranjan Maitra wrote:
>>
>>> Is there a lot of censorship on this list too?
>>
>> That's an irrational comment.
>
> No, that's a question. I am new to the list and would like to know if it
> works efficiently or it is a wasteland of egos like most of the
> internet. Can anyone express opinions here without being shot at? I sure
> hope so. In my humble opinion the F25 installer is awkward. Can I say that?
>
This is a very helpful list, perhaps the most (along with openbox and R-help) that I have
membership too, People are different, of course, some respondents are caustic but helpful,
some are very gentle and so, some others caustic and unhelpful and some others gentle and
unhelpful.
Of course, the same goes for questioners also. Some wanting to learn and some do not even
bother acknowledging if their problem was solved or not. Of course, it does not help at
all when they do not provide any details and expect people wanting to help to divine their
issues and some even get very cross when asked otherwise.
We don't often recognize that these are volunteers and helping to the best of their
ability and resources (mostly time) that are in short supply.
But overall, a very friendly and helpful list with people willing to take the time. I
learnt linux exclusively here, though I had used linux (RH and SuSE) predating Fedora.
> I might accept that as your own opinion if you knew the actual details,
> which I have not given yet, because I would have to reinstall yet again.
> But all you know is that I have tried manual installation and failed.
> Thus your contribution so far sounds like an ad hominem. ;-)
See above. Note also, that the written word is not always the same as in contextual
conversation, so with that I would not be quick to judge.
I agree, that's exactly what I said in my last post 1 minute ago.
Also, if you read the whole quote, you'll see that it was not me who was
quick to judge.
Going for coffee. I'll be back in an hour.
Ranjan
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
11:39 a.m.
On Sun, 1 Jan 2017 16:15:57 +0100, Mayavimmer wrote:
I have tried that very thing many times. It seems to fail in
complicated
situations.
Such as?
Just out of interest (and I could have spared myself this test), I've done
another F25 installation (from Workstation x86_64 live image) to a machine
that can boot F25, F24, F22 and some other distributions already. LVM, ext4
and LUKS involved. I've asked for manual partitioning and haven't run into
any issues.
And it never gives much of a diagnostic message beyond "your
configuration cannot be implemented" or some such. I'll try to repeat
those experiments and give details, starting tomorrow, if I can.
*That* might lead to something.
>> Is there a lot of censorship on this list too?
>
> That's an irrational comment.
No, that's a question. I am new to the list and would like to know if it
works efficiently or it is a wasteland of egos like most of the
internet.
That's another irrational comment. I highly recommend you don't flee into
more such off-topic comments.
In my humble opinion the F25 installer is awkward. Can I say that?
If it makes you happy. Decide yourself.
> and your description so far sounds like PEBKAC. ;-)
I might accept that as your own opinion if you knew the actual details,
which I have not given yet,
Hence my earlier requests for details.
because I would have to reinstall yet again.
But all you know is that I have tried manual installation and failed.
Seriously? You wrote:
| Also note that "manual" does not seem to be very manual after all.
| In previous more complicated installs it chooses put new partitions
| in seemingly arbitrary empty spaces like LVMs.
???
Thus your contribution so far sounds like an ad hominem. ;-)
Talk is cheap.
2:49 p.m.
On 01/01/2017 18:39, Michael Schwendt wrote:
On Sun, 1 Jan 2017 16:15:57 +0100, Mayavimmer wrote:
> I have tried that very thing many times. It seems to fail in complicated
> situations.
Such as?
I have described them already a few times. I don't want to make this
thread very long. I will start a new thread with exact repeatable
failure scenarios, as soon as I can, so we can have a disciplined
discussion about this.
Just out of interest (and I could have spared myself this test)
You could start by sparing yourself this comment, sir. I also have spent
many hours on this. Because I have to. If you don't want, you are free
to do anything else you like.
, I've done
another F25 installation (from Workstation x86_64 live image) to a
machine
that can boot F25, F24, F22 and some other distributions already. LVM, ext4
and LUKS involved. I've asked for manual partitioning and haven't run into
any issues.
Good for you. When I tried it, I ran into issues, which is why I am here
asking the list for their experiences. The information you are giving me
right here is no more precise and detailed than what I gave earlier. I
need details! Did you UEFI or BIOS? How much free space did you have? Is
that space all in a linear chunk or spread out to a piece in an LVM and
another piece a raw partition, etc? Was your /boot inside or outside the
LVM? Was there a preexisting Btrfs partition with some free space in it?
Did you have a preexisting ext4 over LVM over Md RAID 1 install that may
have confused the installer? I mentioned somewhere that on one machine
_each_ install took 40 min. to finish the initial fsck! How long was
yours? These are some of the problems I ran into. But you did not have
any issues. Good for you.
> And it never gives much of a diagnostic message beyond "your
> configuration cannot be implemented" or some such. I'll try to repeat
> those experiments and give details, starting tomorrow, if I can.
*That* might lead to something.
That will certainly be better than the information I can offer now. But
what I have already given, plus the helpful contribution of some other
users should already amount to something.
>>> Is there a lot of censorship on this list too?
>>
>> That's an irrational comment.
>
> No, that's a question. I am new to the list and would like to know if it
> works efficiently or it is a wasteland of egos like most of the
> internet.
That's another irrational comment. I highly recommend you don't flee into
more such off-topic comments.
I recommend the same for you, sir. And I recommend you desist from
making personal recommendations to any user on this list.
> In my humble opinion the F25 installer is awkward. Can I say that?
If it makes you happy. Decide yourself.
It is not a question of happiness, but of clarity.
>> and your description so far sounds like PEBKAC. ;-)
>
> I might accept that as your own opinion if you knew the actual details,
> which I have not given yet,
Hence my earlier requests for details.
I already answered that.
> because I would have to reinstall yet again.
> But all you know is that I have tried manual installation and failed.
Seriously? You wrote:
| Also note that "manual" does not seem to be very manual after all.
| In previous more complicated installs it chooses put new partitions
| in seemingly arbitrary empty spaces like LVMs.
???
You are right there is a typo: add "to" after chooses: "chooses put"
should be "chooses to put". Is it clear now?
> Thus your contribution so far sounds like an ad hominem. ;-)
Talk is cheap.
Look, you chose to offend a new user you don't even know just because he
criticized some aspect of the product in question without having enough
evidence to convict. That does not give you the right to say that the
problem is me. This is a technical list for the purpose of collectively
improving a great product I chose to use. Your behavior diminishes the list.
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
9:23 a.m.
On Sun, 1 Jan 2017 21:49:35 +0100, Mayavimmer wrote:
> Just out of interest (and I could have spared myself this test)
You could start by sparing yourself this comment, sir.
You may want to revisit the subject you've chosen:
Can a second F25 be installed on the same machine?
What answer did you hope for? A definite "yes" or "no"? Or "it
depends".
Sure. I could have ignored the entire thread, but I've chosen to comment
on this thread, because to the best of my knowledge, the installer doesn't
care whether an existing installation of F25 is found. Failure reasons
may be completely independent of whether you're trying to install a second
F25 or F26 or RHEL or even another distribution that would not be happy about
what target partitions you point it at or what is left to work with. You
really need to narrow down the target environment and installation scenario.
, I've done
> another F25 installation (from Workstation x86_64 live image) to a machine
> that can boot F25, F24, F22 and some other distributions already. LVM, ext4
> and LUKS involved. I've asked for manual partitioning and haven't run into
> any issues.
Good for you. When I tried it, I ran into issues, which is why I am here
asking the list for their experiences. The information you are giving me
right here is no more precise and detailed than what I gave earlier.
Of course not. I haven't run into any issues. Not this time, and not the
many times I've done installations like that before with varying
configurations since the Second World War. The much more interesting case
is the failure case. Your failure case, and your installation scenario.
Hence the initial questions about what steps _you_ have tried.
How much free space did you have?
Irrelevant for this case. All that matters is what you have tried and
whether you've reused/reformatted existing partitions, whether you've
tried to allocate something from free space manually or automatically.
Details like that.
I mentioned somewhere that on one machine
_each_ install took 40 min. to finish the initial fsck! How long was
yours?
Not noticable. There is no huge storage fs available to this machine
directly, and accessing the local LUKS storage didn't involve any
annoying delay.
FWIW, I am also not in the know with regard to any forced fsck the current
installer version may run, and as much as you seem to like throwing in
irrelevant issues you consider "awkward", it isn't helpful in this case.
The fsck is an entirely different issue.
These are some of the problems I ran into. But you did not have
any issues. Good for you.
Which is not why I've pointed that out.
Nobody (me included) doubts that you're facing problems with whatever
you're trying to do with the installer and your machine's storage
configuration. Nevertheless, it's you who needs to find the culprit
or collect enough data and logs for installer developers to take a look
at. If you came to bugzilla with empty hands, it would not be any
different.
>>>> Is there a lot of censorship on this list too?
>>>
>>> That's an irrational comment.
>>
>> No, that's a question. I am new to the list and would like to know if it
>> works efficiently or it is a wasteland of egos like most of the
>> internet.
>
> That's another irrational comment. I highly recommend you don't flee into
> more such off-topic comments.
I recommend the same for you, sir.
My questions about $subject have not been off-topic.
And I recommend you desist from
making personal recommendations to any user on this list.
Can't do that, won't do that. You are new to this list, and still you
don't make your own experience on this list, but mention your bad
experience made in other places. It _is_ irrational to start rambling
about "censorship" and "wasteland of egos like most of the internet",
and it doesn't help you with your installation problem at all.
>> because I would have to reinstall yet again.
>> But all you know is that I have tried manual installation and failed.
>
> Seriously? You wrote:
>
> | Also note that "manual" does not seem to be very manual after all.
> | In previous more complicated installs it chooses put new partitions
> | in seemingly arbitrary empty spaces like LVMs.
>
> ???
>
You are right there is a typo: add "to" after chooses: "chooses put"
should be "chooses to put". Is it clear now?
No. The typo is unimportant. You've started with free space and have
asked the installer to creation something _automatically_? Or have you
tried to create a partition manually and whatever space the installer
allocated, wasn't a good working way?
>> Thus your contribution so far sounds like an ad hominem. ;-)
>
> Talk is cheap.
Look, you chose to offend a new user you don't even know just because he
criticized some aspect of the product in question without having enough
evidence to convict.
A false impression. Can't do anything about you feeling offended (and some
people are offended much too easily), but as I'm not a developer of this
installer, I don't care about the criticism. I'm only interested in the
topic, I'm free to post to the list, and if that troubles you, you may
ignore me.
5:02 p.m.
On 02/01/2017 16:23, Michael Schwendt wrote:
On Sun, 1 Jan 2017 21:49:35 +0100, Mayavimmer wrote:
>> Just out of interest (and I could have spared myself this test)
>
> You could start by sparing yourself this comment, sir.
You may want to revisit the subject you've chosen:
Can a second F25 be installed on the same machine?
What answer did you hope for? A definite "yes" or "no"? Or "it
depends".
Sure. I could have ignored the entire thread, but I've chosen to comment
on this thread, because to the best of my knowledge, the installer doesn't
care whether an existing installation of F25 is found. Failure reasons
may be completely independent of whether you're trying to install a second
F25 or F26 or RHEL or even another distribution that would not be happy about
what target partitions you point it at or what is left to work with. You
really need to narrow down the target environment and installation scenario.
> , I've done
>> another F25 installation (from Workstation x86_64 live image) to a machine
>> that can boot F25, F24, F22 and some other distributions already. LVM, ext4
>> and LUKS involved. I've asked for manual partitioning and haven't run
into
>> any issues.
>
> Good for you. When I tried it, I ran into issues, which is why I am here
> asking the list for their experiences. The information you are giving me
> right here is no more precise and detailed than what I gave earlier.
Of course not. I haven't run into any issues. Not this time, and not the
many times I've done installations like that before with varying
configurations since the Second World War. The much more interesting case
is the failure case. Your failure case, and your installation scenario.
Hence the initial questions about what steps _you_ have tried.
> How much free space did you have?
Irrelevant for this case. All that matters is what you have tried and
whether you've reused/reformatted existing partitions, whether you've
tried to allocate something from free space manually or automatically.
Details like that.
> I mentioned somewhere that on one machine
> _each_ install took 40 min. to finish the initial fsck! How long was
> yours?
Not noticable. There is no huge storage fs available to this machine
directly, and accessing the local LUKS storage didn't involve any
annoying delay.
FWIW, I am also not in the know with regard to any forced fsck the current
installer version may run, and as much as you seem to like throwing in
irrelevant issues you consider "awkward", it isn't helpful in this case.
The fsck is an entirely different issue.
> These are some of the problems I ran into. But you did not have
> any issues. Good for you.
Which is not why I've pointed that out.
Nobody (me included) doubts that you're facing problems with whatever
you're trying to do with the installer and your machine's storage
configuration. Nevertheless, it's you who needs to find the culprit
or collect enough data and logs for installer developers to take a look
at. If you came to bugzilla with empty hands, it would not be any
different.
>>>>> Is there a lot of censorship on this list too?
>>>>
>>>> That's an irrational comment.
>>>
>>> No, that's a question. I am new to the list and would like to know if it
>>> works efficiently or it is a wasteland of egos like most of the
>>> internet.
>>
>> That's another irrational comment. I highly recommend you don't flee
into
>> more such off-topic comments.
>
> I recommend the same for you, sir.
My questions about $subject have not been off-topic.
> And I recommend you desist from
> making personal recommendations to any user on this list.
Can't do that, won't do that. You are new to this list, and still you
don't make your own experience on this list, but mention your bad
experience made in other places. It _is_ irrational to start rambling
about "censorship" and "wasteland of egos like most of the
internet",
and it doesn't help you with your installation problem at all.
>>> because I would have to reinstall yet again.
>>> But all you know is that I have tried manual installation and failed.
>>
>> Seriously? You wrote:
>>
>> | Also note that "manual" does not seem to be very manual after all.
>> | In previous more complicated installs it chooses put new partitions
>> | in seemingly arbitrary empty spaces like LVMs.
>>
>> ???
>>
>
> You are right there is a typo: add "to" after chooses: "chooses
put"
> should be "chooses to put". Is it clear now?
No. The typo is unimportant. You've started with free space and have
asked the installer to creation something _automatically_? Or have you
tried to create a partition manually and whatever space the installer
allocated, wasn't a good working way?
>>> Thus your contribution so far sounds like an ad hominem. ;-)
>>
>> Talk is cheap.
>
> Look, you chose to offend a new user you don't even know just because he
> criticized some aspect of the product in question without having enough
> evidence to convict.
A false impression. Can't do anything about you feeling offended (and some
people are offended much too easily), but as I'm not a developer of this
installer, I don't care about the criticism. I'm only interested in the
topic, I'm free to post to the list, and if that troubles you, you may
ignore me.
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
This continues to be very wrong and I cannot continue to answer in
detail. You have been pestering me with your ego ever since I dared to
mention there is something wrong with the installer, which now has been
demonstrated. I am here on this technical list to solve problems for my
customers and you are here to play games. Please cease and desist from
making personal remarks about me or I will complain to the moderator.
7:33 a.m.
On Tue, 3 Jan 2017 00:02:42 +0100, Mayavimmer wrote:
demonstrated. I am here on this technical list to solve problems for
my
customers and you are here to play games. Please cease and desist from
making personal remarks about me or I will complain to the moderator.
That is another irrational comment and doesn't threaten me. Complain to
the moderator, if it makes you happy.
It would be more productive to gather some details about the installation
scenario and figure out what steps are necessary to reproduce a problem. What
I've pointed out in the previous mail has not been wrong. I will continue to
raise questions and add comments as long as this thread remains public, but
that doesn't mean I reply to every email. Obviously.
6:18 a.m.
On 03/01/2017 14:33, Michael Schwendt wrote:
On Tue, 3 Jan 2017 00:02:42 +0100, Mayavimmer wrote:
> demonstrated. I am here on this technical list to solve problems for my
> customers and you are here to play games. Please cease and desist from
> making personal remarks about me or I will complain to the moderator.
That is another irrational comment and doesn't threaten me. Complain to
the moderator, if it makes you happy.
It would be more productive to gather some details about the installation
scenario and figure out what steps are necessary to reproduce a problem. What
I've pointed out in the previous mail has not been wrong. I will continue to
raise questions and add comments as long as this thread remains public, but
that doesn't mean I reply to every email. Obviously.
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
You can do whatever you want. Except making personal comments about me.
Like you just did again. Next one I will complain to the moderator.
10:23 a.m.
On Sun, Jan 01, 2017 at 10:10:55AM +0100, Mayavimmer wrote:
I tried to do an identical second install on the same machine, but
the
installer Anaconda gives an error about being unable to set a root
partition.
This isn't _forbidden_, but it also isn't something we test offically —
and in fact I'm not sure if anyone has actually tested it ever. So,
while I don't see why it couldn't be made to work, I also am not
surprised to hear it doesn't.
Can I ask what you are aiming to accomplish with this? There might be a
better way — virtualization or containers, perhaps.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
11:10 a.m.
On 01/01/2017 17:23, Matthew Miller wrote:
On Sun, Jan 01, 2017 at 10:10:55AM +0100, Mayavimmer wrote:
> I tried to do an identical second install on the same machine, but the
> installer Anaconda gives an error about being unable to set a root
> partition.
This isn't _forbidden_, but it also isn't something we test offically —
and in fact I'm not sure if anyone has actually tested it ever. So,
while I don't see why it couldn't be made to work, I also am not
surprised to hear it doesn't.
I tested about 10 F25 installs yesterday, plus 2 Rosalinux R8 and 2 Mint
18, on an old server with 2GB RAM and a new laptop with 12GB RAM. All 3
OS' had to deal with previous installed versions of the same, except a
couple of cases where I restarted from an empty disk. Only the F25's
gave me problems on both boxes and in different independent ways.
An interesting behavior, as I explained a few posts ago, happens when
you install a second or a third F25, all in the standard LVM device
configuration. They seem to work ok, though there no indication on the
grub menu which one you are running. The problem appears when you
install a new F25 with the /boot partition _inside_ the LVM container,
which seems to work. Except, upon reboot the others are gone!
Also I tried my preferred configuration: Btrfs RAID1 over LVM, which
should give the best of both worlds: awesome scrub autorepair and proper
pooling of same disk spare partitions! The installer barks. It seems to
think that If I want to use Btrfs as a raid fs I also have to use it as
a volume manager. According the the Fedora info mentioned a few posts
back this should only cost a slight, not consistent as somebody said,
performance hit. Is is true that the installer cannot put a Btrfs fs on
a LVM partition? I could have missed something.
Can I ask what you are aiming to accomplish with this? There might be a
better way — virtualization or containers, perhaps.
I have a remote customer with an old server with a Rosalinux and Mes5 on
top of a 2x2TB ext4 over raid. I cannot easily access the location and
need to do most maintenance remotely. They could only be trusted to
reboot the machine at most, or perhaps select a different boot device
from the old BIOS. The old OS is failing but cannot suffer downtime. I
was hoping to install two different F25's in the small 20GB partition
left unraided on the second disk: /dev/sdb17. Reboot to F25. Check
everything. Then do the rest of the work slowly, carefully and
incrementally from remote. Slowly copying files, enlarging partitions
and finally, online raiding the root partition to the other disk, and
finally attaining full redundancy. With at most a single remote reboot
or possible none, and no downtime. There is more, but this already can
only be done _only_, I believe, with Btrfs (ZFS) RAID1 over LVM volumes.
It's not crazy, I have done similar things in the past. The customer
never complained.
Oh, I would have preferred a more stable environment, like RedHat or
CentOS, but I need a recent kernel and btrfs-tools to do this.
Going for coffee, back in an hour.
11:58 a.m.
On Sun, Jan 1, 2017 at 10:10 AM, Mayavimmer <mayavimmer(a)gmail.com> wrote:
On 01/01/2017 17:23, Matthew Miller wrote:
> On Sun, Jan 01, 2017 at 10:10:55AM +0100, Mayavimmer wrote:
>> I tried to do an identical second install on the same machine, but the
>> installer Anaconda gives an error about being unable to set a root
>> partition.
>
> This isn't _forbidden_, but it also isn't something we test offically —
> and in fact I'm not sure if anyone has actually tested it ever. So,
> while I don't see why it couldn't be made to work, I also am not
> surprised to hear it doesn't.
I tested about 10 F25 installs yesterday, plus 2 Rosalinux R8 and 2 Mint
18, on an old server with 2GB RAM and a new laptop with 12GB RAM. All 3
OS' had to deal with previous installed versions of the same, except a
couple of cases where I restarted from an empty disk. Only the F25's
gave me problems on both boxes and in different independent ways.
An interesting behavior, as I explained a few posts ago, happens when
you install a second or a third F25, all in the standard LVM device
configuration. They seem to work ok, though there no indication on the
grub menu which one you are running. The problem appears when you
install a new F25 with the /boot partition _inside_ the LVM container,
which seems to work. Except, upon reboot the others are gone!
A possible explanation for this, is this old bug. The installer
doesn't make all LV's active, therefore grub2-mkconfig won't find
them, and won't create boot entries for them.
https://bugzilla.redhat.com/show_bug.cgi?id=825236
However annoying that is though, about as suboptimal is the way
grub2-mkconfig makes generic boot entries for other OS's rather than
just pointing to their "native" grub.cfg using the configfile command.
This forwarding command is a vastly better workflow than the grub.cfg
of Distro X becoming responsible for Distro Y. When Distro Y gets a
kernel update, only Distro Y's grub.cfg is updated; so if you're using
a configfile forwarding workflow, you'll see that new kernel
automatically whereas if you depend on GRUB as-designed (including as
it works in Fedora), you're totally stuffed. Distro X's grub.cfg won't
reflect the change until you run grub2-mkconfig.
Also I tried my preferred configuration: Btrfs RAID1 over LVM, which
should give the best of both worlds: awesome scrub autorepair and proper
pooling of same disk spare partitions! The installer barks. It seems to
think that If I want to use Btrfs as a raid fs I also have to use it as
a volume manager. According the the Fedora info mentioned a few posts
back this should only cost a slight, not consistent as somebody said,
performance hit. Is is true that the installer cannot put a Btrfs fs on
a LVM partition? I could have missed something.
The Fedora installer will not put Btrfs on either LVM or md RAID.
You could use blivet-gui to get the layout you want in advance, and
the installer should recognize all of those pieces (blivet-gui and
anaconda both leverage python-blivet and libblockdev to recognize and
create storage stacks) and let you set them up as mount points. For a
pre-created Btrfs, the installer will force the creation of a new
Btrfs subvolume for the "/" mount point; otherwise it will let you
reuse existing subvolumes and file systems. Blivet-gui is supposedly
going to be integrated into the Fedora 26 installer as an advanced
partitioning option.
The installer is supposed to enforce /boot on a standard partition or
md RAID; but not allowing it to be in LVM or Btrfs.
>
> Can I ask what you are aiming to accomplish with this? There might be a
> better way — virtualization or containers, perhaps.
>
I have a remote customer with an old server with a Rosalinux and Mes5 on
top of a 2x2TB ext4 over raid. I cannot easily access the location and
need to do most maintenance remotely. They could only be trusted to
reboot the machine at most, or perhaps select a different boot device
from the old BIOS. The old OS is failing but cannot suffer downtime. I
was hoping to install two different F25's in the small 20GB partition
left unraided on the second disk: /dev/sdb17. Reboot to F25. Check
everything. Then do the rest of the work slowly, carefully and
incrementally from remote. Slowly copying files, enlarging partitions
and finally, online raiding the root partition to the other disk, and
finally attaining full redundancy. With at most a single remote reboot
or possible none, and no downtime. There is more, but this already can
only be done _only_, I believe, with Btrfs (ZFS) RAID1 over LVM volumes.
If the OS itself is failing, you have no choice but to accept a moment
of downtime to reboot new binaries. If it were just a case of a hard
drive dying, migration to replacement hardware can be done with either
Btrfs or LVM, independently. For LVM setups it's pvcreate > vgextend >
pvmove > vgreduce. For Btrfs it's either 'btrfs replace' or more
conventionally with 'btrfs dev add' followed by 'btrfs dev remove' -
the former requires a replacement at least as large as the original
device, where the add/remove method will work if the replacement is
smaller. The fs is resized automatically in all cases.
--
Chris Murphy
3:18 p.m.
On 01/01/2017 18:58, Chris Murphy wrote:
On Sun, Jan 1, 2017 at 10:10 AM, Mayavimmer
<mayavimmer(a)gmail.com> wrote:
> On 01/01/2017 17:23, Matthew Miller wrote:
>> On Sun, Jan 01, 2017 at 10:10:55AM +0100, Mayavimmer wrote:
>>> I tried to do an identical second install on the same machine, but the
>>> installer Anaconda gives an error about being unable to set a root
>>> partition.
>>
>> This isn't _forbidden_, but it also isn't something we test offically —
>> and in fact I'm not sure if anyone has actually tested it ever. So,
>> while I don't see why it couldn't be made to work, I also am not
>> surprised to hear it doesn't.
>
> I tested about 10 F25 installs yesterday, plus 2 Rosalinux R8 and 2 Mint
> 18, on an old server with 2GB RAM and a new laptop with 12GB RAM. All 3
> OS' had to deal with previous installed versions of the same, except a
> couple of cases where I restarted from an empty disk. Only the F25's
> gave me problems on both boxes and in different independent ways.
>
> An interesting behavior, as I explained a few posts ago, happens when
> you install a second or a third F25, all in the standard LVM device
> configuration. They seem to work ok, though there no indication on the
> grub menu which one you are running. The problem appears when you
> install a new F25 with the /boot partition _inside_ the LVM container,
> which seems to work. Except, upon reboot the others are gone!
A possible explanation for this, is this old bug. The installer
doesn't make all LV's active, therefore grub2-mkconfig won't find
them, and won't create boot entries for them.
https://bugzilla.redhat.com/show_bug.cgi?id=825236
My new hero, Chris! I think you just found one of the gremlins that made
my previous installs disappear! I knew I didn't just dream that up!
Ok, I'll study this and see if I can come up with a workaround. I see
there are some good reasons why this has not been solved long ago.
However annoying that is though, about as suboptimal is the way
grub2-mkconfig makes generic boot entries for other OS's rather than
just pointing to their "native" grub.cfg using the configfile command.
This forwarding command is a vastly better workflow than the grub.cfg
of Distro X becoming responsible for Distro Y. When Distro Y gets a
kernel update, only Distro Y's grub.cfg is updated; so if you're using
a configfile forwarding workflow, you'll see that new kernel
automatically whereas if you depend on GRUB as-designed (including as
it works in Fedora), you're totally stuffed. Distro X's grub.cfg won't
reflect the change until you run grub2-mkconfig.
Yes! That's the other one I kind of suspected, and always bothered me in
the back of my mind. I always thought you should be able to at least
provide a prefix to a config file, perhaps based on the hostname, and
then rebuild grub.cfg from that. Great. Progress at last.
> Also I tried my preferred configuration: Btrfs RAID1 over LVM, which
> should give the best of both worlds: awesome scrub autorepair and proper
> pooling of same disk spare partitions! The installer barks. It seems to
> think that If I want to use Btrfs as a raid fs I also have to use it as
> a volume manager. According the the Fedora info mentioned a few posts
> back this should only cost a slight, not consistent as somebody said,
> performance hit. Is is true that the installer cannot put a Btrfs fs on
> a LVM partition? I could have missed something.
The Fedora installer will not put Btrfs on either LVM or md RAID.
Another bullseye! Had I known this I would have saved time! Maybe the
installer should add a line of text alerting the user to that effect,
for the time being. If you advertize that you can install LVM, Vtrfs, Md
and other wonderful things, you should at least, IN THE INSTALLER, warn
the user. Great, thanks.
You could use blivet-gui to get the layout you want in advance, and
the installer should recognize all of those pieces (blivet-gui and
anaconda both leverage python-blivet and libblockdev to recognize and
create storage stacks) and let you set them up as mount points. For a
pre-created Btrfs, the installer will force the creation of a new
Btrfs subvolume for the "/" mount point; otherwise it will let you
reuse existing subvolumes and file systems. Blivet-gui is supposedly
going to be integrated into the Fedora 26 installer as an advanced
partitioning option.
Good to know that it's in the works!
The installer is supposed to enforce /boot on a standard partition or
md RAID; but not allowing it to be in LVM or Btrfs.
It _did_ let me install /boot in LVM though. Strange.
>
>>
>> Can I ask what you are aiming to accomplish with this? There might be a
>> better way — virtualization or containers, perhaps.
>>
>
> I have a remote customer with an old server with a Rosalinux and Mes5 on
> top of a 2x2TB ext4 over raid. I cannot easily access the location and
> need to do most maintenance remotely. They could only be trusted to
> reboot the machine at most, or perhaps select a different boot device
> from the old BIOS. The old OS is failing but cannot suffer downtime. I
> was hoping to install two different F25's in the small 20GB partition
> left unraided on the second disk: /dev/sdb17. Reboot to F25. Check
> everything. Then do the rest of the work slowly, carefully and
> incrementally from remote. Slowly copying files, enlarging partitions
> and finally, online raiding the root partition to the other disk, and
> finally attaining full redundancy. With at most a single remote reboot
> or possible none, and no downtime. There is more, but this already can
> only be done _only_, I believe, with Btrfs (ZFS) RAID1 over LVM volumes.
If the OS itself is failing, you have no choice but to accept a moment
of downtime to reboot new binaries. If it were just a case of a hard
drive dying, migration to replacement hardware can be done with either
Btrfs or LVM, independently. For LVM setups it's pvcreate > vgextend >
pvmove > vgreduce. For Btrfs it's either 'btrfs replace' or more
conventionally with 'btrfs dev add' followed by 'btrfs dev remove' -
the former requires a replacement at least as large as the original
device, where the add/remove method will work if the replacement is
smaller. The fs is resized automatically in all cases.
Yes, the OS is obsolete and I can't really install, upgrade or touch
anything for fear of not ever being able to roll back. The hardware
probably has puffed capacitors due to having been run more than a year
in a factory next to huge spiking electrical motors without a UPS!
Against my advice. I gave them mine out of pity.
7:31 p.m.
On Sun, Jan 1, 2017 at 2:18 PM, Mayavimmer <mayavimmer(a)gmail.com> wrote:
On 01/01/2017 18:58, Chris Murphy wrote:
> A possible explanation for this, is this old bug. The installer
> doesn't make all LV's active, therefore grub2-mkconfig won't find
> them, and won't create boot entries for them.
> https://bugzilla.redhat.com/show_bug.cgi?id=825236
My new hero, Chris! I think you just found one of the gremlins that made
my previous installs disappear! I knew I didn't just dream that up!
Ok, I'll study this and see if I can come up with a workaround. I see
there are some good reasons why this has not been solved long ago.
That's charitable. I see it as one of the very bad cases of OSS, it's
all kinds of finger pointing blame by upstreams, miscooperation at the
user expense. And it's replicated at a different layer by distros who
don't care about standardizing this basic system booting problem, so
there's no interoperability.
Why this is not a bigger problem is because installing two Fedoras is
rare. So there aren't many complaints. Next, other distros don't use
LVM by default, so their installations are found by grub2-mkconfig.
It's only Fedora/RedHat default installations that get hit with this
bug.
>
> However annoying that is though, about as suboptimal is the w
> grub2-mkconfig makes generic boot entries for other OS's rather than
> just pointing to their "native" grub.cfg using the configfile command.
> This forwarding command is a vastly better workflow than the grub.cfg
> of Distro X becoming responsible for Distro Y. When Distro Y gets a
> kernel update, only Distro Y's grub.cfg is updated; so if you're using
> a configfile forwarding workflow, you'll see that new kernel
> automatically whereas if you depend on GRUB as-designed (including as
> it works in Fedora), you're totally stuffed. Distro X's grub.cfg won't
> reflect the change until you run grub2-mkconfig.
Yes! That's the other one I kind of suspected, and always bothered me in
the back of my mind. I always thought you should be able to at least
provide a prefix to a config file, perhaps based on the hostname, and
then rebuild grub.cfg from that. Great. Progress at last.
The distros variably apply hundreds of patches on top of upstream
GRUB. While they aren't literal forks, they are sufficiently different
and mutually incompatible, that they're fast becoming different OS's
that just so happen to share a kernel.
>
>
>
>> Also I tried my preferred configuration: Btrfs RAID1 over LVM, which
>> should give the best of both worlds: awesome scrub autorepair and proper
>> pooling of same disk spare partitions! The installer barks. It seems to
>> think that If I want to use Btrfs as a raid fs I also have to use it as
>> a volume manager. According the the Fedora info mentioned a few posts
>> back this should only cost a slight, not consistent as somebody said,
>> performance hit. Is is true that the installer cannot put a Btrfs fs on
>> a LVM partition? I could have missed something.
>
> The Fedora installer will not put Btrfs on either LVM or md RAID.
Another bullseye! Had I known this I would have saved time! Maybe the
installer should add a line of text alerting the user to that effect,
for the time being. If you advertize that you can install LVM, Vtrfs, Md
and other wonderful things, you should at least, IN THE INSTALLER, warn
the user. Great, thanks.
*shrug* well they're mutually exclusive devices, the installer simply
won't let you pick them in combination.
If there were a warning for every possible unsupported layout, the
whole installer would be putting up dozens of placards everytime the
user clicked on something. Plus, warning dialogs in an installer are
very heavy weight: difficult to get the right wording to convey the
problem and work around, they need translations which have different
(earlier) deadlines than most everything else, are hard to maintain.
It's just a huge resource suck.
>
> You could use blivet-gui to get the layout you want in advance, and
> the installer should recognize all of those pieces (blivet-gui and
> anaconda both leverage python-blivet and libblockdev to recognize and
> create storage stacks) and let you set them up as mount points. For a
> pre-created Btrfs, the installer will force the creation of a new
> Btrfs subvolume for the "/" mount point; otherwise it will let you
> reuse existing subvolumes and file systems. Blivet-gui is supposedly
> going to be integrated into the Fedora 26 installer as an advanced
> partitioning option.
Good to know that it's in the works!
>
> The installer is supposed to enforce /boot on a standard partition or
> md RAID; but not allowing it to be in LVM or Btrfs.
It _did_ let me install /boot in LVM though. Strange.
Some versions permit it. It comes and goes depending on what bugs pop
up during release testing. Ostensibly boot on LVM is supportable by
GRUB2, kernel, dracut, systemd, and the software updaters.
--
Chris Murphy
11:39 a.m.
On Sun, 1 Jan 2017 11:23:27 -0500, Matthew Miller wrote:
On Sun, Jan 01, 2017 at 10:10:55AM +0100, Mayavimmer wrote:
> I tried to do an identical second install on the same machine, but the
> installer Anaconda gives an error about being unable to set a root
> partition.
This isn't _forbidden_, but it also isn't something we test offically —
and in fact I'm not sure if anyone has actually tested it ever.
I do manual installs like that regularly. Hence the earlier requests
for details.
The original post doesn't give enough details. I could have answered
"yes" to the $subject, and yet there might be installation scenarios
where the installer fails. More details needed!
So, while I don't see why it couldn't be made to work, I also
am not
surprised to hear it doesn't.
It's the opposite here. I'm surprised manual partitioning would fail. If
you point the installer at usable partitions for / and /boot, why would it
fail?
Of course, some users try to set up dubious/questionable environments
to begin with, such as /boot shared by multiple distributions and things
like that.
Personally, I only share /home and a couple of optional mount points.
11:45 a.m.
On Sun, Jan 01, 2017 at 06:39:02PM +0100, Michael Schwendt wrote:
> > I tried to do an identical second install on the same
machine, but the
> > installer Anaconda gives an error about being unable to set a root
> > partition.
> This isn't _forbidden_, but it also isn't something we test offically —
> and in fact I'm not sure if anyone has actually tested it ever.
I do manual installs like that regularly. Hence the earlier requests
for details.
Manual installs with multiple of the same version? I stand corrected,
then. :)
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
2:51 p.m.
On 01/01/2017 18:45, Matthew Miller wrote:
On Sun, Jan 01, 2017 at 06:39:02PM +0100, Michael Schwendt wrote:
>>> I tried to do an identical second install on the same machine, but the
>>> installer Anaconda gives an error about being unable to set a root
>>> partition.
>> This isn't _forbidden_, but it also isn't something we test offically —
>> and in fact I'm not sure if anyone has actually tested it ever.
> I do manual installs like that regularly. Hence the earlier requests
> for details.
Manual installs with multiple of the same version? I stand corrected,
then. :)
Ok, thanks, so I take it that it can be done. I'll try again then, with
step by step details.
2:01 p.m.
On 01/01/2017 18:39, Michael Schwendt wrote:
On Sun, 1 Jan 2017 11:23:27 -0500, Matthew Miller wrote:
> On Sun, Jan 01, 2017 at 10:10:55AM +0100, Mayavimmer wrote:
>> I tried to do an identical second install on the same machine, but the
>> installer Anaconda gives an error about being unable to set a root
>> partition.
>
> This isn't _forbidden_, but it also isn't something we test offically —
> and in fact I'm not sure if anyone has actually tested it ever.
I do manual installs like that regularly. Hence the earlier requests
for details.
The original post doesn't give enough details. I could have answered
"yes" to the $subject, and yet there might be installation scenarios
where the installer fails. More details needed!
As soon as I can. I already gave some details in the other sister
threads yesterday.
> So, while I don't see why it couldn't be made to work, I also am not
> surprised to hear it doesn't.
It's the opposite here. I'm surprised manual partitioning would fail. If
you point the installer at usable partitions for / and /boot, why would it
fail?
Same exact sentiment, sir. It's ok if the poor little AI in the
installer can't hack complexity, but don't mess with my sacrosanct right
to manually override everything.
Of course, some users try to set up dubious/questionable environments
to begin with, such as /boot shared by multiple distributions and things
like that.
Only legit hacking. Check.
Personally, I only share /home and a couple of optional mount points.
I don't even do that, unless at gunpoint (which was the case recently).
I prefer separate homes with shared data partitions.
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
2:45 p.m.
On 01/01/2017 01:01 PM, Mayavimmer wrote:
On 01/01/2017 18:39, Michael Schwendt wrote:
> On Sun, 1 Jan 2017 11:23:27 -0500, Matthew Miller wrote:
>
>> On Sun, Jan 01, 2017 at 10:10:55AM +0100, Mayavimmer wrote:
>>> I tried to do an identical second install on the same machine, but the
>>> installer Anaconda gives an error about being unable to set a root
>>> partition.
>> This isn't _forbidden_, but it also isn't something we test offically —
>> and in fact I'm not sure if anyone has actually tested it ever.
> I do manual installs like that regularly. Hence the earlier requests
> for details.
>
> The original post doesn't give enough details. I could have answered
> "yes" to the $subject, and yet there might be installation scenarios
> where the installer fails. More details needed!
As soon as I can. I already gave some details in the other sister
threads yesterday.
>> So, while I don't see why it couldn't be made to work, I also am not
>> surprised to hear it doesn't.
> It's the opposite here. I'm surprised manual partitioning would fail. If
> you point the installer at usable partitions for / and /boot, why would it
> fail?
Same exact sentiment, sir. It's ok if the poor little AI in the
installer can't hack complexity, but don't mess with my sacrosanct right
to manually override everything.
> Of course, some users try to set up dubious/questionable environments
> to begin with, such as /boot shared by multiple distributions and things
> like that.
Only legit hacking. Check.
> Personally, I only share /home and a couple of optional mount points.
I don't even do that, unless at gunpoint (which was the case recently).
I prefer separate homes with shared data partitions.
Without having done it myself,
I suspect that for the 2nd installation,
grub will
make write into /boot/grub2/grub.cfg file an entry that is similar to
the entry it makes
when it detects a windows bootable partition.
I am not certain how many bootable partitions per disk grub2 supports.
3:28 p.m.
On 01/01/2017 21:45, JD wrote:
On 01/01/2017 01:01 PM, Mayavimmer wrote:
> On 01/01/2017 18:39, Michael Schwendt wrote:
>> On Sun, 1 Jan 2017 11:23:27 -0500, Matthew Miller wrote:
>>
>>> On Sun, Jan 01, 2017 at 10:10:55AM +0100, Mayavimmer wrote:
>>>> I tried to do an identical second install on the same machine, but the
>>>> installer Anaconda gives an error about being unable to set a root
>>>> partition.
>>> This isn't _forbidden_, but it also isn't something we test offically
—
>>> and in fact I'm not sure if anyone has actually tested it ever.
>> I do manual installs like that regularly. Hence the earlier requests
>> for details.
>>
>> The original post doesn't give enough details. I could have answered
>> "yes" to the $subject, and yet there might be installation scenarios
>> where the installer fails. More details needed!
> As soon as I can. I already gave some details in the other sister
> threads yesterday.
>
>>> So, while I don't see why it couldn't be made to work, I also am not
>>> surprised to hear it doesn't.
>> It's the opposite here. I'm surprised manual partitioning would fail. If
>> you point the installer at usable partitions for / and /boot, why
>> would it
>> fail?
> Same exact sentiment, sir. It's ok if the poor little AI in the
> installer can't hack complexity, but don't mess with my sacrosanct right
> to manually override everything.
>
>> Of course, some users try to set up dubious/questionable environments
>> to begin with, such as /boot shared by multiple distributions and things
>> like that.
> Only legit hacking. Check.
>
>> Personally, I only share /home and a couple of optional mount points.
> I don't even do that, unless at gunpoint (which was the case recently).
> I prefer separate homes with shared data partitions.
Without having done it myself, I suspect that for the 2nd installation,
grub will
make write into /boot/grub2/grub.cfg file an entry that is similar to
the entry it makes
when it detects a windows bootable partition.
I am not certain how many bootable partitions per disk grub2 supports.
Yes, Chris mentioned similar problems. I don't have a solid enough grasp
of the interaction between grub and uefi/bios conventions, but I suspect
something similar.
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
7:10 p.m.
On Sun, Jan 1, 2017 at 1:45 PM, JD <jd1008(a)gmail.com> wrote:
Without having done it myself, I suspect that for the 2nd installation, grub
will
make write into /boot/grub2/grub.cfg file an entry that is similar to the
entry it makes
when it detects a windows bootable partition.
On BIOS firmware computers, yes. And it's the 2nd installation GRUB
that "owns" the drive. It is this grub.cfg whose generic entries
should be replaced using configfile to point to the 1st installations
grub.cfg. This is much more maintainable and compatible.
On UEFI firmware, there is only one fedora bootloader and grub.cfg, so
the 2nd installation will overwrite the 1st. I would modify the
installation so that each has its own grub.cfg found at /boot/grub2
just like it's a BIOS setup (and is supported by upstream GRUB as they
do it this way by default, I'm baffled why Fedora does this
differently). And then create a minimalist grub.cfg on the efi system
partition that points to the two installation specific grub.cfgs by
using configfile command.
I am not certain how many bootable partitions per disk grub2
supports.
A lot. It's limited by GRUB's ability to ennumerate, i.e. hdXmsdosY,
where the practical limit of Y is maybe something like 128. It
supports loading the kernel+initramfs on almost everything: md raid5
degraded; LVM, primary or extended MBR partitions, LUKs encrypted
volumes, Btrfs, ZFS, it's quite impressive what it can do. What
--
Chris Murphy
7:31 p.m.
On 02/01/2017 02:10, Chris Murphy wrote:
On Sun, Jan 1, 2017 at 1:45 PM, JD <jd1008(a)gmail.com> wrote:
>
> Without having done it myself, I suspect that for the 2nd installation, grub
> will
> make write into /boot/grub2/grub.cfg file an entry that is similar to the
> entry it makes
> when it detects a windows bootable partition.
On BIOS firmware computers, yes. And it's the 2nd installation GRUB
that "owns" the drive. It is this grub.cfg whose generic entries
should be replaced using configfile to point to the 1st installations
grub.cfg. This is much more maintainable and compatible.
On UEFI firmware, there is only one fedora bootloader and grub.cfg, so
the 2nd installation will overwrite the 1st. I would modify the
installation so that each has its own grub.cfg found at /boot/grub2
just like it's a BIOS setup (and is supported by upstream GRUB as they
do it this way by default, I'm baffled why Fedora does this
differently). And then create a minimalist grub.cfg on the efi system
partition that points to the two installation specific grub.cfgs by
using configfile command.
Eminently reasonable.
And while we are waiting for that, I would ask: why the UEFI overwrite
pain? Can we add these 3 lines of pseudocode?
if thisBox.alreadyHas( anotherFedora ) and isUEFI:
showDialog("Sorry, cannot currently add a second Fedora")
exit(0)
> I am not certain how many bootable partitions per disk grub2 supports.
A lot. It's limited by GRUB's ability to ennumerate, i.e. hdXmsdosY,
where the practical limit of Y is maybe something like 128. It
supports loading the kernel+initramfs on almost everything: md raid5
degraded; LVM, primary or extended MBR partitions, LUKs encrypted
volumes, Btrfs, ZFS, it's quite impressive what it can do. What
7:55 p.m.
On Sun, Jan 1, 2017 at 6:31 PM, Mayavimmer <mayavimmer(a)gmail.com> wrote:
On 02/01/2017 02:10, Chris Murphy wrote:
> On Sun, Jan 1, 2017 at 1:45 PM, JD <jd1008(a)gmail.com> wrote:
>>
>> Without having done it myself, I suspect that for the 2nd installation, grub
>> will
>> make write into /boot/grub2/grub.cfg file an entry that is similar to the
>> entry it makes
>> when it detects a windows bootable partition.
>
> On BIOS firmware computers, yes. And it's the 2nd installation GRUB
> that "owns" the drive. It is this grub.cfg whose generic entries
> should be replaced using configfile to point to the 1st installations
> grub.cfg. This is much more maintainable and compatible.
>
> On UEFI firmware, there is only one fedora bootloader and grub.cfg, so
> the 2nd installation will overwrite the 1st. I would modify the
> installation so that each has its own grub.cfg found at /boot/grub2
> just like it's a BIOS setup (and is supported by upstream GRUB as they
> do it this way by default, I'm baffled why Fedora does this
> differently). And then create a minimalist grub.cfg on the efi system
> partition that points to the two installation specific grub.cfgs by
> using configfile command.
Eminently reasonable.
And while we are waiting for that, I would ask: why the UEFI overwrite
pain? Can we add these 3 lines of pseudocode?
if thisBox.alreadyHas( anotherFedora ) and isUEFI:
showDialog("Sorry, cannot currently add a second Fedora")
exit(0)
Because that code by itself would prevent replacing an existing Fedora
(of any release version). So now you need a dialog that tells the user
they need to first remove the existing Fedora to install a new Fedora.
And while that is arguably a less trouble UX, it thwarts the dual
Fedora user case where the user has the ability to hack up the
bootloader but doesn't want to screw around with the gory details of
OS installation.
This use case isn't that difficult to support if there were other
changes made to simplify installation and bootloading in general,
while also standardizing bootloading. macOS and Windows manage to do
this today and their installers are completely brain dead stupid. So
it doesn't take a complicated installer to do the things people *need*
to do. It takes a complicated installer to do the things people want
to do but could be met some other way but they don't want to do it
that way because it's not their way and get all pissy if the installer
isn't justifying their way with direct support. I still advocate
ripping out all of the custom partitioning UI... and I'm not a fan of
making the installer ass tons more complicated by inserting blivet-gui
into it. Just run that tool from outside the installer if desired,
cluttering up the installer just makes it more unwieldy...
When billion dollar companies have rock solid installers that only
support the 80% use case with essentially zero bugs and user
complaints about lack of function; compared to installers that try to
disproportionately appease the other 20% use cases with constant
regressions, it makes me think of project failure.
--
Chris Murphy
5:15 a.m.
On 02/01/2017 02:55, Chris Murphy wrote:
On Sun, Jan 1, 2017 at 6:31 PM, Mayavimmer
<mayavimmer(a)gmail.com> wrote:
> On 02/01/2017 02:10, Chris Murphy wrote:
>> On Sun, Jan 1, 2017 at 1:45 PM, JD <jd1008(a)gmail.com> wrote:
>>>
>>> Without having done it myself, I suspect that for the 2nd installation, grub
>>> will
>>> make write into /boot/grub2/grub.cfg file an entry that is similar to the
>>> entry it makes
>>> when it detects a windows bootable partition.
>>
>> On BIOS firmware computers, yes. And it's the 2nd installation GRUB
>> that "owns" the drive. It is this grub.cfg whose generic entries
>> should be replaced using configfile to point to the 1st installations
>> grub.cfg. This is much more maintainable and compatible.
>>
>> On UEFI firmware, there is only one fedora bootloader and grub.cfg, so
>> the 2nd installation will overwrite the 1st. I would modify the
>> installation so that each has its own grub.cfg found at /boot/grub2
>> just like it's a BIOS setup (and is supported by upstream GRUB as they
>> do it this way by default, I'm baffled why Fedora does this
>> differently). And then create a minimalist grub.cfg on the efi system
>> partition that points to the two installation specific grub.cfgs by
>> using configfile command.
>
> Eminently reasonable.
>
> And while we are waiting for that, I would ask: why the UEFI overwrite
> pain? Can we add these 3 lines of pseudocode?
>
> if thisBox.alreadyHas( anotherFedora ) and isUEFI:
> showDialog("Sorry, cannot currently add a second Fedora")
> exit(0)
Because that code by itself would prevent replacing an existing Fedora
(of any release version).
Ok, right. Then we could get the best of both worlds, in keeping with
the Hippocratic Oath to at least do no harm, by dropping the exit() in
this two line pseudocode:
if thisBox.alreadyHas( anotherFedora ) and isUEFI:
showDialog("WARNING: you already have a Fedora installation\n"
"If you continue it will be OVERWRITTEN!")
...or "will be rendered inaccessible", until your suggestions not
implemented or some progress is made. Right now people who have not read
this thread risk losing their data.
So now you need a dialog that tells the user
they need to first remove the existing Fedora to install a new
Fedora.
And while that is arguably a less trouble UX, it thwarts the dual
Fedora user case where the user has the ability to hack up the
bootloader but doesn't want to screw around with the gory details of
OS installation.
Ok, I would not mind going outside the installer to get multiple Fedoras
on my machine. Perhaps we should set up a temporary very informal guide
on how to do that.
Is there a wiki like service associated with this list where we could
gather the wisdom accumulated so far? Tests done, machines used,
configurations, workarounds, repeatable scenarios, faqs, howtos, hearsay?
This use case isn't that difficult to support if there were other
changes made to simplify installation and bootloading in general,
while also standardizing bootloading. macOS and Windows manage to do
this today and their installers are completely brain dead stupid.
It's easier for them because they control their equivalent upstream
grubs and everything else. Besides the money.
So
it doesn't take a complicated installer to do the things people
*need*
to do. It takes a complicated installer to do the things people want
to do but could be met some other way but they don't want to do it
that way because it's not their way and get all pissy if the installer
isn't justifying their way with direct support. I still advocate
ripping out all of the custom partitioning UI... and I'm not a fan of
making the installer ass tons more complicated by inserting blivet-gui
into it. Just run that tool from outside the installer if desired,
cluttering up the installer just makes it more unwieldy...
I am ok with that for the kind of work I do, but I understand the
average Joe would not like it. You could argue Joe should run Mint instead.
When billion dollar companies have rock solid installers that only
support the 80% use case with essentially zero bugs and user
complaints about lack of function; compared to installers that try to
disproportionately appease the other 20% use cases with constant
regressions, it makes me think of project failure.
Agreed.
9:40 a.m.
On Mon, 2 Jan 2017 12:15:38 +0100, Mayavimmer wrote:
>> And while we are waiting for that, I would ask: why the UEFI
overwrite
>> pain? Can we add these 3 lines of pseudocode?
>>
>> if thisBox.alreadyHas( anotherFedora ) and isUEFI:
>> showDialog("Sorry, cannot currently add a second Fedora")
>> exit(0)
>
> Because that code by itself would prevent replacing an existing Fedora
> (of any release version).
Ok, right. Then we could get the best of both worlds, in keeping with
the Hippocratic Oath to at least do no harm, by dropping the exit() in
this two line pseudocode:
if thisBox.alreadyHas( anotherFedora ) and isUEFI:
showDialog("WARNING: you already have a Fedora installation\n"
"If you continue it will be OVERWRITTEN!")
...or "will be rendered inaccessible", until your suggestions not
implemented or some progress is made. Right now people who have not read
this thread risk losing their data.
For the BIOS install scenario, the MBR has been overwritten too, unless
the user customised the installer's bootloader settings.
When installing an OS it is expected that old installations are overwritten
or made non-bootable because a new bootloader is installed. It's a plus
that os-prober finds some existing installations, but it's not a must.
A growing number of warnings one would have to click through would be
problematic, too. The wording in the dialog above is ambiguous. An
upper-case "OVERWRITTEN" would be reason enough for users to quit
installation at this point out of fear. Just because they want to read up
on what exactly will be overwritten and whether they want that. They want
installation to "just work" and expect the installer to do what's
necessary.
12:28 p.m.
On 01/01/2017 06:10 PM, Chris Murphy wrote:
On Sun, Jan 1, 2017 at 1:45 PM, JD <jd1008(a)gmail.com> wrote:
> Without having done it myself, I suspect that for the 2nd installation, grub
> will
> make write into /boot/grub2/grub.cfg file an entry that is similar to the
> entry it makes
> when it detects a windows bootable partition.
On BIOS firmware computers, yes. And it's the 2nd installation GRUB
that "owns" the drive. It is this grub.cfg whose generic entries
should be replaced using configfile to point to the 1st installations
grub.cfg. This is much more maintainable and compatible.
On UEFI firmware, there is only one fedora bootloader and grub.cfg, so
the 2nd installation will overwrite the 1st. I would modify the
installation so that each has its own grub.cfg found at /boot/grub2
just like it's a BIOS setup (and is supported by upstream GRUB as they
do it this way by default, I'm baffled why Fedora does this
differently). And then create a minimalist grub.cfg on the efi system
partition that points to the two installation specific grub.cfgs by
using configfile command.
> I am not certain how many bootable partitions per disk grub2 supports.
A lot. It's limited by GRUB's ability to ennumerate, i.e. hdXmsdosY,
where the practical limit of Y is maybe something like 128. It
supports loading the kernel+initramfs on almost everything: md raid5
degraded; LVM, primary or extended MBR partitions, LUKs encrypted
volumes, Btrfs, ZFS, it's quite impressive what it can do. What
Thanx Chris.
As soon as I have another drive, I will try to put on it 2 fc25's and will
post the behavioral results and the diff results of the grub.cfg files.
3:20 p.m.
On Mon, 2 Jan 2017 11:28:21 -0700, JD wrote:
As soon as I have another drive, I will try to put on it 2 fc25's
and will
post the behavioral results and the diff results of the grub.cfg files.
The UUID of the root fs will be different, and that alone would be enough
already to avoid a conflict of multiple entries in grub.cfg for the same
OS version. os-prober also relies on UUID for the entries it creates.
3:26 p.m.
On 01/02/2017 01:20 PM, Michael Schwendt wrote:
The UUID of the root fs will be different, and that alone would be
enough
already to avoid a conflict of multiple entries in grub.cfg for the same
OS version. os-prober also relies on UUID for the entries it creates.
Just out of curiosity: I know that you can use partition labels in
fstab; can os-prober use them, or does it always use the UUID?
3:47 p.m.
On Mon, 2 Jan 2017 13:26:36 -0800, Joe Zeff wrote:
Just out of curiosity: I know that you can use partition labels in
fstab; can os-prober use them, or does it always use the UUID?
In parts, os-prober consists of shell scripts. When parsing fstab,
it seems it looks for LABEL= first: /usr/share/os-prober/common.sh
4:36 p.m.
On 01/02/2017 01:47 PM, Michael Schwendt wrote:
On Mon, 2 Jan 2017 13:26:36 -0800, Joe Zeff wrote:
> Just out of curiosity: I know that you can use partition labels in
> fstab; can os-prober use them, or does it always use the UUID?
In parts, os-prober consists of shell scripts. When parsing fstab,
it seems it looks for LABEL= first: /usr/share/os-prober/common.sh
Thanx. I often label my partitions so that I can easily remember what
they're supposed to be for, but I generally use the UUID in fstab for
consistency.
6:57 p.m.
On Sun, Jan 1, 2017 at 1:01 PM, Mayavimmer <mayavimmer(a)gmail.com> wrote:
On 01/01/2017 18:39, Michael Schwendt wrote:
> On Sun, 1 Jan 2017 11:23:27 -0500, Matthew Miller wrote:
>
>> On Sun, Jan 01, 2017 at 10:10:55AM +0100, Mayavimmer wrote:
>>> I tried to do an identical second install on the same machine, but the
>>> installer Anaconda gives an error about being unable to set a root
>>> partition.
>>
>> This isn't _forbidden_, but it also isn't something we test offically —
>> and in fact I'm not sure if anyone has actually tested it ever.
>
> I do manual installs like that regularly. Hence the earlier requests
> for details.
>
> The original post doesn't give enough details. I could have answered
> "yes" to the $subject, and yet there might be installation scenarios
> where the installer fails. More details needed!
As soon as I can. I already gave some details in the other sister
threads yesterday.
>
>> So, while I don't see why it couldn't be made to work, I also am not
>> surprised to hear it doesn't.
>
> It's the opposite here. I'm surprised manual partitioning would fail. If
> you point the installer at usable partitions for / and /boot, why would it
> fail?
Same exact sentiment, sir. It's ok if the poor little AI in the
installer can't hack complexity, but don't mess with my sacrosanct right
to manually override everything.
Well you really only get a true manual override with CLI installation.
Any function in a GUI installer requires coding. Manual overrides
involve some of the most complex coding, error handling, and sanity
checks, with a very high degree of liability that I think it's not
worth any GUI installer having such capability. The most reliable
installer examples have essentially no options, and definitely nothing
that really looks like a manual override such as what Anaconda offers.
And yet they'll do what you're asking for.
A literal manual override for everything is highly overrated, and with
all the installer testing and bug filing I've done and looking at
myriad use cases, it's just not worth it. It'd have been easier to
just have a bunch of use case pop-ups for automatic partitioning
presets.
--
Chris Murphy
7:17 p.m.
On 02/01/2017 01:57, Chris Murphy wrote:
On Sun, Jan 1, 2017 at 1:01 PM, Mayavimmer
<mayavimmer(a)gmail.com> wrote:
> On 01/01/2017 18:39, Michael Schwendt wrote:
>> On Sun, 1 Jan 2017 11:23:27 -0500, Matthew Miller wrote:
>>
>>> On Sun, Jan 01, 2017 at 10:10:55AM +0100, Mayavimmer wrote:
>>>> I tried to do an identical second install on the same machine, but the
>>>> installer Anaconda gives an error about being unable to set a root
>>>> partition.
>>>
>>> This isn't _forbidden_, but it also isn't something we test offically
—
>>> and in fact I'm not sure if anyone has actually tested it ever.
>>
>> I do manual installs like that regularly. Hence the earlier requests
>> for details.
>>
>> The original post doesn't give enough details. I could have answered
>> "yes" to the $subject, and yet there might be installation scenarios
>> where the installer fails. More details needed!
>
> As soon as I can. I already gave some details in the other sister
> threads yesterday.
>
>>
>>> So, while I don't see why it couldn't be made to work, I also am not
>>> surprised to hear it doesn't.
>>
>> It's the opposite here. I'm surprised manual partitioning would fail. If
>> you point the installer at usable partitions for / and /boot, why would it
>> fail?
>
> Same exact sentiment, sir. It's ok if the poor little AI in the
> installer can't hack complexity, but don't mess with my sacrosanct right
> to manually override everything.
Well you really only get a true manual override with CLI installation.
Any function in a GUI installer requires coding. Manual overrides
involve some of the most complex coding, error handling, and sanity
checks, with a very high degree of liability that I think it's not
worth any GUI installer having such capability. The most reliable
installer examples have essentially no options, and definitely nothing
that really looks like a manual override such as what Anaconda offers.
And yet they'll do what you're asking for.
A literal manual override for everything is highly overrated, and with
all the installer testing and bug filing I've done and looking at
myriad use cases, it's just not worth it. It'd have been easier to
just have a bunch of use case pop-ups for automatic partitioning
presets.
I agree. I did not literally mean that you should have a gui and the
logic behind it to specify every existing option. I was merely
exaggerating a bit to drive home the point that I feel more manual
control is needed. I think the sweet spot goes something like this: have
a couple of fully automatic use cases covered, but then if you go
outside them disable the smart decision making -- just put any fs type
on any block device, even if considered stupid (/boot inside LVM, Btrfs
over LVM, root too small, stop fscking my 2TB drives, etc), chastising
the user with a warning, at most. It feels like we have two modes now:
full-auto and semi-auto, where I prefer full-auto and manual.
11:25 a.m.
On Sun, 1 Jan 2017 10:10:55 +0100
Mayavimmer <mayavimmer(a)gmail.com> wrote:
I tried to do an identical second install on the same machine, but
the
installer Anaconda gives an error about being unable to set a root
partition.
That's weird. If it isn't operator error (the interface can be
confusing, especially since it is doing something complicated, and isn't
used often enough to get used to the quirks), then it sounds like a bug.
But, the better way to do this, is to manually create the partitions
you want for the second install, rsync the original install, and fix
the /etc/fstab. A lot faster.
I've run two versions of Fedora doing it this way, when I was going to
upgrade one of them to a later version or rawhide, without problem.
Never tried installing a second version, though I have successfully
installed many times with other versions of Fedora on the system. I
can't think of a reason why installing a second version would be an
issue, but you could open a bugzilla to see what the developers think.
The code is the final arbiter.
https://bugzilla.redhat.com/
1:43 p.m.
On 01/01/2017 18:25, stan wrote:
On Sun, 1 Jan 2017 10:10:55 +0100
Mayavimmer <mayavimmer(a)gmail.com> wrote:
> I tried to do an identical second install on the same machine, but the
> installer Anaconda gives an error about being unable to set a root
> partition.
That's weird. If it isn't operator error (the interface can be
confusing, especially since it is doing something complicated, and isn't
used often enough to get used to the quirks), then it sounds like a bug.
But, the better way to do this, is to manually create the partitions
you want for the second install, rsync the original install, and fix
the /etc/fstab. A lot faster.
I thought about doing it this way, but was discouraged by the additional
steps like, mounting /mnt and possibly binding stuff, grub installing
and mkconfigging, fiddling with alternate names in grub.cfg and
wondering what happens after the first kernel update, even worse in the
EFI case where I don't yet understand what is the efi directory naming
convention du jour, etc - you know, all those things an installer really
should do, for 4 reasons:
1. It's pretty tedious and error prone.
2. It fiddles with the ugliest area of computerdom outside of the
kernel: boot stuff.
3. If you mess up you could do it with flair.
4. Many fast changing technologies are involved simultaneously, and only
the upstream distro devs are in a good position to handle synchronization.
I've run two versions of Fedora doing it this way, when I was going to
upgrade one of them to a later version or rawhide, without problem.
Never tried installing a second version, though I have successfully
installed many times with other versions of Fedora on the system. I
can't think of a reason why installing a second version would be an
issue, but you could open a bugzilla to see what the developers think.
The code is the final arbiter.
I'll organize a list of repeatable failure scenarios and gotchas.
https://bugzilla.redhat.com/
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
11:33 a.m.
On Sun, Jan 1, 2017 at 2:10 AM, Mayavimmer <mayavimmer(a)gmail.com> wrote:
I tried to do an identical second install on the same machine, but
the
installer Anaconda gives an error about being unable to set a root
partition.
Reproduce the problem, then grab the logs from /tmp while still in the
installation environment, and put them up somewhere. The likely useful
logs will be storage.log, program.log, and anaconda.log.
It is possible to have two Fedora 25's on the system at the same time,
with varying degrees of storage efficiency. The most efficient layouts
use either Btrfs or LVM thin provisioning, sharing one storage pool
for both installations (or even more than two).
The one gotcha will be the bootloader configuration, whether UEFI or
BIOS firmware, only one Fedora bootloader exists at one time. My
preference is to make use of the GRUB configfile command to point to
another grub.cfg. Exactly how to set this up depends on whether the
firmware is UEFI or BIOS.
--
Chris Murphy
1:46 p.m.
On 01/01/2017 18:33, Chris Murphy wrote:
On Sun, Jan 1, 2017 at 2:10 AM, Mayavimmer
<mayavimmer(a)gmail.com> wrote:
> I tried to do an identical second install on the same machine, but the
> installer Anaconda gives an error about being unable to set a root
> partition.
Reproduce the problem, then grab the logs from /tmp while still in the
installation environment, and put them up somewhere. The likely useful
logs will be storage.log, program.log, and anaconda.log.
Thanks, very useful info. Will do that.
It is possible to have two Fedora 25's on the system at the same time,
with varying degrees of storage efficiency. The most efficient layouts
use either Btrfs or LVM thin provisioning, sharing one storage pool
for both installations (or even more than two).
The one gotcha will be the bootloader configuration, whether UEFI or
BIOS firmware, only one Fedora bootloader exists at one time. My
preference is to make use of the GRUB configfile command to point to
another grub.cfg. Exactly how to set this up depends on whether the
firmware is UEFI or BIOS.
Yes that is exactly one of the wheels I did not want to reinvent.
6:48 p.m.
On Sun, Jan 1, 2017 at 12:46 PM, Mayavimmer <mayavimmer(a)gmail.com> wrote:
On 01/01/2017 18:33, Chris Murphy wrote:
> On Sun, Jan 1, 2017 at 2:10 AM, Mayavimmer <mayavimmer(a)gmail.com> wrote:
>> I tried to do an identical second install on the same machine, but the
>> installer Anaconda gives an error about being unable to set a root
>> partition.
>
> Reproduce the problem, then grab the logs from /tmp while still in the
> installation environment, and put them up somewhere. The likely useful
> logs will be storage.log, program.log, and anaconda.log.
Thanks, very useful info. Will do that.
>
> It is possible to have two Fedora 25's on the system at the same time,
> with varying degrees of storage efficiency. The most efficient layouts
> use either Btrfs or LVM thin provisioning, sharing one storage pool
> for both installations (or even more than two).
>
> The one gotcha will be the bootloader configuration, whether UEFI or
> BIOS firmware, only one Fedora bootloader exists at one time. My
> preference is to make use of the GRUB configfile command to point to
> another grub.cfg. Exactly how to set this up depends on whether the
> firmware is UEFI or BIOS.
Yes that is exactly one of the wheels I did not want to reinvent.
Unfortunately it is not already invented by upstream GRUB or any other
distro. The existing method creates generic entries for "other OS's"
rather than forwarding entries. The result is a really incredibly bad
UX for multiboot - worse than the work necessary to do it correctly
rather than the overly complicated wrong way it's done now.
--
Chris Murphy
2668
days inactive
2671
days old
44 comments
9 participants
participants (9)
-
Chris Murphy -
JD -
Joe Zeff -
Matthew Miller -
Mayavimmer -
Michael Schwendt -
Patrick O'Callaghan -
Ranjan Maitra -
stan