Ran into a a couple of related bugs recently and want to get some feedback on whether they are SuSE specific, or if they are fundamental design flaws in linux, or what. Short description: * had/have working SuSE11.0 sys with 1 visible SAS-based disk that the OS had labeled "sda". I could tell it was labeled 'sda' by looking in the grub menu where it instructed linux to boot from sda3, and also by typing "fdisk -l". * Drives were mounted with Labels, as is my custom /=Root, /var=Var, etc. (months pass) * Needed big scratch space, so hotpluged a 1TB SATA into the controller Drive came up as 'sdb', I formatted & used it -- even added a working entry in /etc/fstab to hold the common non-default mount options (logbufs, noatime) Life was fine until a few weeks later I rebooted. System wouldn't boot. No valid root partition found at "sda3", please specify a valid root partition. Well I hadn't changed anything in terms of moving the root partition and no boot options would work (failsafe, nothing). Then I wondered if I had been <sarcasm>"blessed"</sarcasm> by some magical randomizing device-name manager due to the new disk I plugged in. I unplugged the new drive and it still didn't boot, but got further. Now it failed "fsck". At least that dumped me into single-abuser root mode where I found that 'fsck' was trying to call the "dummy script" _fsck.xfs_ (which does nothing other than test that the device it is asked to check, 'exists'. (but that was failing!) It seems fsck doesn't understand "noauto" (it used to!) -- and now tries to force a check and disk-modification (that would happen if it was the old fsck operating on an ext-type file system and it found correctable errors). But "noauto" used to mean (doesn't it still?) _manual_ mount only! Why would fsck try to force-check a disk that was labeled 'noauto' because it might not even be present? After commenting out the fstab line, altogether, the system booted. Fsck no longer was passing a non-existent device to "fsck.xfs" that simply checked for 'existance' -- so it no longer returned an error and the system was allowed to boot up normally rather than forcing me into 'single-abuser' mode to "fix" the problem of my "manually mounted disk" not being "fsck-able" on boot. Grrrr. AAARRRRGGGG...&& GRRRRRR.... Stupid machine... this is the blessing of "automation" that is being forced on me to make my life 'easier' -- which rarely does make it easier and isn't even implemented right on multiple levels!!! Grrrr.... ;^)....this is so "dorky"
Please NOTE<<<: so no one gets defensive here, I'm not mad or angry, or upset (it's just a machine), but at worst, "frustrated", but really mostly amused at the machine's clumsy attempts to "help me", only to make things worse and less reliable than before!
So 2 bugs: 1) Why are my drives being switch around randomly? It's a feature, right? I DO use labels in my fstab -- but SUSE doesn't use labels for 'format -l', smartd, hdparm-settings-by-device, NOR, **most importantly**, does it use the software generated labels in the boot files (lilo or grub) -- and those are the real sticklers. I've long complained about the stupidity of forcing all devices to be 'floating' and dynamic (or defaulting to floating and dynamic) and this illustrates why. Question is, is this a SuSE only bug, or is this the whole concept of dynamic device management (it bites me on network setups as well, though there seem to be ways to work around it there and force a specific device to stay 'eth0', or 'eth1'... but that doesn't happen by default either and is only a problem if you have multiple ethernet cards and want to make sure your routing and firewall settings protect and route to the correct device. But I really need to make sure that hot-plugging a hard-disk in doesn't change the boot-disk because grub/lilo (among other utils that prefer or use hardware-device names and not software-names). And 2nd, more minor bug... why is fstab forcing an fsck on a drive not marked for mounting (i.e. marked 'noauto')? This is a regression. I can file a routine bug for the 2nd, but the 1st problem I don't even know where I'd start to file the bug against what -- because the whole system of dynamic software-naming of devices, while 'well intentioned' and desirable for dynamic software volumes, isn't really desirable for fixed-boot drives that important pieces (booting et al.) of the current software doesn't support being 'dynamic' in any way. So where would, or could, or should the 2nd problem be addressed? And if someone tells me I should submit a patch for all affected pieces of software, may the great 'foo bird' come to you and doodoo on you! (just don't wipe it off if it does...) :-) Linda Walsh (trying to maintain sense of humor about all this ya know, to avoid the reduction-to-quivering/gibbering-mass reaction)... :-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org