[opensuse] Bugs? in SuSE11 or fundamental linux flaws? file bug(s)
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
In <49F22C96.9010405@tlinx.org>, Linda Walsh wrote:
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".
The md*, hd*, and sd* "labels" are not persistent in any way. "sda1" is simply the first partition of the first drive found in the scsi subsystem. "md2" is simply the third device-mapper device created. These names are based on the detection order of devices, a non-deterministic but not entirely random process. udev provides a way to generate device names based on persistent attributes of the detected devices rather rather the order they were found in. Even before udev was around, libblkid provided a means to locate filesystems based on persistent attributes, rather than device. -- Boyd Stephen Smith Jr. ,= ,-_-. =. bss@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
On Fri, Apr 24, 2009 at 5:37 PM, Boyd Stephen Smith Jr.
In <49F22C96.9010405@tlinx.org>, Linda Walsh wrote:
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".
The md*, hd*, and sd* "labels" are not persistent in any way. "sda1" is simply the first partition of the first drive found in the scsi subsystem. "md2" is simply the third device-mapper device created. These names are based on the detection order of devices, a non-deterministic but not entirely random process.
udev provides a way to generate device names based on persistent attributes of the detected devices rather rather the order they were found in. Even before udev was around, libblkid provided a means to locate filesystems based on persistent attributes, rather than device.
Yes but at least the first stage of booting is typically handled by grub, and I don't remember seeing a solution to keeping the grub disk designations stable as drives come and go. Curious if anyone else has? Greg -- Greg Freemyer Head of EDD Tape Extraction and Processing team Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Friday 24 April 2009 04:40:36 pm Greg Freemyer wrote:
Yes but at least the first stage of booting is typically handled by grub, and I don't remember seeing a solution to keeping the grub disk designations stable as drives come and go.
Curious if anyone else has?
You mean (hd0) pointing to different device? # cat /boot/grub/device.map (fd0) /dev/fd0 (hd1) /dev/disk/by-id/ata-WDC_<...1> (hd0) /dev/disk/by-id/ata-WDC_<...2> I don't see problem. The /boot/grub/menu.lst has /dev/disk/by-id/ata-WDC_<...1> and /dev/disk/by-id/ata-WDC_<...2> entries. If it would be label used syntax is different, but still it seems that it works fine. It could that openSUSE grub is patched to allow this kind of naming. -- Regards, Rajko http://news.opensuse.org/category/people-of-opensuse/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Rajko M. wrote:
On Friday 24 April 2009 04:40:36 pm Greg Freemyer wrote:
Yes but at least the first stage of booting is typically handled by grub, and I don't remember seeing a solution to keeping the grub disk designations stable as drives come and go.
Curious if anyone else has?
You mean (hd0) pointing to different device?
# cat /boot/grub/device.map (fd0) /dev/fd0 (hd1) /dev/disk/by-id/ata-WDC_<...1> (hd0) /dev/disk/by-id/ata-WDC_<...2>
I don't see problem.
The /boot/grub/menu.lst has /dev/disk/by-id/ata-WDC_<...1> and /dev/disk/by-id/ata-WDC_<...2> entries.
If it would be label used syntax is different, but still it seems that it works fine. It could that openSUSE grub is patched to allow this kind of naming.
Rajko, Has a point. Normally it isn't a problem with just two disks, but when you get into sets of raid arrays it is a must. (/boot/grub/device.map) For the past couple of years things seemed relatively stable with drives not swapping order under the new labeling schemes, but something must be coming unglued, because in the past several months I count at least three separate threads about this, Linda's included. The device.map file helps by providing the mapping between the fake drive names/labels that are now used and the old hardware hd(1,2,3..) convention. In Linda's case it can be used to tell the boot process which device is hd0 and which is hd1 so they don't get swapped and lead to grub trying to boot from /dev/sda3 on what was in reality Linda's /dev/hdb. I ran into this problem and it drove me nuts when I had 2 device mapper containing 2 different md arrays that drove grub nuts. If you are experiencing a similar problem, then look at your devices in /dev/mapper and/or with df -h to figure out what devices are what: [21:48 archangel:/srv/www] # l /dev/mapper total 0 drwxr-xr-x 2 root root 0 2009-04-24 04:49 . drwxr-xr-x 23 root root 0 2009-04-24 04:49 .. crw-rw---- 1 root root 10, 60 2009-04-24 04:49 control brw------- 1 root disk 254, 1 2009-04-24 04:49 nvidia_fdaacfde brw------- 1 root disk 254, 6 2009-04-24 04:49 nvidia_fdaacfde5 brw------- 1 root disk 254, 7 2009-04-24 04:49 nvidia_fdaacfde6 brw------- 1 root disk 254, 8 2009-04-24 04:49 nvidia_fdaacfde7 brw------- 1 root disk 254, 9 2009-04-24 04:49 nvidia_fdaacfde8 brw------- 1 root disk 254, 0 2009-04-24 04:49 nvidia_fffadgic brw------- 1 root disk 254, 2 2009-04-24 04:49 nvidia_fffadgic5 brw------- 1 root disk 254, 3 2009-04-24 04:49 nvidia_fffadgic6 brw------- 1 root disk 254, 4 2009-04-24 04:49 nvidia_fffadgic7 brw------- 1 root disk 254, 5 2009-04-24 04:49 nvidia_fffadgic8 Your drives will be the names *without* a number. [23:07 archangel:/srv/www] # df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/nvidia_fffadgic5 19G 9.5G 8.0G 55% / none 2.0G 0 2.0G 0% /dev/shm /dev/mapper/nvidia_fffadgic6 114M 16M 93M 15% /boot /dev/mapper/nvidia_fffadgic7 37G 346M 35G 1% /home /dev/mapper/nvidia_fdaacfde7 20G 17G 2.0G 90% /mnt/ecs /dev/mapper/nvidia_fdaacfde5 69M 19M 47M 29% /mnt/ecs/boot /dev/mapper/nvidia_fdaacfde8 437G 141G 275G 34% /mnt/ecs/home Then just create and/or edit your /boot/grub/device.map to map your drives to the real hardware naming scheme. Here, if I want the drive /dev/mapper/nvidia_fdaacfde to boot as hd0, I just do the following: [21:01 archangel:/srv/www] # cat /boot/grub/device.map (hd0) /dev/mapper/nvidia_fdaacfde (hd1) /dev/mapper/nvidia_fffadgic (fd0) /dev/fd0 Take a look at what you have Linda, and see if it makes sense, then post back. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, Apr 24, 2009 at 6:19 PM, Rajko M.
On Friday 24 April 2009 04:40:36 pm Greg Freemyer wrote:
Yes but at least the first stage of booting is typically handled by grub, and I don't remember seeing a solution to keeping the grub disk designations stable as drives come and go.
Curious if anyone else has?
You mean (hd0) pointing to different device?
# cat /boot/grub/device.map (fd0) /dev/fd0 (hd1) /dev/disk/by-id/ata-WDC_<...1> (hd0) /dev/disk/by-id/ata-WDC_<...2>
I don't see problem.
The /boot/grub/menu.lst has /dev/disk/by-id/ata-WDC_<...1> and /dev/disk/by-id/ata-WDC_<...2> entries.
If it would be label used syntax is different, but still it seems that it works fine. It could that openSUSE grub is patched to allow this kind of naming.
So it does. Time to go update the fate request related to having a tool to update /etc/fstab. Obviously it should also update the grub device table as well. Greg -- Greg Freemyer Head of EDD Tape Extraction and Processing team Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2009-04-24 at 14:18 -0700, Linda Walsh wrote:
It seems fsck doesn't understand "noauto" (it used to!) -- and now
No, fsck obeys the 0 or non 0 at the end of the line.
So 2 bugs: 1) Why are my drives being switch around randomly? It's a feature, right?
Of the BIOS. That's why they invented the other types of mountings (id, uuid, label...)
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.
It seems grub does support them in the map file. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknyTVIACgkQtTMYHG2NR9VZHgCfUPk/HpDGSFi7x/GqWnTZLADB um8An2espnaBcEQBsSdpBT9huFrbtR5B =HY1N -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, Apr 24, 2009 at 5:18 PM, Linda Walsh
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.
That's something I've complained about also. Some BIOS's will insert a USB drive as the first drive and that makes things a pain. The disk by label stuff seems to have helped, but I wish it would prompt me to continue if it can't find something in fstab instead of dropping into problem mode. I think I should choose to say continue if I pulled a drive for some reason thats non-root and non-system and just mounted elsewhere. It was a real pain with SuSE 9.x when I had SCSI, SATA, and USB Drives. Making everything an sdx is very irriatating. Even IDE is now an sdx on most systems(not on older ppc macs tho). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2009-04-26 at 20:42 -0400, Larry Stotler wrote:
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 ... That's something I've complained about also. Some BIOS's will insert a USB drive as the first drive and that makes things a pain. The disk by label stuff seems to have helped, but I wish it would prompt me to continue if it can't find something in fstab instead of dropping into
On Fri, Apr 24, 2009 at 5:18 PM, Linda Walsh <> wrote: problem mode. I think I should choose to say continue if I pulled a drive for some reason thats non-root and non-system and just mounted elsewhere.
man mount: nofail Do not report errors for this device if it does not exist. That might help with that particular problem. Else, I think it is done by a script, so perhaps the query is doable. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkn19JwACgkQtTMYHG2NR9WrYgCaA7MrSYmBGnMcy6Fuw27xYcSm NDIAniU1NNkjNSeaeYIbDxKZz5sLQInA =IpGf -----END PGP SIGNATURE-----
On Mon, Apr 27, 2009 at 2:08 PM, Carlos E. R.
man mount: nofail Do not report errors for this device if it does not exist. That might help with that particular problem. Else, I think it is done by a script, so perhaps the query is doable.
Can it be put in the fstab though? I'll have to look into that. Thanx Carlos -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2009-04-27 at 17:46 -0400, Larry Stotler wrote:
On Mon, Apr 27, 2009 at 2:08 PM, Carlos E. R. <> wrote:
man mount: nofail Do not report errors for this device if it does not exist. That might help with that particular problem. Else, I think it is done by a script, so perhaps the query is doable.
Can it be put in the fstab though? I'll have to look into that. Thanx Carlos
I think so, yes. I haven't tried, one only remembers these things when the system fails to boot because a partition is not there, and I have to edit the fstab right there. My usual solution is to set it "noauto" and a "0" on the fsck option, but nofail looks interesting, too. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkn2OKAACgkQtTMYHG2NR9VI3QCbBzMh9ysbIVzR93T+2FZkXNzg IsYAniRDmpBYKCoNUgsxu8BFrOuA0uIL =ZXG1 -----END PGP SIGNATURE-----
participants (7)
-
Boyd Stephen Smith Jr. -
Carlos E. R. -
David C. Rankin -
Greg Freemyer -
Larry Stotler -
Linda Walsh -
Rajko M.