2019-02-27 15:01:07 -0600 | commented answer | Fedora 29 VirtualBox possible conflict to sixpack13 : Did you misinterpret my query? The link that I indicated that I am about to follow will have me install |
2019-02-27 09:32:30 -0600 | asked a question | Fedora 29 VirtualBox possible conflict Fedora 29 VirtualBox possible conflict I did a complete re-install (not upgrade) to Fedora 29 in November 2018. At that |
2019-01-04 01:21:05 -0600 | commented question | submitting feature request Sorry for the ambiguity. I am reluctant to respond with a two page detailing of a very complex feature request. In sum |
2019-01-04 00:24:36 -0600 | received badge | ● Enthusiast |
2019-01-03 21:02:44 -0600 | asked a question | submitting feature request submitting feature request What is the procedure to follow to submit a feature request to the Fedora developers communit |
2018-11-13 19:28:10 -0600 | commented question | could Fedora please reverse its policy re End-Of-Life I internet-researched and discovered people having trouble upgrading. |
2018-11-12 19:06:48 -0600 | asked a question | could Fedora please reverse its policy re End-Of-Life could Fedora please reverse its policy re End-Of-Life Internet-researching, I've seen many situations where the user had |
2017-12-21 12:34:44 -0600 | received badge | ● Notable Question (source) |
2017-09-01 03:11:59 -0600 | received badge | ● Notable Question (source) |
2017-09-01 03:11:59 -0600 | received badge | ● Popular Question (source) |
2017-05-06 07:45:37 -0600 | received badge | ● Notable Question (source) |
2017-05-06 07:45:37 -0600 | received badge | ● Popular Question (source) |
2016-05-26 12:02:45 -0600 | commented question | fedora 22 filesharing problem with virt-manager and Windows 7 guest My bad for not being clear. Within the Windows 7 vm, if I add /mnt/disk1/ it does not show in the Windows network, so I can't map to it. Alternatively, if I add /myshareddisk1, which is (samba) "localhost-mounted", virtual machine manager (virt-manager) crashes. |
2016-05-23 21:40:20 -0600 | commented answer | is there a way to install chrome on f22 after Aprill 2016? netflix not work with firefox (Fedora 22 : cinnamon), but does work with chrome. |
2016-05-23 19:49:47 -0600 | asked a question | fedora 22 filesharing problem with virt-manager and Windows 7 guest I'm running Fedora 22 (64 bit, 16gb memory) with a cinnamon desktop and I would like to use Virtual Machine Manager to run Windows 7. However, I need filesharing between the Fedora 22 host and the virtual machine (Windows 7). I installed samba and Virtual Machine Manager via I then created the /mnt/disk1 (with 1 file) and /myshareddisk1 (empty) directories and used chmod 777 on both of them. Then I added the following trailer to /etc/samba/smb.conf: Then I used the following commands to enable the samba access to /mnt/disk1. Then, I used the following commands to create samba passwords for the root user, and my other user, steve. I then started samba and made /myshareddisk1 a mount of /mnt/disk1 via I then verified the samba process via both I then started the virtual machine service (systemctl start libvirtd) and started the virt-mgr application. Then I created a new virtual machine, and used a Windows 7 iso to install Windows 7 into this machine. The Windows 7 virtual machine runs ok. SO FAR, EVERYTHING WAS FINE. HOWEVER THIS IS ALL WORTHLESS TO ME IF I CAN'T FILE SHARE BETWEEN FEDORA AND WINDOWS. Using the virt-mgr gui, I tried to add a samba file system to the Windows 7 virtual machine; an error message was generated. I then google researched, and discovered that (perhaps) virt-mgr doesn't like the source directory /home/steve/shared02, because it is not owned by the root user. I then tried a source directory of /mnt/disk1. This allowed virt-mgr to start the Windows 7 virtual machine, but did not provide any file sharing access. Then, I tried a source directory of /myshareddisk1, which (before the samba mounting) was owned by the root. This re-generated the error: I then altered the mounting (mount //localhost/mydisk1 /myshareddisk1 -o user=root) and repeated the process: virt-mgr still produced the Error starting domain message. I then experimented within virt-mgr with various drive/mode combinations for the file system to be added - no joy. Questions: If possible, please give direct answer(s) rather than referring to a webpage.
|
2016-04-20 12:08:33 -0600 | received badge | ● Commentator |
2016-04-20 12:08:33 -0600 | commented answer | fedora 22 cinnamon dmesg memory problem thanks for the response, genodeftest. I could be mistaken, but I thought that my fedora22-kde4(dmesg) output did contain the "device node =" string. With that string missing, and a "...debugging..." message occurring, I questioned it. Also, on a cold boot, just after the bios message, when the screen shows Fedora options to select, the TOP ONE IN THE LIST is "fedora ... debug ..." which I also think is strange. This might relate to previous problems I had installing Fedy (i.e. repo not exist). No problems were reported re sudo smartctl -s on -t short /dev/sdb. |
2016-04-19 21:47:59 -0600 | received badge | ● Nice Question (source) |
2016-04-19 11:23:30 -0600 | asked a question | fedora 22 cinnamon dmesg memory problem This query is probably more appropriately directed to a cinnamon or cinnamon-fedora forum, if any. However, I'll probably have better luck at this forum. Boot disk recently died; decided to recover by re-installing everything, starting with Fedora 22 Live. kde proved problematic so switched to cinnamon. Several months ago, while using Fedora 22 with kde4, I researched how to make an external hard disk bootable. One of the steps was to find the device node assigned to the drive. Today, I'm under fedora 22 64 bit with cinnamon 2.6.13, 16gb memory. I inserted a hard disk to my usb connected docking station (device sdd). Cinnamon automatically mounted it; I then unmounted the drive, leaving it still assigned to device sdd. Then: The heading lines from the top command (executed as the super user) are: Questions
|
2016-04-14 21:22:06 -0600 | commented answer | fedora 22 dnf upgrade failed to sync The debate seems to be "more that can go wrong" vs "ease of use". Since I am a programmer, and dnf is straightforward (and powerful), it is a no-brainer for me to avoid Fedy unless I'm forced into it; [e.g. if I can't find a workable Adobe Flash repo any other way, I'll query Linux forum(s)]. For true Linux newbie, ease of use" might be attractive. |
2016-04-14 21:20:59 -0600 | commented answer | fedora 22 dnf upgrade failed to sync thanks florian, very interesting response. following up, i googled : fedora "not use fedy", and fedora "against fedy"; interesting reading. I was merely following the advice in both http://linoxide.com/linux-how-to/thin... and http://www.attabot.org/linux/things-i... . |
2016-04-14 21:00:49 -0600 | received badge | ● Scholar (source) |
2016-04-14 12:55:56 -0600 | asked a question | fedora 22 dnf upgrade failed to sync Symptomsudo dnf update : excerpt Rigfedora 22 64 bit, cinnamon 2.6.13, 16gb memory BackgroundBoot disk recently died; decided to recover by re-installing everything, starting with Fedora 22 Live. kde proved problematic so switched to cinnamon. Then had trouble installing fedy. With the (partial or full) failures shown below, I (mistakenly) did not retain the error messages. The following seemed to totally fail: The following seemed to either partially or totally fail. I noticed what seemed to be error messages. Because of the error messages in the previous approach, I then: The above seemed to succeed, "Fedy" was added to the cinnamon start Menu. In fact, (partially unrelated) after a previous (terminal) attempt to install Adobe Flash failed, the Fedy installer successfully installed it. This was verified via a webpage that requires Flash. Long TermActually, I've been "living off of" a usb-connected external hard disk, using it as a boot disk. New hard disks coming in a few days; then I'll (again) re-install from scratch, starting with Fedora 22 Live. Questions
|
2016-03-09 21:01:59 -0600 | received badge | ● Popular Question (source) |
2016-03-03 16:53:26 -0600 | asked a question | recovery by package re-install In case of hard disk failure, I want my recovery to (ideally) re-create the pre-hard-disk-crash environment. After researching backup strategies for my Fedora 22 home pc, I've decided to only use rsync on my /home and /etc directories, and to (during recovery) manually re-install packages and manually upgrade packages. After examining the dnf documentation and recovery-related forum entries, I'm confused about the explicit recovery steps to take. The following chart shows the number of entries for various commands: 00042_lines dnf history list With no linux recovery experience, my tentative strategy is shown below: I REQUEST CRITICISM FROM EXPERIENCED LINUX USERS. I ALSO REQUEST SPECIFIC OPTIONS TO USE WITH THE "dnf [options] upgrade" COMMAND (STEP # 5 BELOW). (1) In addition to using rsync to maintain an independent copy of my /home and /etc directories, maintain a copy of dnf_history_userinstalled.txt, et al. Ignore the other 4 entries above. (2) Maintain a bootable flashdrive of Fedora 22 Workstation Live, updating it whenever fedoraproject.org updates the corresponding iso. To recover when the (boot) hard disk fails: (3) Use the flashdrive to install the "full" Fedora 22 to a new hard disk. (4) Use dnf_history_userinstalled.txt to manually install the (less than 50) packages. (5) Execute the "dnf [options] upgrade" command. Hopefully, since I kept the flashdrive of Fedora 22 Workstation Live "current", this process will be "streamlined". (6) Use rsync to update the /home and /etc directories on the new hard disk. |
2016-02-12 21:12:24 -0600 | commented answer | rsync on root vs package reinstall I don't think the previous answer tackled any of the three specific issues that I raised. Rsync vs clone is a separate issue; I'm happy enough with rsync. Also, I feel that these issues are best served by explicit responses, rather than referencing another webpage, unless that webpage specifically discusses/debates one of the three issues that I am raising. |
2016-02-11 01:10:09 -0600 | received badge | ● Supporter (source) |
2016-02-11 00:52:10 -0600 | asked a question | rsync on root vs package reinstall This is a followup of what I believe to be three open issues re the following query on this forum: rsync boot disk dirs to exclude https://ask.fedoraproject.org/en/ques... Because of my inexperience, one of my replies on that query became mis-positioned, which caused that webpage to be confusing. I'm hoping for responses from several people on this followup query. Issues: (1) Suppose that: a. My boot drive is (device = sda) and my docking station houses a backup hard drive (device = sdc). b. I have already used a recent version of Fedora22 Live to install the (full) Fedora22 on (device = sdc), making sdc bootable. c. I want to maintain sdc as a full backup (i.e. a functional "clone") in case sda goes bad, totally relying on periodic rsync's of the sda-root against sdc to keep sdc current. d. I want to be able to both boot the backup from the docker (position sdc) or replace the original boot disk with the backup, booting the backup in (position sda). e. I want to TOTALLY AVOID having to reinstall any packages. My Fedora 22 boot drive has the following directory structure: .autorelabel, bin, boot, .config, dev, etc, home, lib, lib32, lib64, lost+found, media, mnt, opt, proc, root, run, sbin, srv, sys, tmp, usr, var My tentative list of directories to exclude is: /dev, /home, /media, /mnt, /proc, /run/media, /sys, /tmp, /var/lock, /var/run /home is excluded because I rsync it separately. Under the assumptions of issue (1), I REQUEST DISCUSSION OF DIRECTORIES TO EXCLUDE. (2) In my Linux-inexperience, and focusing on supposition (1)d above, I have speculated that /etc/fstab and /boot/grub2/grub.cfg may need special handling. My intent is: a. On sda, copy /etc/fstab to .../fstab_sda and copy /boot/grub2/grub.cfg to .../grub_sda.cfg. b. Exclude /etc/fstab and /boot/grub2/grub.cfg from the rsync, HOPING that the backup will therefore boot successfully from (position sdc). c. If I want to replace the boot disk with the backup (booting the backup from position sda), I will replace .../fstab and .../grub.cfg with their ..._sda counterparts, HOPING that the backup will therefore boot successfully from (position sda). HAS ANYONE TAKEN THIS APPROACH? DO .../fstab and .../grub.cfg ACTUALLY NEED THIS SPECIAL HANDLING? ARE THERE ANY OTHER FILES THAT NEED THIS SPECIAL HANDLING? (3) My research SUGGESTS that (1) + (2) above are overkill, and that I should abandon the rsync_on_the_root strategy in favor of: a. Only rsync'g /home and /etc. b. Maintaining a list of installed packages with dnf. c. Restoring by using Fedora 22 Live to place the (full) Fedora 22 on a new disk, manually rsync'g /home and /etc on this new disk, and then using dnf to manually re-install the packages to this new disk. d. Periodically checking fedoraproject.org for a newer version of the Fedora 22 (workstation) Live iso. On my system, "dnf history userinstalled" reports only 24 packages since my ... (more) |
2016-02-10 23:31:39 -0600 | commented answer | rsync boot disk dirs to exclude Thanks again for the responses, Florian. My bad re generating a confusing web page. Anyway, the only pending issues are having other people suggest other Fedora 22 dirs to exclude, and the (partly generic, partly Fedora 22 specific) issue of package_re-install vs rsync against the root. I will consolidate the remaining issues into a separate query; LET'S CONSIDER THIS QUERY (WEBPAGE) CLOSED. |
2016-02-10 08:47:44 -0600 | edited answer | rsync boot disk dirs to exclude The web page "re-located" my "answer", which was my response to Florian's comments. Logically, my answer should immediately precede the comment: "Here is how I would do it. Your plan sounds good..." Below given as an answer because I didn't want to split my reply into multiple comments. Very interesting comments, thanks florian. Goals: a. A full backup of my harddrive in case my main one goes bad. b. Ability to boot the backup hard drive from either the docking station (device = sdc) or as a replacement hard disk (device = sda). This gives me flexibility in a restore situation and facilitates "rolling back" the main boot drive (using device=sdc to restore device=sda), in case a "bad" package is installed, without having to open my pc case. c. After booting with the backup harddrive, all installed packages should be present; no need to re-install packages. After reading your comments I have two followup questions: (1) re goal b above, and noting that /boot will be included and /dev excluded from the rsync, I believe that I will need special handling for /etc/fstab and /boot/grub2/grub.cfg. I will probably create fstab_original and grub_original.cfg on my main boot disk (just before each rsync) and then specifically exclude /etc/fstab and /boot/grub2/grub.cfg from the rsync. This should allow the backup to boot from the docking station (device = sdc). If I ever need to swap the backup for the original boot (i.e. move the backup into device=sda), I will first boot Fedora 22 live from a separate flash drive and replace fstab and grub.cfg with their ..._original counterparts, on the backup. Is this workable/practical? Are there other areas that will also need special handling? (2) re goal c above, I was surprised to encounter the following recommendation: rpm -qa | tee installed_packages.list I presumed that all installed packages would automatically be replicated by the rsync. Doesn't that make the above command obselete? What am I missing? |
2016-02-09 17:44:11 -0600 | commented answer | rsync boot disk dirs to exclude The web page "re-located" my "answer", which was my response to Florian's comments. Logically, my answer should immediately precede the comment: "Here is how I would do it. Your plan sounds good..." |
2016-02-09 17:20:38 -0600 | commented answer | rsync boot disk dirs to exclude (4) Continuting the last question, assume that the last package installed is bad, I have uninstalled via (dnf history undo ...), the resulting system is non-bootable, and I successfully repair the system. Does this mean that the repaired system approximates the system just before the last package was installed? If not, is the difference "significant"? |