on my old laptop, suddenly booting hangs with the last line
Reached target remote file systems
haven’t been using the laptop for a while, it was booting well before and I can’t remember of having installed any updates.
Would be great if anyone could give ma a hint on how to boot again.
Is this laptop booting in UEFI mode, or using legacy GRUB / MBR ?
Please tell a bit more about that laptop 
Why I’m asking this:
You say that it’s an old laptop. So the battery probably isn’t that healthy anymore.
You furher say that you didn’t use the laptop ‘for a while’ - how long?
Now a possible problem resulting from this is that due to the loss of power on that old laptop some data may have been lost, which could become relevant if it boots in UEFI mode.
May be.
On 2015-05-14 12:26, suse paul wrote:
>
> on my old laptop, suddenly booting hangs with the last line
> Reached target remote file systems
How long did you wait?
If the system is waiting for a remote filesystem to mount (nfs) it will
wait for some thing like 3 minutes per mount.
Another possibility is graphical system not working, but then you would
get a text prompt.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
the laptop is from pre-UEFI-times (32 bit) , so legacy grub/MBR
the battery is bad, the laptop was nearly constantly connected to power. for a few weeks.
If booting proceeded that far, shouldn’t only data on the hard disk be relevant that doesn’t depend on the battery???
there are no NFS mounts established.
I waited for many hours.
Did you try to press Alt-F1 and then ENTER?
The BIOS battery can go bad on old machines.
Did this machine mount any partition that were from the network?
Show cat /etc/fstab
Hi Paul, hi all!
You’re probably right.
I just had in the back of my mind that on UEFI systems some information is stored in some special RAM located directly on the motherboard.
Such information then could get lost if there is no more power supply (which in some cases may even be desirable).
Doesn’t seem to be the case for you
From your 1st posting:
The term ‘remote’ is a bit strange here.
But I just checked my own startup messages using ‘dmesg’.
Result: I just get almost the same
5.089911] systemd[1]: Starting Remote File Systems.
and I’m booting from my internal HDD only, with no network drives even ever mounted or accessed from my PC.
Obviously, the term ‘Remote’ in this message thus seems to be quite misleading … ::\
From your brief description I would guess that it’s a hardware error.
OK, it may not be caused by missing power supply.
But what about bad or oxidized contacts at plugs?
What about a failure of your HDD?
Clearly not a nice perspective, but since you said that you even didn’t make any updates, what else could explain the behaviour that you observed?
Did you try to boot a Live-Linux or to boot from an external (USB) HDD and access the internal HDD of your PC/laptop then?
Good luck
Mike
On 2015-05-16 00:56, ratzi wrote:
> You’re probably right.
> I just had in the back of my mind that on UEFI systems some information
> is stored in some special RAM located directly on the motherboard.
RAM? I would think it would be Flash.
> and I’m booting from my internal HDD only, with no network drives even
> ever mounted or accessed from my PC.
>
> Obviously, the term ‘Remote’ in this message thus seems to be quite
> misleading … ::\
Well, no, the service runs for everybody; it first checks if there is
some network share, aka remote filesystem, to mount. If there is
nothing, it exits immediately.
Of course, the messages could be more clear, like saying that there are
no remote mounts.
So… it probably prints the message, exits, and then halts at the next
service before this one prints anything.
The message is misleading in that the problem is not there 
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
Hi Carlos!
Nice explanation
Yes, based on your posting I could well explain a message like ‘Starting Remote File Systems’.
But there are a few messages on that ‘Remote’ file system (I never used network volumes) in the startup messages of my PC:
5.089809] systemd[1]: Starting Remote File Systems (Pre).
5.089895] systemd[1]: Reached target Remote File Systems (Pre).
5.089911] systemd[1]: Starting Remote File Systems.
5.090051] systemd[1]: Reached target Remote File Systems.
The term ‘Remote’ in this, which as well is part of the title of this thread, may have triggered two of the above answers in this thread, asking about NFS volumes, I guess.
Anyway.
Best wishes
Mike
On 2015-05-16 03:56, ratzi wrote:
>> Well, no, the service runs for everybody; it first checks if there is
>> some network share, aka remote filesystem, to mount. If there is
>> nothing, it exits immediately.
> Nice explanation
Thanks
> Yes, based on your posting I could well explain a message like ‘Starting
> Remote File Systems’.
>
> But there are a few messages on that ‘Remote’ file system (I never used
> network volumes) in the startup messages of my PC:
>
>
> Code:
> --------------------
> 5.089809] systemd[1]: Starting Remote File Systems (Pre).
> 5.089895] systemd[1]: Reached target Remote File Systems (Pre).
> 5.089911] systemd[1]: Starting Remote File Systems.
> 5.090051] systemd[1]: Reached target Remote File Systems.
> --------------------
Mmm. So there are actually two services, one named “Pre”. I don’t know
why two. And each one triggers two messages, one at the start, one at
the end of the “job”.
> The term ‘Remote’ in this, which as well is part of the title of this
> thread, may have triggered two of the above answers in this thread,
> asking about NFS volumes, I guess.
Yes, of course.
When you see such a message, or rather when somebody says he saw it, it
is rather unclear if the service finished or not, and it is stuck waiting.
The timeout for an NFS mount, which is one of the possible remote
filesystems (another would be a samba share, I believe) is about 3
minutes. Many people hit the power button in desperation.
So it was a possibility… till he said he had waited hours.
>
> Anyway.
>
> Best wishes
> Mike
Same!
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
I could boot a live system from a USB-Stick and access the HDD.
ALT-F1 gives a different page
close to the top there is a page stating “…end trace …”
many lines that don’t look suspicious to me.
some lines with “ata1…” e.g “configured for UDMA/100”
some lines with “sd…”
e.g "scsi 0:0:1:0: attached scsi generic sg1 type 5
sda: sda1 sda2 < sda5 >
sd 0:0:1:0: [sda] attached SCSI disk
ALT-F7 gives a page with th green wave-like screensaver pattern. it doesn’t react to any keyboard or mouse action.
is there any further info I can provide for “elucidation”?
On 2015-05-19 17:46, suse paul wrote:
> I could boot a live system from a USB-Stick and access the HDD.
>
> ALT-F1 gives a different page
Is that the live or the system? I’ll assume the system.
> close to the top there is a page stating “…end trace …”
You had a kernel Oops.
> many lines that don’t look suspicious to me.
> some lines with “ata1…” e.g “configured for UDMA/100”
> some lines with “sd…”
> e.g "scsi 0:0:1:0: attached scsi generic sg1 type 5
> sda: sda1 sda2 < sda5 >
> sd 0:0:1:0: [sda] attached SCSI disk
And it stops there? No more? What happens if you press enter?
> ALT-F7 gives a page with th green wave-like screensaver pattern. it
> doesn’t react to any keyboard or mouse action.
Oh.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
the system
On 2015-05-19 22:26, suse paul wrote:
>> And it stops there? No more? What happens if you press enter?
>>
>
> - few more lines about cdrom initialized and random… initialized
> - nothing happens
Well, there was a kernel oops, which is bad news, earlier. And we don’t
know what it affected.
Unfortunately, with systemd there is no way I know to read the log of a
failed system and find out what went wrong - unless you had syslog
installed in advance.
You might try to boot the previous kernel. Or safemode/failsafe/whatever
the name is.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
journactl -D /path/to/var/log/journal on another system.
On 2015-05-20 06:16, arvidjaar wrote:
>
> robin_listas;2710852 Wrote:
>>
>>
>> Unfortunately, with systemd there is no way I know to read the log of a
>> failed system and find out what went wrong
>
> journactl -D /path/to/var/log/journal on another system.
Good to know! Thanks.
suse_paul, you try that.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
I did that.
its last part comprises a correct shutdown at April, 6th.
(date of rescue system is correct)
no later entries
Just on the off chance that this may help (probably not your issue):
I’ve an old laptop with the battery almost gone. If I leave it off for a couple of weeks the battery gets totally empty. Then - after connecting the power brick, of course - sometimes BIOS trows an error, other times the kernel complains about invalid or corrupt file system.
It took me some time to find out that the problem was the date, reset to the 1930’s or something after power loss. The file system dates are all much later than the system date, and the kernel assume it’s a system-wide error.
I have just to set the date and the laptop boots normally.
On 2015-05-22 03:26, brunomcl wrote:
>
> Just on the off chance that this may help (probably not your issue):
>
> I’ve an old laptop with the battery almost gone. If I leave it off for a
> couple of weeks the battery gets totally empty. Then - after connecting
> the power brick, of course - sometimes BIOS trows an error, other times
> the kernel complains about invalid or corrupt file system.
>
> It took me some time to find out that the problem was the date, reset to
> the 1930’s or something after power loss. The file system dates are all
> much later than the system date, and the kernel assume it’s a
> system-wide error.
Yes, it would drop you into recovery mode, to run an fsck on the
filesystems. Good point.
But it appears he does not get a prompt…
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))