[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: avoiding the "press control+D to continue" when there is a minor problem





Le 29.07.2014 16:27, Darac Marjal a écrit :
On Tue, Jul 29, 2014 at 02:57:04PM +0200,
berenger.morel@neutralite.org wrote:
Hello.

I tried the idea exposed by PaulNM here to fix an inode exhaustion:
https://lists.debian.org/debian-user/2014/07/msg01588.html

My implementation seems to be wrong, and I was not smart enough to try on a normal desktop. Plus, I had to reboot it because of a kernel version problem (the booted version was not the correct one, the needed virtualbox module
was not existing).
So, when rebooting it, the computer went to the "type root password or control+D to continue", which made me unable to use it without a physical access, because it was not able to find /var/cache/apt-cacher-ng.img (I guess it is because it tries to mount everything at the same time, and that it's not sequential, so /var is still empty. I should be able to find a
workaround for this.).

So, is there is any way to avoid being stuck in this step, to make the system at least try to boot? I know that it would probably imply probably a lot of flaws, and that it would probably be a wrong idea, but I am curious
about that.

According to the manpage of fstab, mount, fsck et al iterate through the entries in /etc/fstab. It follows, therefore, that the entry for mounting
/var/cache/apt-cacher-ng.img should be placed *after* the entry for
/var.

Systemd uses it's own logic for mounting,

I know that I'm using testing/unstable on that computer, but I have found no systemd package except id128-0 and journal0. I guess it's still running sysvinit (and I did no effort on it for that) but you make me doubt. How can I check this?

I believe, wherein all mounts
are *attempted* concurrently.

When systemd was new, I read some docs from official sources and, IIRC, systemd mount filesystems when they are needed the first time. Is this information obsolete, or do I remember wrong things?

Dependent mounts will initially fail, but
will resolve as the lower layers mount. There is, however, a known
bug[1] with remote filesystems but I don't think it will apply in your
case.

A final option would be to add "noauto" to the fstab options so
that the mount is not performed at boot time. You should, however, mount
the filesystem yourself before using it.

[1] https://wiki.ubuntu.com/systemd#Remote_filesystem_mounts-1



--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org with a subject
of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: [🔎] 6f98dcb55fdce4c03388e99199c44bd5@neutralite.org">https://lists.debian.org/[🔎] 6f98dcb55fdce4c03388e99199c44bd5@neutralite.org



Reply to: