Can't boot without Thumb drive attached

I used a thumb drive to backup up a few files (/etc, /home, /boot/grub, using rsync as su) from an old pc that’s used only as a print server (11.1, 2.6.27.19-32-default1686, KDE 4.1.3)

I then unmounted and removed the thumb drive. The next time I rebooted the boot process was halted and the screen shown heredisplayed. With the thumb attached the PC boots fine, but not without it.

I’ve tried all sorts of things including reattaching the thumb drive and unmounting it as root, but no luck. I’ve checked the drive and it contains only the backup folders.

any ideas?

Check your /etc/fstab for entries related to your thumb drive.

KDE auto-detects USB mass storage devices and can mount them for you, and safely remove them to. Presumably GNOME has similar. That way you don’t have fstab(5) entries to clear, and if you mount yourself, you can mount from command line anyway without touching fstab(5).

why is /var not accessible?

try attaching the thumb drive and after the successful boot do this

cat /etc/fstab

df --print-type

and, copy paste output here…

if copy/paste is not easy from there, try directing the output to the
thumb drive thus

cat /etc/fstab >> /[full path to thumbdrive]/fstab.txt

and the other to df.txt


palladium, fishing

Thanks to all, the solution was really simple once you all pointed me in the right direction.

df --print-type

Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/sda1 ext3 10325748 3567128 6234100 37% /
udev tmpfs 353576 208 353368 1% /dev
/dev/sda2 ext3 25806300 1888556 22606840 8% /home
/dev/sdb1 ext3 7708732 1414944 5902204 20% /thumb
/dev/sr0 iso9660 679066 679066 0 100% /media/SU1110.001-1

cat /etc/fstab

/dev/disk/by-id/ata-TOSHIBA_MK4026GAX_65AG1617T-part3 swap swap defaults 0 0
/dev/disk/by-id/ata-TOSHIBA_MK4026GAX_65AG1617T-part1 / ext3 acl,user_xattr 1 1
/dev/disk/by-id/ata-TOSHIBA_MK4026GAX_65AG1617T-part2 /home ext3 acl,user_xattr 1 2
proc /proc proc defaults 0 0
sysfs /sys sysfs noauto 0 0
debugfs /sys/kernel/debug debugfs noauto 0 0
devpts /dev/pts devpts mode=0620,gid=5 0 0
/dev/disk/by-id/usb-SanDisk_Cruzer_1740011B77C2AD5C-0:0-part1 /thumb ext3 acl,user_xattr 12

I just removed the last line from fstab, and the problem is solved :wink:

(Not sure why the error message claiming /var is not accessible. it clearly is accessible, so that message appears to be bogus…)

The /var likely wasn’t writeable for blogd when you were in filesystem maintenance mode, due to fsck(8) checks failing.

If a disk was becoming problematic for example, writing blocks in wrong places say, it makes sense to minimise the writes made to filesystems, and let the sysadmin diagnose.

Rob

Ah yes, that makes sense. Thanx again.