MEPIS Community Forum

I'd suggest running TestDisk. It's on the Mepis DVD. Boot it and run it from there. I'm beginning to think you might have a partitioning error. A leftover mount or end point can hang things quite badly. The test only takes a minute or two.

Been busy trying some things. Since there is nothing on the laptop that I do not have else where I could clear everything and start all over. One of the things I found was that the Memory test with any Mepis 11 DVD does Not work on this laptop, it causes the machine to reboot. I have memory tests on other cds and both of them will run and show no errors, even after running for over 20 hours. The version on the Mepis DVD is 4.10, the versions that do run are 4.0a and 4.20.

Another, is that for some reason Debian base disco's are slow to boot on this machine, both 32 or 64 based. Windows XP boots fine and so does Fuduntu-2012-2-x86-64 (RedHat based).

So here is how the laptop is setup right now, after running hardware test again with no errors.
Started with a blank hard drive.
Used XP to make 1st partition and installed there, boots fine. 4.4 GiB sda1 vfat
Then used SimplyMepis DVD 11.0.12_64 to make the root, home and swap partitions.
sda2 ext4 root 10.2 GiB
sda3 ext4 home 56.7 GiB
sda4 swap 2.19 GiB
Install with Check for badblocks and ext4

Still boots as explained in my first post. I hope that the reason can be found why and corrected. I am planning on installing and updating the machine, for now I will have to live with the slow boot. I did not like Fuduntu even though it is for laptops. About April 20th I will be leaving a trip with the laptop.

You should be able to find out where the delay is by looking at /var/log/kern.log which you will have to do as root (right click -> actions -> edit file as su).
The kernel log isn't wiped between boots. It gets archived when it gets too large but continues from where it was, so you'll need scroll down to find the spot where you powered on. Wait a minute or two between shutting down and restarting so you have a clear break in the timestamps to look for.

The timestamps should show where the delay happens. If there's no significant delay showing in the kernel log then I would guess something is seriously wrong with the /boot/initrd.img ramdisk which starts things up.

In fact, if you can't find the delay in the kernel log, I'd try removing the initrd line from the /boot/grub/message.lst file to see if that helps.
Good Luck!

I could see anything with the kern.log, timestamps were all within a second or two . So I removed the initrd line from the /boot/grub/message.lst file and no changes to boot up time.

Here what the screen shows:
[ 0.612681] EXT-fs (sda2): error: couldn't mount because of unsupported optional features (240)
[ 0.612681] EXT-fs (sda2): error: couldn't mount because of unsupported optional features (240)
INT: version 2.88 booting
Using makefile-style concurrent boot in runlevel S.
Starting the hotplug events dispatcher: undevd.
Synthesizing the initial hotplug events...done.
Waiting for/dev to be fully populated..._
takes 63 seconds for curser to start blinking again _ and then 8 seconds to start showing what going on.

So what is it about this machine that Mepis does not like?

WAG> do you have printer connected that reads USB thumb drives or SD cards?

It does look like it's hunting for USB devices and that it's taking too long to find them.

The only things connected are my EVO cooler which has 3 usb ports on it and a logitich usb mouse.

EDIT: It does the same with out anything connected to the laptop.

Thanks everyone for all you help!!!! Extra thanks to:

timkb4cq As removing the initrd line is what worked.

lucky9 Saying It looks like it's hunting for USB devices and that it's taking too long to find them. Was what had me try disconnecting every thing again.

I started with nothing hook up and later hook up the laptop cooler which gets it's power from the laptop and provides 3 usb connections. If I put the initrd line back in then it is the long boot time with nothing connected. Removed it and it boot's like my desktop. So now I just have to remember to leave the cooler unhook on the laptop or have a slow boot.

I do wonder what the trouble is the initrd line and the memory test program??

THANKS ALL you deserved the shout out.

Perhaps timkb4cq will give an explanation to us. But at the very least we'll know what to try next time!

It's just a logical presumption.
Since the delay didn't show in the kernel log it had to occur before kernel logging started - and that starts very early in the process. The only big thing between grub and the run time kernel is the initrd so the problem almost had to be there.

Initrd is an initial ramdisk that allows drivers for devices not rolled into the kernel to load. A lot of linux drivers are built by default as modules including a lot of networking drivers. Without an initrd a network boot wouldn't work. But if there's a module set to load in the initrd that won't load for some reason you can have a problem and I think that's what has happened here. A driver is trying to load, not finding the expected hardware and finally timing out. It's almost certainly related to your usb cooler/hub which is being recognized as something it's not.

I would try running dmeg in a Konsole terminal immediately before & immediately after plugging the cooler in to see how it's being recognized and what's trying to load. If you can isolate a driver and rebuild the initrd without that module the problem will go away.

Alternatively, it could be an IRQ collision with your usb controller and another device preventing devices from being properly recognized while building /dev
If your usb driver is in a kernel module, this would always happen with an initrd line present but without it the kernel wouldn't see the usb until later in the boot process.

Without more testing I couldn't say exactly what the issue is - but you can see the logic that led me to initrd.