Fucking LMAO
3 Likes
He still keeps courses
1 Like
2 Likes
On systemd, no.
On sysv, maybe creates a scheduled cron job.
Why do you ask?
Want to set up a service or two to start on boot.
But want a simple way to check to see if a shutdown/reboot (after the boot) gets scheduled so starting the service can be cancelled.
You could write your own small daemon that uses entr to detect changes to /run/systemd/shutdown/scheduled .
1 Like
so that file is created/ modified for when a shutdown is scheduled?
edit:
THanksā¦ it IS!!!
Hey all,
Iām trying to set up Gnome Boxes to store the virtual machine images on a secondary HD I have mounted on my Fedora 30 install.
I already have the second HD auto mounted via fstab to /drives/sshd-data/ and have been using a āVirtual Machinesā directory here for Virtual Box to store its VMs for some time.
drwxr-xr-x. 3 shecks shecks 4096 May 2 00:07 gnome-boxes
drwx------. 2 root root 16384 Apr 11 13:16 lost+found
drwxr-xr-x. 12 shecks shecks 4096 May 1 23:46 'Virtual Machines'
Iād like to do the same for the Gnome Boxes VMs so I have created a gnome-boxes directory and a new symbolic link to point the default Gnome Boxes storage directory to the new one.
ln -s /drives/sshd-data/gnome-boxes ~/.local/share/gnome-boxes
I can see that Gnome Boxes is able to write to the directory so the symbolic link is working but I am getting a permissions error when qemu tries to start the VM image.
gnome-boxes:4566): Boxes-WARNING **: 15:16:14.734: machine.vala:633: Failed to start Fedora-Xfce-Live-x86_64-30-1: Unable to start domain: internal error: process exited while connecting to monitor: 2019-05-02T14:16:14.707658Z qemu-system-x86_64: -drive file=/home/shecks/.local/share/gnome-boxes/images/boxes-unknown,format=qcow2,if=none,id=drive-sata0-0-0,cache=writeback: Could not open '/home/shecks/.local/share/gnome-boxes/images/boxes-unknown': Permission denied
I initially thought that it was because it could not write to the new directory but it has been able to create an āimagesā sub folder in /drives/sshd-data/gnome-boxes/
When I run Gnome Boxes using the default image path everything works as expected so I reckon Iāve screwed up how the second drive is mount or the directory permissions.
I use the following in /etc/fstab to auto mount the drive
/dev/mapper/fedora--sshd-data /drives/sshd-data ext4 defaults,x-systemd.device-timeout=0 0 2
Do I need to specify further permissions here? Iāve read about adding default user and group permissions for the drive via the uid, gid and umask options.
Currently I need to use sudo to create directories on the drive then chown to changed ownership, could this be the issue? Should I try setting the ownership in the fstab options?
EDIT: I am thinking that whatever user QEMU is running under needs read/write access to the directory, but I figured that might be root so should have access?
Does anyone have any ideas on what might be going on?
Thanks.
Unmount.
Create a temp VM to see if it works.
If so note the owners and permission.
1 Like
Still no luck, when I unmount the drive Gnome Boxes starts but complains that it canāt connect to the virtual machine backend.
When I mount the drive I can open Gnome Boxes and attempt to create a new VM but when it starts it gives me the permissions error.
I have checked the directory and it is creating an image file in the images directory
[shecks@red-dwarf images]$ pwd && ll
/home/shecks/.local/share/gnome-boxes/images
total 196
-rwxr--r--. 1 shecks shecks 196928 May 2 23:14 boxes-unknown
Then when it tries to start the VM with QEMU it gives the permissions error:-
qemu-system-x86_64: -drive file=/home/shecks/.local/share/gnome-boxes/images/boxes-unknown,format=qcow2,if=none,id=drive-sata0-0-0,cache=writeback: Could not open '/home/shecks/.local/share/gnome-boxes/images/boxes-unknown': Permission denied
I see that the boxes-unknown image file has been created with read-only access for everyone but me. I would assume that QEMU is trying to open the file for at least read and write and as some other user so wonāt have write access.
ohā¦ I was assuming it was working before you tried your linking folders stuff.
Oh, sorry it was working with the default folder. I thought you meant just to umount the drive and see if Gnome Boxes can create its file in the empty /drives/sshd-data mount point
Iāll delete the symlink and give it another go and see if there are any differences in the permissions of the files it creates in the default location.
1 Like
I smell selinux.
Hi, guy, 's I am having trouble changing ownership of a directory in Ubuntu 19.04. The directory owner currently is root. I what to change the owner but keep the current group. I also want to use the -R option and make sure all files and directories are owned by the new owner. I tried searching the web but as usual, the commands I am typing are not doing what I want. They either seem to work and donāt change anything or I get errors. I am trying to change a directory which is currently owned by root to my account name which is shadowbane.
I have tried typing sudo chown -R shadowbane media or several adaptations, and I seen to still not able to accomplish what I want.
Is the directory youāre trying chown a mount point to a USB drive?
If not, and you want to change the directory and all itās content and subdirectories and their content typically Iād do
chown -R user.group /path/to/dir
1 Like
The verbose (-v) switch might provide some feedback and give you a clue as to why it is failing.
Also realise that removable/mounted media may have been formatted with a filesystem (e.g. fat32) that does not support Linux file permissions. If thatās the case then you can either reformat the drive with a filesystem that does support Linux permissions, or edit your /etc/fstab to mount the media with the ownership and permissions you want.
/etc/fstab example:
UUID=blah /media/me/MyDrive vfat defaults,uid=1000,gid=123,umask=0022 0 0
2 Likes
Thanks Level1 and Cotton for your help I think you are right the problem is I am trying to share files that are on a disk with Windows file system. I think the correct way to accomplished what I want is to setup a samba server.
I have a small problem on a Fedora 30 workstation machine using Gnome. The machine is upgraded from Fedora 29. I get notifications in my top bar that my home directory is full and that i need to clean up some space. I can click the notification and the Disk Usage Analyzer opens and this indicates that home is full (the bar in front of home is full and red).
But when I run df-h I get the following output:
So iām puzzled. df-h suggest that is have diskspace enough for a home directory to grow. I also checked the inodes (per googles search results) and that also is looking fine to me.
And I checked /etc/fstab for a hint of quotaās but there are none as far as I can tell:
Any suggestions on how to solve this? Sidenode: It does look like Fedora cannot save information after these notifications. After a reboot (did you try turning it off an on again) I lost some data I saved (Nautulis bookmarks).
You can use various LVM commands to change the size of logical volumes. Doing so, however, does not change the underlying filesystem metadata to make it aware that it is on a larger logical volume (block device). For that task there is resize2fs.
You probably need to do something like:
sudo resize2fs /dev/mapper/fedora-home
But I strongly suggest that you research the use of resize2fs in conjunction with lvm before doing so.
e.g. https://www.tldp.org/HOWTO/LVM-HOWTO/extendlv.html
Whenever messing around with filesystems, the usual caveats apply.
PS: When extending a LVM volume, you should use the -r switch (i.e. lvextend -r ...) to have the filesystem resized at the same time ā thereby avoiding the need to run resize2fs after the fact.
Analogy: A farmer is experiencing stock crowding, so he buys some of his neighbourās land. The new farm looks bigger on paper, and should solve the crowding problem, but until the farmer reconfigures his fences and gates, he canāt use any of the new land ā and his cows are stuck in the same crowded paddocks they were prior to the expansion. lvextend works on the ātitleā level; resize2fs works on the āpaddockā level. lvextend -r works at both levels.