I know the changes that Fedora is going through are supposed to be for the better and I can't argue against that as I'm not an OS dev. I'm sure some of this stuff does make Fedora better. Listed below are some of the changes. I may have forgotten some stuff and I may have gotten some stuff wrong.
In no particular order:
sysv init -> systemd rsyslogd -> journal +systemd (http://fedoraproject.org/wiki/Features/SystemdMessageCatalog) udev -> systemd+udev display manager selection -> systemd iptables -> firewalld cron -> systemd Calander (http://fedoraproject.org/wiki/Features/SystemdCalendarTimers) anaconda -> fedup + new anaconda eth0, eth1 -> something else unifying many separate dirs into /usr changing first uid/gid 500 -> 1000 grub -> grub2 /tmp mounted tmpfs intro of new /run dir
I know some of the old methods still work, but the idea is the new way is to eventually replace the old. As a sys admin I have *many* hours invested in learning the OS. I'm not against learning new stuff, provided there is a benefit, but I must admit I'm having trouble keeping up.
On 01/22/2013 01:52 AM, Robert Arkiletian wrote:
but I must admit I'm having trouble keeping up.
You're not alone there! And for me, since I'm still on Fedora 14, there's also GNOME 3!
I will install F18 in the next couple of weeks. I've always used Fedora every 4 releases (that's a new version every 2 years roughly). That means I'll have updates for one year and the next year I'm on my own (thanks to the Remi repo and others I can extend that extra year).
Anyhow, I mention this because indeed this is the VERY first time that I'm feeling like you (having a tough time trying to keep up). I've always used to read the "Release Notes" of all the 3 releases I missed plus the new one I'm about to install and I could keep up. This time I'm facing ALL the new changes you mentioned and, since I'm already feeling overwhelmed, I decided to skip the learning of some new stuff for later:
- I just learned I can disable firewalld and use my iptables scripts - I can install MATE and face GNOME 3 some time in the future
That's the way I'll be dealing with all of this.
In the end, if someone's a typical home user, who mainly use the web browser and doesn't care how things work behind the scenes, perhaps this won't bother him at all. I'm not like that.
On Tue, 2013-01-22 at 06:46 -0400, Jorge Fábregas wrote:
On 01/22/2013 01:52 AM, Robert Arkiletian wrote:
but I must admit I'm having trouble keeping up.
You're not alone there! And for me, since I'm still on Fedora 14, there's also GNOME 3!
I will install F18 in the next couple of weeks.
Beter wait for F19 ... I have F18 on 3 desktops and I am disapointed ... http://www.dedoimedo.com/computers/fedora-18-kde.html
and grub2 for dual boot ... "Beginning in Fedora 18, GRUB2 can no longer be installed to a partition." http://docs.fedoraproject.org/en-US/Fedora/18/html/Installation_Guide/s1-gru...
C.Sava
On 22 January 2013 11:03, Cristian Sava csava@central.ucv.ro wrote:
On Tue, 2013-01-22 at 06:46 -0400, Jorge Fábregas wrote:
On 01/22/2013 01:52 AM, Robert Arkiletian wrote:
but I must admit I'm having trouble keeping up.
You're not alone there! And for me, since I'm still on Fedora 14, there's also GNOME 3!
I will install F18 in the next couple of weeks.
Beter wait for F19 ... I have F18 on 3 desktops and I am disapointed ... http://www.dedoimedo.com/computers/fedora-18-kde.html
and grub2 for dual boot ... "Beginning in Fedora 18, GRUB2 can no longer be installed to a partition." http://docs.fedoraproject.org/en-US/Fedora/18/html/Installation_Guide/s1-gru...
What are the implications of that? I guess it affects the case where some people have multiple linuxes installed and use a chainload to start grub installed on the separate partitions?
Am 22.01.2013 12:10, schrieb Ian Malone:
On 22 January 2013 11:03, Cristian Sava csava@central.ucv.ro wrote:
On Tue, 2013-01-22 at 06:46 -0400, Jorge Fábregas wrote:
On 01/22/2013 01:52 AM, Robert Arkiletian wrote:
but I must admit I'm having trouble keeping up.
You're not alone there! And for me, since I'm still on Fedora 14, there's also GNOME 3!
I will install F18 in the next couple of weeks.
Beter wait for F19 ... I have F18 on 3 desktops and I am disapointed ... http://www.dedoimedo.com/computers/fedora-18-kde.html
and grub2 for dual boot ... "Beginning in Fedora 18, GRUB2 can no longer be installed to a partition." http://docs.fedoraproject.org/en-US/Fedora/18/html/Installation_Guide/s1-gru...
What are the implications of that? I guess it affects the case where some people have multiple linuxes installed and use a chainload to start grub installed on the separate partitions?
exactly
one reason more to have one priamry OS and use virtualization for anything else these days where the virt-overhead is nearly zero and in many cases virtual machines are faster than physical setups
On Tue, 2013-01-22 at 12:12 +0100, Reindl Harald wrote:
Am 22.01.2013 12:10, schrieb Ian Malone:
On 22 January 2013 11:03, Cristian Sava csava@central.ucv.ro wrote:
On Tue, 2013-01-22 at 06:46 -0400, Jorge Fábregas wrote:
On 01/22/2013 01:52 AM, Robert Arkiletian wrote:
but I must admit I'm having trouble keeping up.
You're not alone there! And for me, since I'm still on Fedora 14, there's also GNOME 3!
I will install F18 in the next couple of weeks.
Beter wait for F19 ... I have F18 on 3 desktops and I am disapointed ... http://www.dedoimedo.com/computers/fedora-18-kde.html
and grub2 for dual boot ... "Beginning in Fedora 18, GRUB2 can no longer be installed to a partition." http://docs.fedoraproject.org/en-US/Fedora/18/html/Installation_Guide/s1-gru...
What are the implications of that? I guess it affects the case where some people have multiple linuxes installed and use a chainload to start grub installed on the separate partitions?
exactly
one reason more to have one priamry OS and use virtualization for anything else these days where the virt-overhead is nearly zero and in many cases virtual machines are faster than physical setups
I hate this constraint!
C.S.
On 1/22/13, Cristian Sava csava@central.ucv.ro wrote:
and grub2 for dual boot ... "Beginning in Fedora 18, GRUB2 can no longer be installed to a partition." http://docs.fedoraproject.org/en-US/Fedora/18/html/Installation_Guide/s1-gru...
*anaconda* won't install GRUB2 to a partition. You can still accomplish it with `grub2-install --force`.
-T.C.
On Tue, Jan 22, 2013 at 10:46 AM, Jorge Fábregas jorge.fabregas@gmail.com wrote:
On 01/22/2013 01:52 AM, Robert Arkiletian wrote:
but I must admit I'm having trouble keeping up.
You're not alone there! And for me, since I'm still on Fedora 14, there's also GNOME 3!
I will install F18 in the next couple of weeks. I've always used Fedora every 4 releases (that's a new version every 2 years roughly). That means I'll have updates for one year and the next year I'm on my own (thanks to the Remi repo and others I can extend that extra year).
Anyhow, I mention this because indeed this is the VERY first time that I'm feeling like you (having a tough time trying to keep up). I've always used to read the "Release Notes" of all the 3 releases I missed plus the new one I'm about to install and I could keep up. This time I'm facing ALL the new changes you mentioned and, since I'm already feeling overwhelmed, I decided to skip the learning of some new stuff for later:
- I just learned I can disable firewalld and use my iptables scripts
- I can install MATE and face GNOME 3 some time in the future
That's the way I'll be dealing with all of this.
In the end, if someone's a typical home user, who mainly use the web browser and doesn't care how things work behind the scenes, perhaps this won't bother him at all. I'm not like that.
-- Jorge
How on earth are you still running F14. I thought the repos would be closed. I have just started using Fedora after having used *buntu. F17 was fine until i discovered that in fact F18 should have been out before Xmas. I find the 6 month releases counter productive i feel now after 5 years of using linux. Always keen to point out the benefits but i feel that a release is out on a certain date and that's it.
I've switched to a rolling release this week and i'll see how i get on with that. F18 imo isn't worth putting on.
james
On Tue, 2013-01-22 at 04:28 -0700, T.C. Hollingsworth wrote:
On 1/22/13, Cristian Sava csava@central.ucv.ro wrote:
and grub2 for dual boot ... "Beginning in Fedora 18, GRUB2 can no longer be installed to a partition." http://docs.fedoraproject.org/en-US/Fedora/18/html/Installation_Guide/s1-gru...
*anaconda* won't install GRUB2 to a partition. You can still accomplish it with `grub2-install --force`.
-T.C.
Thank you for the hint.
C.S.
On Tue, Jan 22, 2013 at 12:12:30PM +0100, Reindl Harald wrote:
one reason more to have one priamry OS and use virtualization for anything else these days where the virt-overhead is nearly zero and in many cases virtual machines are faster than physical setups
Which is OK on desktops with large (> 23" diagonal) monitors. But on a laptop (16:9 15" diagonal screen or smaller) you need a magnifying glass to work with the virtual screens. Neither KVM nor VirtualBox can present the virtual machine in the same 16:9 fullscreen format as your primary OS.
AV
Am 22.01.2013 12:48, schrieb Alexander Volovics:
On Tue, Jan 22, 2013 at 12:12:30PM +0100, Reindl Harald wrote:
one reason more to have one priamry OS and use virtualization for anything else these days where the virt-overhead is nearly zero and in many cases virtual machines are faster than physical setups
Which is OK on desktops with large (> 23" diagonal) monitors. But on a laptop (16:9 15" diagonal screen or smaller) you need a magnifying glass to work with the virtual screens. Neither KVM nor VirtualBox can present the virtual machine in the same 16:9 fullscreen format as your primary OS.
not using both of them
but VMware surely can fullscreen of a VM where you do not recognize any difference bewteen native and virtual as long you do not rely on 3D games
i would wonder if KVM / VirtualBox are not able to do this
On Tue, 22 Jan 2013 12:48:04 +0100 Alexander Volovics a.volovic@upcmail.nl wrote:
Neither KVM nor VirtualBox can present the virtual machine in the same 16:9 fullscreen format as your primary OS.
AV
I am using Full Widescreen with KVM. F17 host. F18 guest.
On Tue, 2013-01-22 at 13:31 +0200, Cristian Sava wrote:
On Tue, 2013-01-22 at 04:28 -0700, T.C. Hollingsworth wrote:
On 1/22/13, Cristian Sava csava@central.ucv.ro wrote:
and grub2 for dual boot ... "Beginning in Fedora 18, GRUB2 can no longer be installed to a partition." http://docs.fedoraproject.org/en-US/Fedora/18/html/Installation_Guide/s1-gru...
*anaconda* won't install GRUB2 to a partition. You can still accomplish it with `grub2-install --force`.
-T.C.
Thank you for the hint.
C.S.
My painful initial introduction to F18. Maybe it will help someone
The important part is the use of core.img and the "not using" of block addressing
I used bullets 3. and 5. successfully (on an all ext4 disk)!
John
https://bugzilla.redhat.com/show_bug.cgi?id=872826#c36 https://bugzilla.redhat.com/show_bug.cgi?id=886502 Should be in the Release Notes somewhere? Very slightly modified
NB Probably Only Valid for BIOS Booting?
Problem There is no longer an option to install boot loader (GRUB) to a partition.
Embedding GRUB to a partition contain an ext[234] file system is not recommended by upstream GRUB development, and in Fedora 18 is no longer an option.
Suggested alternatives: 1. Allow Fedora 18 to install GRUB2, to become your primary boot manager/loader (default).
2. Do not install a boot loader using Anaconda If you don't want your primary boot manager replaced, then in anaconda you need to deselect boot loader installation during F18 installation.
Installation Destination/Full disk summary and options to reveal the Selected Disks dialog.
Select disks and click "Do not install bootloader".
"Your system will not be bootable without additional post-install configuration. It's suggested you do this after installation has successfully finished, but before you reboot."
3. Configure the F18 boot loader manually at the end of installation Actions Create GRUB2 core.img, suppress embedding in the MBR and then produce grub.cfg
Control/Alt/F2 to a console terminal just before rebooting
Establish with certainty which /dev/sdX device Fedora 18 is installed on. Is this valid if / and /boot are on different partitions? mount | grep sysimage chroot /mnt/sysimage
Install GRUB, using whole /dev/sdX device from previous step, not including partition number The --grub-setup option inhibits the installation of grub to the MBR of /dev/sdX, however all the required grub2 files are installed in their correct locations grub2-install --grub-setup=/bin/true /dev/sdX
Then create grub.cfg - the name must be grub.cfg and NOT grub2.cfg grub2-mkconfig -o /boot/grub2/grub.cfg
4. If there is already a GRUB2 instance, add a menu entry to that distribution's grub.cfg, using 'configfile' to load the Fedora 18 grub.cfg created in step 3 above.
5. If you use a boot manager other than GRUB2, including GRUB Legacy, you can have it find and execute /boot/grub2/i-386-pc/core.img for example a GRUB Legacy entry with Fedora 18 /boot found on the 3rd partition:
title Load GRUB2, Fedora 18 root (hd0,3) kernel /boot/grub2/i386-pc/core.img boot ---------------------------------------------------- Be careful with partition numbers when mixing grub and grub2 Be careful with the presence of the leading /boot depending upon whether /boot is a separate partition Not certain of the exact syntax to be used above if separate /boot partition is present!!!!
############################################################################################# If the above is forgotten during installation then the following may be useful ! Necessary during my very first F18 install!
http://www.gnu.org/software/grub/manual/html_node/GRUB-only-offers-a-rescue-...
27.1 GRUB only offers a rescue shell
GRUB's normal start-up procedure involves setting the 'prefix' environment variable to a value set in the core image by grub-install, setting the 'root' variable to match, loading the 'normal' module from the prefix, and running the 'normal' command (see normal). This command is responsible for reading /boot/grub/grub.cfg, running the menu, and doing all the useful things GRUB is supposed to do.
If, instead, you only get a rescue shell, this usually means that GRUB failed to load the 'normal' module for some reason. It may be possible to work around this temporarily: for instance, if the reason for the failure is that 'prefix' is wrong (perhaps it refers to the wrong device, or perhaps the path to /boot/grub was not correctly made relative to the device), then you can correct this and enter normal mode manually:
# Inspect the current prefix (and other preset variables): set # Find out which devices are available: ls # Set to the correct value, which might be something like this: set prefix=(hd0,1)/grub set root=(hd0,1) insmod normal normal However, any problem that leaves you in the rescue shell probably means that GRUB was not correctly installed. It may be more useful to try to reinstall it properly using grub-install device (see Invoking grub-install). When doing this, there are a few things to remember:
Drive ordering in your operating system may not be the same as the boot drive ordering used by your firmware. Do not assume that your first hard drive (e.g. '/dev/sda') is the one that your firmware will boot from. device.map (see Device map) can be used to override this, but it is usually better to use UUIDs or file system labels and avoid depending on drive ordering entirely.
At least on BIOS systems, if you tell grub-install to install GRUB to a partition but GRUB has already been installed in the master boot record, then the GRUB installation in the partition will be ignored. If possible, it is generally best to avoid installing GRUB to a partition (unless it is a special partition for the use of GRUB alone, such as the BIOS Boot Partition used on GPT). Doing this means that GRUB may stop being able to read its core image due to a file system moving blocks around, such as while defragmenting, running checks, or even during normal operation. Installing to the whole disk device is normally more robust. Check that GRUB actually knows how to read from the device and file system containing /boot/grub. It will not be able to read from encrypted devices, nor from file systems for which support has not yet been added to GRUB.
On Tue, Jan 22, 2013 at 12:16:52PM +0000, Frank Murphy wrote:
On Tue, 22 Jan 2013 12:48:04 +0100 Alexander Volovics a.volovic@upcmail.nl wrote:
Neither KVM nor VirtualBox can present the virtual machine in the same 16:9 fullscreen format as your primary OS.
I am using Full Widescreen with KVM. F17 host. F18 guest.
When I tried with Ubuntu in F16 I could only get 4:3 fullscreen not 16:9 fullscreen. Is there some special trick or has KVM 'advanced'?
AV
On Tue, 22 Jan 2013 13:34:39 +0100 Alexander Volovics a.volovic@upcmail.nl wrote:
When I tried with Ubuntu in F16 I could only get 4:3 fullscreen not 16:9 fullscreen. Is there some special trick or has KVM 'advanced'?
AV
I did nothing special just qxl video driver in the Guest
On Tue, Jan 22, 2013 at 12:37:14PM +0000, Frank Murphy wrote:
On Tue, 22 Jan 2013 13:34:39 +0100 Alexander Volovics a.volovic@upcmail.nl wrote:
When I tried with Ubuntu in F16 I could only get 4:3 fullscreen not 16:9 fullscreen. Is there some special trick or has KVM 'advanced'?
I did nothing special just qxl video driver in the Guest
Then I will have to try again now I am using F18 to see what happens.
AV
On Tue, 22 Jan 2013 13:03:48 +0200 Cristian Sava csava@central.ucv.ro wrote:
On Tue, 2013-01-22 at 06:46 -0400, Jorge Fábregas wrote:
On 01/22/2013 01:52 AM, Robert Arkiletian wrote:
but I must admit I'm having trouble keeping up.
You're not alone there! And for me, since I'm still on Fedora 14, there's also GNOME 3!
I will install F18 in the next couple of weeks.
Beter wait for F19 ... I have F18 on 3 desktops and I am disapointed ... http://www.dedoimedo.com/computers/fedora-18-kde.html
Similar to my experience - when it works its unusuably bad, but its quite capable of leaving you needing to reinstall an old release from scratch
Alan
I'm facing ALL the new changes you mentioned and, since I'm already feeling overwhelmed, I decided to skip the learning of some new stuff for later:
If you are trying to keep a system running to get work done without big changes you want Centos rather than Fedora - definitely. That or something like Ubuntu where the change rate is a bit saner, and with the LTS version a lot less.
- I just learned I can disable firewalld and use my iptables scripts
- I can install MATE and face GNOME 3 some time in the future
That's the way I'll be dealing with all of this.
In the end, if someone's a typical home user, who mainly use the web browser and doesn't care how things work behind the scenes, perhaps this won't bother him at all. I'm not like that.
For that kind of user I've had more success with Ubuntu than anything else - it just works, it's got Ubuntu One file back up services and it's got a community pitched at the "user" level.
From a technical perspective there is plenty not to like about some areas of Ubuntu, and it lags Fedora on features and the like, but for end users who don't care about such detail it usually just works.
Alan
On Tue, Jan 22, 2013 at 1:09 PM, Alan Cox alan@lxorguk.ukuu.org.uk wrote:
If you are trying to keep a system running to get work done without big changes you want Centos rather than Fedora - definitely.
Even then, I'm not so sure any more. My recent CentOS 6 install was a pretty horrendous experience, and I still can't get a lot of stuff working (network printing and scanning, for example). I'm starting to think that RHEL5 and somewhere around F14 was a high point for Linux and it's all been heading downhill since then :-( Stuff that used to work out of the box no longer does, and they've removed the tools that I used to use to fix things.
Tet
On Tue, 2013-01-22 at 04:28 -0700, T.C. Hollingsworth wrote:
On 1/22/13, Cristian Sava csava@central.ucv.ro wrote:
and grub2 for dual boot ... "Beginning in Fedora 18, GRUB2 can no longer be installed to a partition." http://docs.fedoraproject.org/en-US/Fedora/18/html/Installation_Guide/s1-gru...
*anaconda* won't install GRUB2 to a partition. You can still accomplish it with `grub2-install --force`.
-T.C.
But is there some danger associated with doing this as part of an upgrade? If not, why was the option removed from Anaconda?
On Tue, 22 Jan 2013 13:35:20 +0000 Matthew Saltzman mjs@clemson.edu wrote:
But is there some danger associated with doing this as part of an upgrade? If not, why was the option removed from Anaconda?
Why would you be changing Grub-install /some/part as part of an upgrade, if is in going in the same place as what is\was there?
Am 22.01.2013 14:35, schrieb Matthew Saltzman:
On Tue, 2013-01-22 at 04:28 -0700, T.C. Hollingsworth wrote:
On 1/22/13, Cristian Sava csava@central.ucv.ro wrote:
and grub2 for dual boot ... "Beginning in Fedora 18, GRUB2 can no longer be installed to a partition." http://docs.fedoraproject.org/en-US/Fedora/18/html/Installation_Guide/s1-gru...
*anaconda* won't install GRUB2 to a partition. You can still accomplish it with `grub2-install --force`.
-T.C.
But is there some danger associated with doing this as part of an upgrade? If not, why was the option removed from Anaconda?
because fedora does announce features for code which is not written because some not so smart guys really believe it is possible to write, debug and finalize this in a 6 month release cycle which is nothing else as lost reality
that happened with: * pulseaudio * KDE4.0 * GNOME3 * systemd * anaconda
all of them where proposed and accepted as feature based on the hope it could be working and useable to the end of the release schedule instead REJECT ANY FEATURE which is not basically working only left with minoity cleanup/fixing/debugging/polish
On Tue, 2013-01-22 at 12:12 +0100, Reindl Harald wrote:
one reason more to have one priamry OS and use virtualization for anything else
There are some cases where this doesn't work. One I know of is commercial games under Windows. Some of them just do not work when Windows is running in a VM.
I have been told (and I don't know if it's true but it makes sense) that this is because of copy protection. The game CD has some stuff written beyond the "end" of the disc. Low-level system calls can read this, but a normal user space disc copy doesn't, so the software can tell when it loads whether or not this is the original CD or a copy. Since the hypervisor doesn't implement reading beyond the end of the disc, the games won't load even with the original CD when running in a VM.
As I said, I don't know if this explanation is correct, but I do know that some of my games will not load when running in a VM, so I have to have a native Windows boot.
--Greg
On 22 January 2013 15:02, Greg Woods woods@ucar.edu wrote:
On Tue, 2013-01-22 at 12:12 +0100, Reindl Harald wrote:
one reason more to have one priamry OS and use virtualization for anything else
There are some cases where this doesn't work. One I know of is commercial games under Windows. Some of them just do not work when Windows is running in a VM.
I have been told (and I don't know if it's true but it makes sense) that this is because of copy protection. The game CD has some stuff written beyond the "end" of the disc. Low-level system calls can read this, but a normal user space disc copy doesn't, so the software can tell when it loads whether or not this is the original CD or a copy. Since the hypervisor doesn't implement reading beyond the end of the disc, the games won't load even with the original CD when running in a VM.
As I said, I don't know if this explanation is correct, but I do know that some of my games will not load when running in a VM, so I have to have a native Windows boot.
One of a number of tricks that publishers have tried to use (another favourite is detecting debuggers, which often refuses to work with Wine). Of course the game ends up being cracked anyway and people with legitimate copies end up looking for cracks to work around problems with the copy protection... Actually the grub2 install thing should not affect dual-booting windows. From what I understand (I've never used this setup myself) some people multi-boot linux versions by having separate /boot and a partition-installed grub for each one, which the device-installed grub chooses. You could potentially multiboot linuxes by sharing the /boot and having all the entries in one grub.conf, but I think it might be tricky to correctly handle updates. Fortunately there are fewer issues running linux in a VM, unless the machine has limited resources.
On Tue, 2013-01-22 at 08:02 -0700, Greg Woods wrote:
On Tue, 2013-01-22 at 12:12 +0100, Reindl Harald wrote:
one reason more to have one priamry OS and use virtualization for anything else
There are some cases where this doesn't work. One I know of is commercial games under Windows. Some of them just do not work when Windows is running in a VM.
I have been told (and I don't know if it's true but it makes sense) that this is because of copy protection. The game CD has some stuff written beyond the "end" of the disc. Low-level system calls can read this, but a normal user space disc copy doesn't, so the software can tell when it loads whether or not this is the original CD or a copy. Since the hypervisor doesn't implement reading beyond the end of the disc, the games won't load even with the original CD when running in a VM.
I would have thought that correct emulation would allow those same low-level calls in a VM. AFAIK the guest system can read the whole CD as a raw device (assuming appropriate privileges).
As I said, I don't know if this explanation is correct, but I do know that some of my games will not load when running in a VM, so I have to have a native Windows boot.
One reason for some games not working is that they require a better graphics card than the one emulated by the VM.
poc
On Tue, 2013-01-22 at 15:11 +0000, Ian Malone wrote:
Actually the grub2 install thing should not affect dual-booting windows.
You're right, it doesn't. I can dual boot Windows just fine with grub2. I was responding to the comment that there is no reason to ever need a native boot when a VM would do.
From what I understand (I've never used this setup myself) some people multi-boot linux versions by having separate /boot and a partition-installed grub for each one
I used to do that so that I could hibernate Linux and then boot Windows, later thawing Linux. This was necessary because when there was a hibernate image present, Linux used to immediately boot the matching kernel without presenting the grub menu, so when Linux was hibernated, it was impossible to boot any other OS. I got around that by having grub in a partition and using a chainloader statement to load it from the disk's boot sector. I believe this was done to make sure the user didn't select the wrong kernel, which would trash the hibernation image and require a cold boot. Since the switch to grub2, I now get the usual menu regardless of whether or not there is a hibernation image present, so I no longer need to install grub in a partition.
--Greg
On Tue, 2013-01-22 at 15:29 +0000, Patrick O'Callaghan wrote:
On Tue, 2013-01-22 at 08:02 -0700, Greg Woods wrote: The game CD has some stuff written
beyond the "end" of the disc.
I would have thought that correct emulation would allow those same low-level calls in a VM. AFAIK the guest system can read the whole CD as a raw device (assuming appropriate privileges).
The trick is in defining "correct" emulation and "the whole CD". If the entire ISO image can be read, isn't that the whole CD? Well it is, unless you come across this kind of trickery. So it's not hard to imagine that a hypervisor emulator might not implement the ability to read blocks that are technically beyond the end of the disc.
One reason for some games not working is that they require a better graphics card than the one emulated by the VM.
True, however in at least one case I get complaints like "please use the ORIGINAL CD" when trying to load the game in a VM, even when I *did* have the original CD. There is obviously some kind of copy protection going on that doesn't work properly from within a VM.
--Greg
On Tue, 22 Jan 2013 13:35:20 +0000 Matthew Saltzman mjs@clemson.edu wrote:
On Tue, 2013-01-22 at 04:28 -0700, T.C. Hollingsworth wrote:
On 1/22/13, Cristian Sava csava@central.ucv.ro wrote:
and grub2 for dual boot ... "Beginning in Fedora 18, GRUB2 can no longer be installed to a partition." http://docs.fedoraproject.org/en-US/Fedora/18/html/Installation_Guide/s1-gru...
*anaconda* won't install GRUB2 to a partition. You can still accomplish it with `grub2-install --force`.
-T.C.
But is there some danger associated with doing this as part of an upgrade? If not, why was the option removed from Anaconda?
Yes, there is a danger. See: https://bugzilla.redhat.com/show_bug.cgi?id=872826#c19
"The problem is ext4's boot sector is only 512 bytes, which is not enough space. The use of --force fragments GRUB, and installs the pieces into free space without informing the file system. At any future time the file system can step on any one of those block lists and render the system unbootable."
kevin
I've basically given up trying to view multiple OSs on one medium-sized screen. My basic setup when not on the road is to have two screens and run the other OS in the second screen. Unfortunately, I use a couple of programs that are built for Ubuntu, and I can't get the dependencies to work to compile them in Fedora; in addition, I do a lot of teaching and while I make most of my presentations in libreoffice, I almost always have to review them in PowerPoint to make sure the format change worked right.
So, I normally work with a second OS up that's either Mint/Ubuntu or Windows. But I'd go blind if I tried to do that with just one screen.
billo
On Tue, 22 Jan 2013, Alexander Volovics wrote:
On Tue, Jan 22, 2013 at 12:12:30PM +0100, Reindl Harald wrote:
one reason more to have one priamry OS and use virtualization for anything else these days where the virt-overhead is nearly zero and in many cases virtual machines are faster than physical setups
Which is OK on desktops with large (> 23" diagonal) monitors. But on a laptop (16:9 15" diagonal screen or smaller) you need a magnifying glass to work with the virtual screens. Neither KVM nor VirtualBox can present the virtual machine in the same 16:9 fullscreen format as your primary OS.
AV
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On Tue, Jan 22, 2013 at 8:48 AM, Alexander Volovics a.volovic@upcmail.nl wrote:
Neither KVM nor VirtualBox can present the virtual machine in the same 16:9 fullscreen format as your primary OS.
Are you implying that Virtualbox doesn´t have a full screen mode? Because, believe me, I have used it on Windows hosts to run Linux full screen.
FC
On Tue, Jan 22, 2013 at 8:12 AM, Reindl Harald h.reindl@thelounge.net wrote:
one reason more to have one priamry OS and use virtualization for anything else these days where the virt-overhead is nearly zero and in many cases virtual machines are faster than physical setups
That is only partially accurate on CPUs that feature hardware virtualization support (AMD-V or Intel VT-x). The other day just for kicks I tried installing the latest Ubuntu virtualized on a Atom based Netbook running XP SP3, and it took about two hours just to install... performance could be described as "slow as molasses". ;). But yes, I guess that if you use a Quad-core with AMD-V or VT-x and 8 gigs of ram, things would be almost seamless.
Which reminds me of something.... I noticed that the latest Ubuntu features an optional kernel ("Linux-virt" package) that is supposedly optimized for running Linux virtualized.... is there such a package in Fedora? (never looked, just thinking aloud :).
TIA FC
On Tue, Jan 22, 2013 at 02:18:00PM -0300, Fernando Cassia wrote:
Which reminds me of something.... I noticed that the latest Ubuntu features an optional kernel ("Linux-virt" package) that is supposedly optimized for running Linux virtualized.... is there such a package in Fedora? (never looked, just thinking aloud :).
It's not optimized in a performance sense. It just doesn't include drivers for hardware support which isn't likely in a virt environment, making it smaller.
On Tue, 2013-01-22 at 09:45 -0700, Greg Woods wrote:
On Tue, 2013-01-22 at 15:29 +0000, Patrick O'Callaghan wrote:
On Tue, 2013-01-22 at 08:02 -0700, Greg Woods wrote: The game CD has some stuff written
beyond the "end" of the disc.
I would have thought that correct emulation would allow those same low-level calls in a VM. AFAIK the guest system can read the whole CD as a raw device (assuming appropriate privileges).
The trick is in defining "correct" emulation and "the whole CD". If the entire ISO image can be read, isn't that the whole CD? Well it is, unless you come across this kind of trickery. So it's not hard to imagine that a hypervisor emulator might not implement the ability to read blocks that are technically beyond the end of the disc.
So are you talking about 1) the actual physical CD, or 2) an ISO image of the CD? I presumed the former, in which case there *should* be no difference (and if there is, then the VM's emulation is incomplete). OTOH if it's an ISO image, then all bets are off; for one thing whatever software created the image may not have tried to read the entire physical medium but just the filesystems it found there, and for another (probably more relevant in this case) some copy-protection schemes use deliberately damaged blocks so that normal s/w will get read errors which an ISO image cannot reproduce.
One reason for some games not working is that they require a better graphics card than the one emulated by the VM.
True, however in at least one case I get complaints like "please use the ORIGINAL CD" when trying to load the game in a VM, even when I *did* have the original CD. There is obviously some kind of copy protection going on that doesn't work properly from within a VM.
See option (1) above.
poc
On Tue, Jan 22, 2013 at 02:12:37PM -0300, Fernando Cassia wrote:
On Tue, Jan 22, 2013 at 8:48 AM, Alexander Volovics a.volovic@upcmail.nl wrote:
Neither KVM nor VirtualBox can present the virtual machine in the same 16:9 fullscreen format as your primary OS.
Are you implying that Virtualbox doesn´t have a full screen mode? Because, believe me, I have used it on Windows hosts to run Linux full screen.
I could run VirtualBox full screen allright but the actual guest screen was in 4:3 ratio and I couldn't get 16:9 ratio. So there were 2 large black bars on either side.
However that was some time ago (F16 had just come out). I have not tried VB recently.
I have just installed Ubuntu 13.04 (alpha, daily build) in F18 using KVM and 'virt-manager' and now I can get 16:9 fullscreen with KVM.
But it performs a bit slow and shaky. I don't know if this is due to virtualization or the alpha status of Ubuntu 13.04 or both.
Performance wise I would say that dual boot is preferable.
AV
On Tue, 2013-01-22 at 18:24 +0000, Patrick O'Callaghan wrote:
On Tue, 2013-01-22 at 09:45 -0700, Greg Woods wrote:
On Tue, 2013-01-22 at 15:29 +0000, Patrick O'Callaghan wrote:
On Tue, 2013-01-22 at 08:02 -0700, Greg Woods wrote: The game CD has some stuff written
beyond the "end" of the disc.
I would have thought that correct emulation would allow those same low-level calls in a VM. AFAIK the guest system can read the whole CD as a raw device (assuming appropriate privileges).
The trick is in defining "correct" emulation and "the whole CD".
So are you talking about 1) the actual physical CD, or 2) an ISO image of the CD? I presumed the former
Yes, I meant the real CD passed through to the VM as a virtual CD-ROM.
in which case there *should* be no difference (and if there is, then the VM's emulation is incomplete).
Yes, the hypervisor's emulation is incomplete if my original speculation is correct. But it's not surprising that it's incomplete, since 99.9% of the time, there is no good reason to be reading blocks beyond the end of the disc.
some copy-protection schemes use deliberately damaged blocks so that normal s/w will get read errors which an ISO image cannot reproduce.
I hadn't thought of that, but in that case, the emulator is also incomplete since it isn't passing through the read errors.
This is getting quite far afield now. The original point was only that there are reasons why a native boot might be needed and a VM won't always work as a replacement.
--Greg
On Tue, 2013-01-22 at 09:51 -0700, Kevin Fenzi wrote:
On Tue, 22 Jan 2013 13:35:20 +0000 Matthew Saltzman mjs@clemson.edu wrote:
On Tue, 2013-01-22 at 04:28 -0700, T.C. Hollingsworth wrote:
On 1/22/13, Cristian Sava csava@central.ucv.ro wrote:
and grub2 for dual boot ... "Beginning in Fedora 18, GRUB2 can no longer be installed to a partition." http://docs.fedoraproject.org/en-US/Fedora/18/html/Installation_Guide/s1-gru...
*anaconda* won't install GRUB2 to a partition. You can still accomplish it with `grub2-install --force`.
-T.C.
But is there some danger associated with doing this as part of an upgrade? If not, why was the option removed from Anaconda?
Yes, there is a danger. See: https://bugzilla.redhat.com/show_bug.cgi?id=872826#c19
"The problem is ext4's boot sector is only 512 bytes, which is not enough space. The use of --force fragments GRUB, and installs the pieces into free space without informing the file system. At any future time the file system can step on any one of those block lists and render the system unbootable."
kevin
Not true if you use something like this (old grub)
title Load GRUB2, Fedora 18 root (hd0,3) kernel /boot/grub2/i386-pc/core.img boot
or grub2 equivalent
no --force involved!
See my previous post
John
El mar, 22-01-2013 a las 11:10 +0000, Ian Malone escribió:
On 22 January 2013 11:03, Cristian Sava csava@central.ucv.ro wrote:
On Tue, 2013-01-22 at 06:46 -0400, Jorge Fábregas wrote:
On 01/22/2013 01:52 AM, Robert Arkiletian wrote:
but I must admit I'm having trouble keeping up.
You're not alone there! And for me, since I'm still on Fedora 14, there's also GNOME 3!
I will install F18 in the next couple of weeks.
Beter wait for F19 ... I have F18 on 3 desktops and I am disapointed ... http://www.dedoimedo.com/computers/fedora-18-kde.html
and grub2 for dual boot ... "Beginning in Fedora 18, GRUB2 can no longer be installed to a partition." http://docs.fedoraproject.org/en-US/Fedora/18/html/Installation_Guide/s1-gru...
What are the implications of that? I guess it affects the case where some people have multiple linuxes installed and use a chainload to start grub installed on the separate partitions?
-- imalone http://ibmalone.blogspot.co.uk
Hi! Just for information: I have 3 linux installed in my computer and they're all fine. GRUB is pretty and this is the first time that it recognize them and boot them well. I'm very happy.
Cheers, Lailah
-
Alan Cox -
Alexander Volovics -
Cristian Sava -
Dr J Austin -
Fernando Cassia -
Frank Murphy -
Greg Woods -
Ian Malone -
James Freer -
Jorge Fábregas -
Kevin Fenzi -
Matthew Miller -
Matthew Saltzman -
Patrick O'Callaghan -
Reindl Harald -
Robert Arkiletian -
Sylvia Sánchez -
T.C. Hollingsworth -
Tethys -
William Oliver