(resolved) Jessie - CurlFTPfs mount = emergency mode

General Discussion
1

I’ve been trying out DietPi today, and it just isn’t working for me. Here’s my process:

Raspberry Pi 2, 4GB sd w/ v94, ethernet, 2a power supply

Login via SSH
Update to 97, reboot, wait 2 minutes
Login via SSH
USB drive: No, I'm setting this up with Ampache, media on NAS.
Optimized Software: VNC, LAMP, ProFTP
Boot Options: Yes, VNC
Additional Software: Curlftpfs
FTP Client setup now: Yes
Network Options: Static, correct addresses, Apply
Test Network: Online
FTP client: install curl
FTP client: setup, says connected, exit, back to Dietpi-Config
Overclocking: med
Locale: deselect en_gb, select en_us
Timezone: America>New York, exit
Go Start Install
During the Install process, setting locale fails, falls back to default (which shouldn't be an issue).
Set VNC password
Reboots, wait 10 minutes
Connection Refused w/ SSH and VNC

Once it reboots, it goes to emergency mode. Logging in starts an endless loop of echos stating it’s copying to RAM. I let it sit for 40 minutes, with no luck. Please let me know what info you would like for diagnosis. Where is the log stored for the install process? Also, if you’re in any IRC chatrooms please let me know; I think it would be easier to communicate efficiently there, assuming we were both present.

2

Hi Jig,

Thanks for the report and steps you made. It looks like a possible filesystem corruption or failure.

This kind of issue is caused by one of the following:
- SD card corruption.
The SD card is failing, or, a bad image write occurred.

- Unstable PSU
Regardless of amperage, the PSU must provide a constant and stable 5v output. You can check for this by looking for the rainbow square

- System instability
This can be caused by overclocking, or very rarely, faulty hardware on your device.

I would suggest trying a different SD card, and, no overclocking. Also remove any USB devices that draw excess power (eg: 2.5inch USB HDD). Try not to change any settings in dietpi-config (eg: leave DHCP). See if that works.

3

I’ll definitely mess around with it later when I’m back home. It wont be for another 8-10 hours, though.

4

No worries Jig. Just let us know the results when you can.

5

No sign of under-voltage or over-voltage. Nothing is connected other than the ethernet cable. Before I try a new SD (this is my smallest one, and I use my larger ones in my other Pi), I’ll try again without overclocking or as much config changes. I’ll report back once finished.

6

Thanks Jig.
We just need to a get a baseline installation done with default settings. Then we should be able to debug this and find the cause.

7

Trying from Linux this time, instead of Windows. Redownloaded the Jessie zip from the website. Wiped SD in GParted, flashed using dd. This time around I’m connecting a monitor to view what’s happening. On first boot, there are some FAILED messages, however I could not see what they were. Still using SSH to configure. I used the same process as a did previously with these differences:

I did not select anything in Additional software (curl should be installed with ProFTP, and if not, I can add it later).
The only changes I did in DietPi-Config were autoboot to VNC, and FTP Client (which installed curl).

During install, on main console, not SSH:

systemd-fstab-generator: Failed to create mount unit file /run/systemd/generator/mnt-usb_1.mount, as it already exists. Duplicate entry in /etc/fstab? (This appeared a total of 6 times, before the display went black)

Same result :frowning:

fstab:

#Internal Drives---------------------------------------------------
proc            /proc           proc    defaults          0       0
/dev/mmcblk0p1  /boot           vfat    defaults,noatime  0       2
/dev/mmcblk0p2  /               ext4    defaults,noatime  0       1
tmpfs 			/tmp  			tmpfs 	noatime,nodev,nosuid,mode=1777  0 0
tmpfs 			/var/log 		tmpfs 	defaults,size=20m,noatime,nodev,nosuid,mode=1777  0 0
tmpfs 			/DietPi 		tmpfs 	defaults,size=10m,noatime,nodev,nosuid,mode=1777  0 0

#External Drives---------------------------------------------------
# - Try and use only ext4 for USB drives
# - Faster performance than NTFS, espically on RPi v1
/dev/sda1       /mnt/usb_1      ext4    defaults,noatime,nofail  0       0
/dev/sda1       /mnt/usb_1      ntfs-3g    defaults,nofail       0       0

#Samba Client------------------------------------------------------
#/mnt/samba . Please use dietpi-config and the networking menu to setup this mount

#FTP Client Mount--------------------------------------------------
curlftpfs#[user]:[password]@[server] /mnt/ftp_client fuse auto,allow_other,direct_io,transform_symlinks,user,uid=1000,nonempty 0  0
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that

I’m not sure why the External Drives are present. Regardless, I commented them out and it changed nothing.

Do you want me to try again without changing anything in DietPi-Config? I can always install/setup curl/ProFTP later, as well as VNC. Or just try my original process with a different SD?

8

systemd-fstab-generator: Failed to create mount unit file /run/systemd/generator/mnt-usb_1.mount, as it already exists. Duplicate entry in /etc/fstab? (This appeared a total of 6 times, before the display went black)

Gotta love SystemD.
This is nothing to worry about. As you can see from our /etc/fstab file, we use two mounting options for /dev/sda1. It basically ensures a NTFS or EXT4 formatted drive will be automatically mounted. It will try ext4 first, then ntfs. This will not effect your system, regardless of if you have a external drive or not. Its just SystemD saying “I dont think you should use Linux this way, so i’am going to tell you about it!” :wink:

The failed message. Please try running this after boot, this will list any failed services. Let me know what it returns:

systemctl status * | grep fail



Do you want me to try again without changing anything in DietPi-Config? I can always install/setup curl/ProFTP later, as well as VNC. Or just try my original process with a different SD?

Are you still being sent to Emergency mode?
Try another SD card if you can, just to be sure. Also, dont select, or install any software. Just run through the DietPi 1st run setup and select “go start install” when Dietpi-software appears.

9

Good to know, thank you!

Unfortunately I’m still in emergency mode, so I cannot do that.
Notable entries:

Failed to mount /mnt/ftp_client.
Dependency failed for Local File Systems.



Okay, I’ll try another SD card, without any special selections. If that works, I’ll report here and then try adding software one at a time.

Also, I’m on #dietpi on Freenode if you want to migrate there.

EDIT: Apparently, my other 2 SD cards are corrupt beyond repair. My working cards are already deployed and I’m unwilling to risk losing them. I’m going to try with this SD card again, without installing any software.

10

I’ll join that IRC channel tomorrow as i’am off for the evening. This will also allow us to run some tests on your if needed.

I’am 99.9% certain that if you use a “tested and working” sd card, you wont be sent into emergency mode. What brand SD cards are you using? Sandisk never fail for me, yet, generic brands fail regularly.

11

I’m using a Sandisk, which has worked for me in the past with other distros (although I have not used it for months prior to this). Surprisingly, my two 8gb cards that are suddenly not working are Samsung cards, of which I have identical cards deployed and working. I’ll let you know what happens with the default install on the Sandisk.

12

Attempting with the same SD card.

Install without any optimized/additional software worked fine.
Chose LAMP from the optimized section, rebooted without issue.
Chose ProFTP from optimized section, rebooted without issue.
Chose VNC from optimized section, chose not to change auto boot settings, rebooted without issue.
Dietpi-Config > Networking > FTP Client > install curl > FTP Client, setup server. Would not start up after reboot!

I’ve isolated the problem to curl!

Relevant issue: https://bugzilla.opensuse.org/show_bug.cgi?id=943146
It looks as if Comment 8 has a solution that could be applied to the install process.

I’ll let you implement the mount-unit, but as a temporary “fix” for emergency mode, I made sure “nofail,x-systemd.device-timeout=1” was appended to the appropriate lines in dietpi-set_curlftpfs, which unfortunately did not work for a fresh install. I added those options in my fstab post-install, though, and that worked.

EDIT: Yup, the issue is with mounting the ftp drive on boot. After adding nofail to my fstab, I was able to boot. I connected to VNC and confirmed that the ftp drive did not mount properly. I reconfigured FTP through dietpi-config on the VNC desktop, and it connected fine. I rebooted to see if it held (which lead to emergency mode, fixed by manually editing fstab), and I can now say with certainty that dietpi-set_curlftpfs is the culprit. I’ll hold off on deploying the server so I can test a fresh install once you’ve taken a (f)stab at this. :stuck_out_tongue:

EDIT2: I just changed the timeout option to 30 seconds, and it still wasn’t connected to the server. I thought the issue was that it just needed time to authenticate and connect, but that was not the issue. There’s something preventing it from correctly mounting at boot.

EDIT3: Pictsidhe had the same issue in his thread. I hadn’t tried DietPI prior to this week, so I can’t confirm, but if this issue is just popping up it’s likely related to a recent change.

13

Hi Jig,

Excellent debugging in this issue, cant thank you enough!

As per my post: https://dietpi.com/forum/t/resolved-jessie-curlftpfs-mount-emergency-mode-dupe/129/8 i’ll run some tests and let you guys know what happens.

14

Curlftpfs does not support “nofail”

root@dietpi:~# mount -a
fuse: unknown option `nofail'

Comment 8 and Comment 10 both work. I personally prefer using _netdev as the resolution. This seems to be the “correct” and working method across multiple distros (eg: Wheezy/Jessie/Ubuntu)

Resolution:
I’ve updated dietpi-set_curlftpfs and dietpi-set_smbclient to use _netdev /etc/fstab mount attributes when its created.

This will be available in v98. I’ll also create a patch to update existing network mounts to add _netdev.

Thanks again Jig for your assistance debugging and research, made fixing this issue alot easier :slight_smile:

15

Great! I’m glad you were able to figure it out. No problem; thank you for DietPi! It makes deployment extremely easy. Will you be doing an img release of v98? I’m more than willing to test out a fresh install.

16

DietPi has an update system which does not require you to use a new image each update.

When v98 is released, you will be informed during login. You then simply run dietpi-update and your current system will be patched to v98.

For new image installations:
As DietPi automatically updates during 1st run setup, regardless of the image version you have used, it will always update to the latest version.

v98 Should be later today, just got a few things to finish off before committing to master branch (live)

17

Yes, I’m aware; I just wanted to test out setting it up like I had originally attempted. I’ll just prepare my SD with v94 now, so it’ll update before initial setup. Looking forward to the release, I’ll keep an eye on Github.

EDIT: I see you fixed the keyboard setting issue too!