LinuxQuestions.org - [SOLVED] Booting hangs indefinitely in "Mounting local filesystems non-root" (rc.S)

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Booting hangs indefinitely in "Mounting local filesystems non-root" (rc.S) (https://www.linuxquestions.org/questions/slackware-14/booting-hangs-indefinitely-in-mounting-local-filesystems-non-root-rc-s-4175455827/)

Booting hangs indefinitely in "Mounting local filesystems non-root" (rc.S)

I have a fresh install of Slackware 14.0 and the boot stops at the line "Mounting non-root local filesystems" so I have to add noapic to the boot options. So KDE becomes very slow and useless (opening apps, system shutdown...) and this did not happen with 13.1 version. I have disabled Nepomuk and Strigi. Using mainly ReiserFS.

Where should I start?

Fstab file:

Code:

/dev/sda2        swap            swap        defaults        0  0

/dev/sda1        /                reiserfs    defaults        1  1

/dev/sda3        /home            reiserfs    defaults        1  2

#/dev/cdrom      /mnt/cdrom      auto        noauto,owner,ro,comment=x-gvfs-show 0  0

/dev/fd0        /mnt/floppy      auto        noauto,owner    0  0

devpts          /dev/pts        devpts      gid=5,mode=620  0  0

proc            /proc            proc        defaults        0  0

tmpfs            /dev/shm        tmpfs      defaults        0  0

The last message you see on screen does not necessarily mean that is where the script is halting. Edit rc.S and add some temporary echo messages such as echo Test 1, echo Test 2, etc. Place the first echo message just after the mounting snippet:

...
echo "Mounting non-root local filesystems:"
sleep 3
if /bin/grep -wq devpts /proc/mounts ; then
/sbin/mount -a -v -t nonfs,nosmbfs,nocifs,noproc,nosysfs,nodevpts
else
/sbin/mount -a -v -t nonfs,nosmbfs,nocifs,noproc,nosysfs
fi
echo "Test 1"
...

If you see the "Test 1" message on screen then the stoppage is occuring after that. If you don't see the "Test 1" message then you've isolated the problem area.

It was my first thought after posing the problem but I did not have access to the machine until today.

Code:

echo "Mounting non-root local filesystems:"

echo T001

sleep 3

echo T002

if /bin/grep -wq devpts /proc/mounts ; then

  echo T002A

...

The result was only T001. What?

I upgraded the sleep to 8 without apparent changes. Any idea?

I'd tentatively comment out the line for /home in /etc/fstab (or use a noauto option for it) and see what happens. You should be able to mount /home manually afterwards.

I got no changes disabling /home in fstab. I have restored the BIOS to factory settings and enabled Hyper-Threading Technology, this was always off by default. There were no problems for 13.1 version. It seems that part of the problem was solved. I no longer need noapic to continue boot but the system is still very slow.

Should I activate a new feature in the system for HTT?

Code:



$ uname -a

Linux INFINITE 3.2.29-smp #2 SMP Mon Sep 17 13:16:43 CDT 2012 i686 Intel(R) Pentium(R) 4 CPU 3.06GHz GenuineIntel GNU/Linux

Quote:

Originally Posted by Divel (Post 4922715)

Should I activate a new feature in the system for HTT?

Code:



$ uname -a

Linux INFINITE 3.2.29-smp #2 SMP Mon Sep 17 13:16:43 CDT 2012 i686 Intel(R) Pentium(R) 4 CPU 3.06GHz GenuineIntel GNU/Linux

I guess no as 3.2.29-smp kernels have CONFIG_SCHED_SMT=y already.

Following this article you could try to include :

Code:

append="acpismp=force"

to the relevant image section in /etc/lilo.conf, though this option be not documented in /usr/src/linux/Documentation/kernel-parameters.txt. (dunno if it is still usable with 2.6 kernels).

In any case, please post full output of:

Code:

cat /proc/cpuinfo

No apparent changes using acpismp=force.

Code:

# grep acpismp /var/log/*



messages:128487:Apr  3 10:10:39 INFINITE kernel: [    0.000000] Kernel

command line: auto BOOT_IMAGE=Linux ro root=801 vt.default_utf8=0

acpismp=force

Code:

# cat /proc/cpuinfo



processor      : 0

vendor_id      : GenuineIntel

cpu family      : 15

model          : 2

model name      : Intel(R) Pentium(R) 4 CPU 3.06GHz

stepping        : 9

microcode      : 0x17

cpu MHz        : 3066.654

cache size      : 512 KB

physical id    : 0

siblings        : 2

core id        : 0

cpu cores      : 1

apicid          : 0

initial apicid  : 0

fdiv_bug        : no

hlt_bug        : no

f00f_bug        : no

coma_bug        : no

fpu            : yes

fpu_exception  : yes

cpuid level    : 2

wp              : yes

flags          : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pebs bts cid xtpr

bogomips        : 6133.30

clflush size    : 64

cache_alignment : 128

address sizes  : 36 bits physical, 32 bits virtual

power management:



processor      : 1

vendor_id      : GenuineIntel

cpu family      : 15

model          : 2

model name      : Intel(R) Pentium(R) 4 CPU 3.06GHz

stepping        : 9

microcode      : 0x17

cpu MHz        : 3066.654

cache size      : 512 KB

physical id    : 0

siblings        : 2

core id        : 0

cpu cores      : 1

apicid          : 1

initial apicid  : 1

fdiv_bug        : no

hlt_bug        : no

f00f_bug        : no

coma_bug        : no

fpu            : yes

fpu_exception  : yes

cpuid level    : 2

wp              : yes

flags          : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pebs bts cid xtpr

bogomips        : 6132.40

clflush size    : 64

cache_alignment : 128

address sizes  : 36 bits physical, 32 bits virtual

power management:

I had a previous boot problem that I solved with vga=normal. Could this be related to the current problem?

Code:

error fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver

On the other hand, should I try the huge.s kernel?

Quote:

Could this be related to the current problem?

Could be. I ran into a similar problem:

https://www.linuxquestions.org/quest...re-4175450593/

In Comment No. 8 I describe a black screen I sometimes saw.

I tried two solutions:

1. Set CONFIG_SHED_SMT=n in /boot/config-huge-smp-3.2.29-smp.
2. Booting with vmlinuz-huge-3.2.29 (no-SMP).

There is an appreciable improvement when using the no-SMP kernel but I do not think it worked as well as SMP in 13.1 version. I did not spend much time on the first solution. BIOS-HTT was required in both cases. Why?