I'm using zfs on a generic Ubuntu 18.04 system. Everything works fine when creating and mounting file systems using normal mountpoints.
However, I have a use case that would be helped if I could use legacy mounts that auto mount at boot time.
If I set my legacy mount as noauto and then manually mount after startup, everything works fine.
But when I remove noauto, I fail to automatically mount at boot. It's obvious what the problem is - during startup the attempt to mount the drive is taking place before the ZFS modules are loaded:
$ systemctl status home-vagrant.mount
● home-vagrant.mount - /home/vagrant
Loaded: loaded (/etc/fstab; generated)
Active: failed (Result: exit-code) since Thu 2020-04-30 11:41:07 PDT; 24s ago
Where: /home/vagrant
What: vagrant
Docs: man:fstab(5)
man:systemd-fstab-generator(8)
Process: 464 ExecMount=/bin/mount vagrant /home/vagrant -t zfs (code=exited, status=2)
Apr 30 11:41:07 ubuntu mount[464]: The ZFS modules are not loaded.
Apr 30 11:41:07 ubuntu mount[464]: Try running '/sbin/modprobe zfs' as root to load them.
Apr 30 11:41:07 ubuntu systemd[1]: home-vagrant.mount: Mount process exited, code=exited status=2
Apr 30 11:41:07 ubuntu systemd[1]: home-vagrant.mount: Failed with result 'exit-code'.
Apr 30 11:41:07 ubuntu systemd[1]: Failed to mount /home/vagrant.
Of course, later in the boot process the ZFS modules are loaded and it can be mounted properly. I can see the two events in the boot printout, it's pretty obvious what the problem is - but not the fix.
I haven't been able to find a simple how-to for dealing with this. From what I can see, it seems like installing zsh-initramfs is supposed to help with this - but how?
What little information is floating around out there seems to primarily deal with using zsh for the root file system, and in many cases that is a lot more complicated.
Part of the use case might clear up why I want legacy mounts - I have bind mounts that are being mounted in the ZFS file system. So a workaround would be to use links instead of mounts - and if I can't solve this problem that's what I'll do.
But it seems like this should be doable!
One possible workaround is to load zfs kernel modules in your initrd.
I'm not sure about Ubuntu, but on CentOS/Fedora, you could add a script to /etc/sysconfig/modules that executes really early on, as soon as the rootfs is mounted. You may want to look at whether there is an analogue in Ubuntu.
Related
After installing zfs the following output is returned when running zfs list:
user#machine:~$ zfs list
The ZFS modules are not loaded.
Try running '/sbin/modprobe zfs' as root to load them.
user#machine:~$ sudo /sbin/modprobe zfs
modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.19.84-microsoft-standard/modules.dep.bin'
modprobe: FATAL: Module zfs not found in directory /lib/modules/4.19.84-microsoft-standard
How to user zfs with WSL2?
Essentially, this error occurs because the ZFS Modules need to be built into the kernel, and the WSL2 kernel does not currently have ZFS Modules included. Thankfully, there is a great tutorial on wsl.dev that covers manually building the kernel with ZFS. I don't fully understand how it works, but just following the steps was easy enough: https://wsl.dev/wsl2-kernel-zfs/
Took me about 2 hours to walk through, but I did a bunch of research along the way ;)
I am starting a fresh app with react-native, and following the getting started tutorial here. I have installed Android Studio, the sdk and avd files, and the react-native init seems to work ok...
react-native init myapp
>>
Installing React...
Installing Jest...
npm WARN deprecated minimatch#2.0.10: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
Then I try and run the app
react-native run-android
And it just hangs there (even left it overnight).
If I do an strace
...lots of stuff then
read(12, "HTTP/1.0 200 OK\r\nServer: Motion/3.2.12+git20140228\r\nConnection: close\r\nMax-Age: 0\r\nExpires: 0\r\nCache-Control: no-cache, private\r\nPragma: no-cache\r\nContent-Type: multipart/x-mixed-replace; boundary=--BoundaryString\r\n\r\n", 65536) = 217
epoll_wait(5, [{EPOLLIN, {u32=12, u64=12}}], 1024, -1) = 1
read(12, "--BoundaryString\r\nContent-type: image/jpeg\r\nContent-Length: 4235\r\n\r\n\377\330\377\340\0\20JFIF\0\1\1\0\0\1\0\1\0\0\377\341\0\224Exif
And then keeps cycling with the line...
read(12, "--BoundaryString\r\nContent-type: image/jpeg\r\nContent-Length: 4235\r\n\r\n\377\330\377\340\0\20JFIF.....
I have tried things like reinstalling react-native, the sdks etc, but error persists.
I have also seen a similar error linked to watchman with react-native init, but I don't think this would apply, as I don't currently have that installed (have tried with it installed previously).
I am using Linux Mint 18
4.4.0-51-generic #72-Ubuntu SMP Thu Nov 24 18:29:54 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Ok, it was a camera application using port 8081 that was causing the issue.
If I kill that process it works. I checked the ports in use by
netstat -tulpn
look for port 8081 in there, then
kill -9 <pid>
Assuming it's something you are happy not to have running, and change its config.
Would be handy if react-native checks for a port in use and reports it if it is, to save others having the same issue.
If you're on Windows, you can try:
Ctrl + Alt + Delete to bring up the Task Manager
Select the "Node.js: Server-side Javascript" process
Click the "End Task" button
Then try the react-native run-android command again.
I hope it helps.
ran from Command Prompt as Administrator (that got the react-native start to run)
Then in the other command prompt when run-android I got after an extremely long wait: Could not determine java version from 10.
I upgraded gradlew in the [project]/gradle/wrapper/gradle-wrapper.properties to
distributionUrl=https\://services.gradle.org/distributions/gradle-4.3-src.zip
Then waited a long time for it to finish, seemingly doing nothing.
Got a filenullpointer exception in findLauncherJar...
Read further and changed to
distributionUrl=https\://services.gradle.org/distributions/gradle-4.3-all.zip
Then it hung with a message:
gradle refresh failed could not find com.android.tools buildg
Found SO 38702032 which suggested changes to the file Android/build.gradle and corrected the gradle version to 4.3.0
Got another error and went to http://jcenter.bintray.com/com/android/tools/build/gradle/ to see what versions existed. Found that the last was 2.3.3
Put it back to what it was and added mavenCentral
Also checked that I have the paths (C:\Users\MyUsername\AppData\Local\Android\Sdk\platform-tools;C:\Users\MyUsername\AppData\Local\Android\Sdk\tools)
and the three environment variables (c:\program files\java\sdk-10) and that I have the two ANDROID_HOME and ANDROID_SDK_HOME (c:\users\MyUsername\AppData\Local\Android\Sdk) ...
rebooting and works.
Our hard disk, with Mageia 3, got a bad block problem. We can still read it, but not boot on it. I installed this disk as secondary disk (on another computer working with Fedora 20 Gnome). I would like to save the databases (containing Drupal websites) of the old disk, so I installed mariadb and phpmyadmin packages on a new booting hard disk with Mageia 4, set up the same password as for the old disk (I don't know where MariaDB password is stored), copied the configuration file /etc/my.cnf and the folder /var/lib/mysql to the new disk. But mysqld refuses to start. I get
# systemctl status mysqld.service
mysqld.service - MySQL database server
Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled)
Active: failed (Result: start-limit) since Wed 2014-03-12 18:08:35 ULAT; 2s ago
Process: 20618 ExecStartPost=/usr/sbin/mysqld-wait-ready $MAINPID (code=exited, status=1/FAILURE)
Process: 20245 ExecStart=/usr/bin/mysqld_safe --nowatch (code=exited, status=0/SUCCESS)
Process: 20228 ExecStartPre=/usr/sbin/mysqld-prepare-db-dir (code=exited, status=0/SUCCESS)
Main PID: 20617 (code=exited, status=1/FAILURE)
Mar 12 18:08:35 Dell-graphist systemd[1]: Failed to start MySQL database server.
Mar 12 18:08:35 Dell-graphist systemd[1]: Unit mysqld.service entered failed state.
Mar 12 18:08:35 Dell-graphist systemd[1]: mysqld.service holdoff time over, scheduling restart.
Mar 12 18:08:35 Dell-graphist systemd[1]: Stopping MySQL database server...
Mar 12 18:08:35 Dell-graphist systemd[1]: Starting MySQL database server...
Mar 12 18:08:35 Dell-graphist systemd[1]: mysqld.service start request repeated too quickly, refusing to start.
Mar 12 18:08:35 Dell-graphist systemd[1]: Failed to start MySQL database server.
Mar 12 18:08:35 Dell-graphist systemd[1]: Unit mysqld.service entered failed state.
Or is it better, in my Fedora computer, to configure MariaDB to read the old disk databases and to produce a .sql file? If so, how to configure MariaDB for this ?
Thank you if you can help.
biz -- I think you can try to do the dump following this method:
MYSQLDUMP without the password prompt
If you have access to the file system and server, you can use dump to put the database stuff some where ready for recovery.
I'm not sure if this approach also works when starting the daemon. It is worth a try if you are still wanting to save your stuff.
Another less 'interesting' option is to do a deep copy of the whole mysql/mariadb folder. You need to change ownership of the target folder after copying to be "mysql:mysql" and change your mysql config to point to the new location.
Use start and see if the server will come-up on the cloned directory? You may still find problems on some queries if there's a hole in the (origin) disk. Either way you ought to be able to just dump to a text file stream as long as you get a server working.
I've deployed Solr in Jetty 9.0.6 on a Debian machine and sometimes when i try to start it up, it fails without giving me any clues why. The <>.stderrout.log file is allways empty.
How could I enable logging or verbose output for the start operation?
I'm doing:
$ sudo service jetty start
Starting Jetty . . . . . . . FAILED Tue Oct 15 11:10:18 CEST 2013
thanks!
With Jetty 9.0.6 you pass into the part of your service that calls ${jetty.home}/start.jar the extra --daemon command line variable and look for the start.log files. (These files are usually found at the ${jetty.logs}/start.log location.
Along with that, also include the -DDEBUG=true to enable debug of the startup process, as well as enabling the debug on Jetty itself (until the actual logger kicks in).
Finally, if you want the default Jetty StdErrLog to log at debug level too, add the -Dorg.eclipse.jetty.LEVEL=DEBUG to the command line as well.
To put this in non-service terms ...
[jetty-distribution-9.0.6.v20130930]$ java -jar start.jar --daemon -DDEBUG=true -Dorg.eclipse.jetty.LEVEL=DEBUG
As for how to do that with a debian service, I have no clue.
Something that I've noticed recently on two different machines is that Apache2 installed via MacPorts seems to have stopped launching when I boot up. The honest truth is that I can't swear it did so before, but it's something I think I'd notice because installing the LaunchDaemon is part of my install process. In fact, if I try to reload the LaunchDaemon, it fails:
$ sudo launchctl load -w /Library/LaunchDaemons/org.macports.apache2.plist
org.macports.apache2: Already loaded
Unless I start Apache manually (using sudo apachectl restart), grep'ing for either "apache2" or "httpd" in my process list only produces this:
$ sudo ps -ef | egrep "apache2|httpd"
0 52 1 0 0:00.06 ?? 0:00.08 /opt/local/bin/daemondo --label=apache2 --start-cmd /opt/local/etc/LaunchDaemons/org.macports.apache2/apache2.wrapper start ; --stop-cmd /opt/local/etc/LaunchDaemons/org.macports.apache2/apache2.wrapper stop ; --restart-cmd /opt/local/etc/LaunchDaemons/org.macports.apache2/apache2.wrapper restart ; --pid=none
1410639199 6960 6792 0 0:00.00 ttys001 0:00.00 egrep apache2|httpd
Looks like the daemon itself is in place, but no executable. As far as I know/can tell, the relevant executables (httpd and apachectl) are executable by everyone.
Has anyone else noticed this? Any ideas?
UPDATE
As requested below, I did execute launchctl list. The list is long and I'm not sure how to snip it, but suffice to say that no org.macports.* items are listed. That in itself is interesting because my MySQL daemon is loaded the same way. It works, but also doesn't appear in the list. Let me know if the entire output is really needed.
UPDATE
I assumed that I had executed launchctl list under sudo, but prompted by mipadi's comment below, I tried again ensuring that I did so and I assumed incorrectly. When executed under sudo, the MacPorts items appear:
51 - org.macports.mysql5
52 - org.macports.apache2
I'm not sure whether that will help, but it's a little more info nonetheless.
UPDATE
I've asked a different, but related, question at LaunchDaemons and Environment Variables. I'll update both questions as I learn more.
UPDATE
Today, based on mailing list input, I tried using a wildcard home directory. Academically, it's a little more inclusive than I'd like, but the practical reality is that I'm the only one using this computer; certainly the only one who'd have Apache config files laying around.
Include "/Users/*/Dropbox/Application Support/apache/conf.d.osx/*.conf"
Include "/Users/*/Library/Application Support/MacPorts/apache/conf.d/*.conf"
Unfortunately...
httpd: Syntax error on line 512 of /opt/local/apache2/conf/httpd.conf: Wildcard patterns not allowed in Include /Users/*/Dropbox/Application Support/apache/conf.d.osx/*.conf
I found my answer to this problem here:
https://trac.macports.org/ticket/36101
"I apparently fixed this when changing my local dnsmasq config. In /etc/hosts I added my servername (gala) to the loopback entry:
127.0.0.1 localhost gala
and then I changed ServerName in /opt/local/apache2/conf/httpd.conf to match:
ServerName gala
Apache now starts at boot for me."
Since I now know why Apache has stopped loading on startup, I'm going to articulate that answer and mark this question as answered. The reason Apache has stopped launching on boot is that I'm trying to share an httpd.conf file across systems. The config file needs to Include files from directories that exist within my home directory. Since the home directory is different on each machine, I was trying to reference the ${HOME} environment variable.
This works fine when manually starting after the machine is booted, but fails on startup because the environment variable isn't yet set. As mentioned above, see this question for more information.
Rob:
Had the same problem: "sudo launchctl load -w ..." started Apache2 while I was logged in, but did not work during startup (the "-w" should have taken care of that). Also, as you noticed, the daemon seems to be registered with launchctl. It will show up with "sudo launchctl list" and another "sudo launchctl load ..." will result in the error message.
I played with "sudo port load apache2" and "sudo port unload apache2", but could not get httpd running on reboot.
In the end, I got rid of the MacPorts startup item: "sudo port unload apache2", checked with "sudo launchctl list" that org.macports.apache2 is no longer registered for startup.
Afterwards, I followed the steps on http://diymacserver.com > Docs > Tiger > Starting Apache. I only had to adapt the path from /usr/local/... to /opt/local/...
Now the MacPorts Apache2 is starting fine with every reboot.
Good luck, Klaus
I found that my MacPorts apache2 was not starting on boot because of an “error” in my httpd.conf.
I was using
Listen 127.0.0.1:80
Listen 192.168.2.1:80
Listen 123.123.123.123:80 # Example IP, not the one I was really using
And in Console.app I was seeing
4/8/12 4:59:06.208 PM org.macports.apache2: (49)Can't assign requested address: make_sock: could not bind to address 192.168.2.1:80
4/8/12 4:59:06.208 PM org.macports.apache2: no listening sockets available, shutting down
4/8/12 4:59:06.208 PM org.macports.apache2: Unable to open logs
I tried adjusting permissions on all the log folders (despite the fact that logs were being written just fine when I manually started apache2) and that didn't help.
Even though the Apache Documentation for Listen clearly states
Multiple Listen directives may be used to specify a number of addresses and ports to listen to. The server will respond to requests from any of the listed addresses and ports.
I decided to try switching back to just using
Listen 80
And after doing so apache2 is starting on boot with no errors or warnings.
If you're using Subversion with Apache, you may find that Apache is not starting because the mod_dav_svn.so file has moved to /opt/local/libexec. You'll need to adjust your Apache startup files to account for the new location of this file.
In newer versions of MacPorts you can run sudo port load apache2 to instruct MacPorts to take care of the launchctl setup and automatically start the process. To stop the process run port unload.
After loading check /opt/local/apache2/logs/error_log for errors, including configuration issues.
In addition to my previous answer I have also found that sometimes Apache fails to start because something else with the system is not yet ready.
On one OS X Server machine I also use the DNS to create a “internal only” DNS name for the machine and that name is used in my Apache configuration. Sometimes when Apache tries to start the DNS server is not yet ready and Apache fails to load because the hostname isn’t valid.
I have also seen this on other non-Server systems without local DNS as well where something else required by Apache must not be ready yet.
One thing that has worked is to edit the apache2.wrapper located at /opt/local/etc/LaunchDaemons/org.macports.apache2/apache2.wrapper that MacPorts’ daemondo uses to start up Apache.
Edit the Start() function to add a sleep command to wait a bit before launching Apache.
Original (Lines 14-17 on my machine)
Start()
{
[ -x /opt/local/apache2/bin/apachectl ] && /opt/local/apache2/bin/apachectl start > /dev/null
}
With wait time added
Start()
{
[ -x /opt/local/apache2/bin/apachectl ] && sleep 10 && /opt/local/apache2/bin/apachectl start > /dev/null
}