Moving /var...
 

I'm in the process of moving some filesystems around on a SUSE 10.0 system. Originally the system had some smallish hard disks and I opted to spread the OS onto three separate disks. As part of an upgrade, I'm moving all of the OS-related filesystems onto only two disks (so I can replace the third with a much larger disk). I'm doing the moves in single user/maintenance mode (using either 'mv' or 'cpio' in pass-through mode).

So far all's gone well except when I moved '/var' and attempted to remount it. The mount command came back with a message about the superblock being bad. That doesn't make any sense since fsck reported zero errors when run against the copy of the '/var' filesystem and I can mount the copy of '/var' onto some other mount point (say: '/mnt/newvar') and I receive no error messages and can see that all the files that were in the original '/var' are present. For now, I'm back to using the '/var' that was on the third disk (the original '/var') but, of course, I can't swap out that third disk for the larger one since '/var' is still on it. :(

I've always suspected that there are some things about Linux's single user mode that's not as single user as one might like; this could be one of 'em. (There are some things that seem to be running that probably shouldn't be if Linux was really in maintenance mode. Like 'ntp' and 'syslog'.)

Anyway... anyone know of anything that could cause this odd behaviour with '/var'?

Finally... What is the file '/etc/blkid.tab' used for? It looks like some sort of XML-ish format file with all sorts of references to disk devices and filesystem types. There's no manpage for it. What creates this or uses it?

TIA,

Rick

(Sorry but I don't have any snapshots of the console message. If anyone thinks it'll help, I can try teeing the output from mount into a disk file and post it here.)

I've never been a fan of copying live file systems - that's one of the things Knoppix was invented for.
Simple "cp -a ..."

As for your other query I'm surprised "man blkid" isn't instituted on your distro.

I don't know how to solve this, but you can customize your single-user runlevel (i wonder why you are using it). When the kernel loads and initializes, it loads the init program, which uses /etc/inittab as configuration file. There are defined several runlevels, which script to execute on starting some particular runlevel, and which to execute on changing a runlevel (to kill all runlevel-specific processes, etc.). Also there you can define, what to execute on Ctrl-Alt-Delete.
So you just modify the appropriate runlevel script. They are usually located under /etc/rc.d. There is one 'fundamental' script that executes before any runleve-specific scripts on startup. You can easily recognize it, because it adds /bin and /sbin to the PATH in the beginning

Then again, the single-user level shouldn't really have "live" filesystems in the sense that there shouldn't be processes that open files on the filesystems. Unless it's the superuser doing something. (Which is why he has the system in single-user mode ;) ) Seems to me that there really ought to be a maximum of about a half dozen processes running at that time. I typically see about four times that many and some that really have no need to be running when you performing system maintenance. (For example: ntp. I mean, who cares about system time while you're running fsck, right?)

I'll see if I can pull this off tonight after booting from the SUSE DVD in rescue mode.

I know about that one. I have to use something like 'cpio' at work (more non-Linux systems than Linux systems) so I'm used to that. Accomplishes the same thing.

DOH! I never looked for the manpage for 'blkid'. I was looking for 'blkid.tab'. Guess I should have tried 'apropos blkid'. (I blame the lateness of the hour.)

Thanks for the reply...

Rick

Sounds like fun. Maybe on some cold winter's day. BTW, I'm in single-user mode to avoid the tons of open files that I'd have if I were in run level 3 or 5. I wouldn't have much confidence in the integrity of the filesystem copy if a slew of processes had open files on the source filesystem.

I doubt I'd want to muck around with that though I used to back when I was running an older versions of Red Hat in order to call a script that I wrote to run 'stinit' to initialize the SCSI tape drive after ejecting any tapes that were loaded.

It might be worth looking at adding several new symbolic links (Kwhatever) to /etc/rc1.d to shutdown some of the extraneous stuff I found running last night. Either that or boot from the CD or DVD to ensure that nothing was touching those filesystems. That would be a problem, however, on those systems that installed across the network because they have no CD-ROM drive. Seems (to me, anyway) like I've run into a
fundamental flaw in the way many, if not most, distributions are implementing single-user mode.

Thanks for the reply...

Rick