MEPIS Community Forum

I found this in the virtualbox.org tutorials. (it's dated 27 Mar 2009, so it may or may not still apply)

It recommends putting the mount command in the /etc/rc.local init script instead of mounting the shared folder with fstab.

These instructions cover Guest Additions and shared folders: http://www.virtualbox.org/manual/ch04.h ... redfolders

Early versions of VirtualBox required mounting shared folders manually at run time or through /etc/fstab:



However, I see that beginning with V4.0, mounting is done automatically by Guest Additions.



I've been using manual mounting since I began using VirtualBox, back in Version 2.x. Call it force of habit. I'm not here to defend using the manual method. The only reason I'm bringing this up in this thread is because it's a convenient way to test out the fstab bug. I'm confident the bug will appear regularly in a SM 11.0 guest with the modification, so the bug can be repeated and tested on a standard (virtual) hardware platform.

If you don't want to test the bug using my method, you don't have to. The choice is yours

First it is not a VurtualBox bug, VurtualBox is made to install in Debian, which because of all the problems with fstab updated along with other main stream Linux distro's to grub2,
VBox installs with no problems in any of the debian current releases as they all use Grub2..
Also of note Debian stable is very conservative in there choice of software and do not advise users to install Grub2 just for fun they do it for a reason

Well the fstab thing hit me today but with everything else that was going on I doubt that my data will be of help.
At one point I believed I had a bad external hard disk because Clonezilla wouldn't see all of the partitions on it. Difference partitions at different times of course.

I also had a mangled file system (Ext3) on my /home partition. It took most of the afternoon to get back to normal....mainly because of a bad Image which didn't work secondary to the file system being hashed.

Ended up having to reset the KDE and Group settings with the Mepis User Assistant. I believe that or correcting the file system enabled the System Assistant to install GRUB correctly. But I can't be sure as that was just the last thing that cleared up. I was beginning to wonder if anything would fix the ability to install GRUB. It may well have been both working together causing that problem.

During all of this my fstab was mangled. Nothing was above the dynamic line. Nothing. Repaired with the Mepis LiveDVD using KWrite. The System Assistant for GRUB. User Assistant for the Permissions, etc. and the good old Command Line for the file system and some other checking.

While things were not totally calm this afternoon and early evening....I haven't had this much fun in a long time. Thank you, Warren.

Did you find anything in the log files that could give a clue?
If you could repeat the whole mess with boot logging enabled, you could have another day of fun. And get some valuable information for Warren.
Seems like you have to go pretty far to be sure of destroying the fstab. That must be the reason why I haven't been able to do it. My small experiments haven't been close to the complete mayhem you created. Good idea, even if it wasn't intentional.
Henry

Perhaps it's something in the air at around this time because on boot up yesterday evening my system wobbled again. I think the cause of it was because I had removed a USB keyboard dongle without letting the system unload it properly and then put it back before the system was started again.

At least the only error message that came up suggested that all was not well with it and though the machine booted through it wasn't happy - see fstab below. <grin>

# Dynamic entries below
/dev/sda1 /mnt/sda1 ext3 noauto,users,exec,relatime 0 0
/dev/sda2 swap swap sw,pri=1 0 0
/dev/sda3 /mnt/sda3 ext3 noauto,users,exec,relatime 0 0
/dev/cdrom1 /media/cdrom1 udf,iso9660 noauto,users,exec,ro 0 0
/dev/sr0 /media/cdrom1 udf,iso9660 noauto,users,exec,ro 0 0

I only have one optical drive and I could have sworn that it was designated /dev/cdrom not /dev/cdrom1 before this latest glitch.

That was a good experiment. One of the best yet. Shows clearly how the fstab error happens.
Can you repeat it?
Enable bootlog first to (hopefully) find more details.
Enable it in the file /etc/default/bootlogd
BOOTLOGD_ENABLE=Yes
The bootlog then shows up in /var/log/boot
Had to google for how to enable bootlog, had forgotten it completely.
Henry

If you can find out how to reproduce the error with a USB keyboard, Warren gets a chance to fix it.
Henry

I'll certainly try, as soon as I finish up some stuff I'm doing.


Heh heh, I had bootlog enabled from a while back but had forgotten about it. With any luck there will be something useful in there when/if I can reproduce the glitch.

Enabling bootlog was easier said than done. Mine is producing nice empty documents.
It's surprising how stable Mepis is when you try to crash it.
If I was a computer, I should have been seriously disturbed when someone connects and disconnects an USB-stick (with strange signs in the name) during the boot process.
Henry