[opensuse] Re: Very strange boot problem
Le 12/12/2009 08:44, Bob S a écrit :
Well, something happens.And I can't explain it. If I go into the rescue system and choose "boot installed system" for 11.2 it is shown as sda8. It boots 11.2 perfectly. Why it shows sda8 instead of sdc8 I have no idea.
this is the interesting part. Is your dvd reader sata or pata. I never could really know how mother boards managed the sata drives. I would like to have any hint on the subject. May be having a dvd inserted changed the drive order did you try booting *the hard drive* with the dvd inserted (but without using the dvd) Very
illogical. Remember now, I tried to boot normally as sda8 and got that stupid message about finding it. The partitioner, fdisk, and Parted Magic all show the disk layout correctly.
same in recovery system loaded from the dvd?
This is crazy. Why should replacing the MB have anything to do with booting?
all!! It's the mobo / BIOS that decides what drive is what at boot time (after that, it's Linux)
That is all HD stuff except for the bios. And that all seems to be correct. And why does the install/rescue system mis-identify tue disks in a seemingly random order?
I would like to see what do the grub console when typing kernel ( <TAB> (using tab completion, with and without a dvd in the drive I would really like understanding what happen :-) jdd -- http://www.dodin.net http://valerie.dodin.org http://news.opensuse.org/2009/04/13/people-of-opensuse-jean-daniel-dodin/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Le 12/12/2009 08:44, Bob S a écrit : Thin it is time to re- visit the old way of doing things /de/hda ect this /dev/disc/by ID ect is nothing but a mine field over which there is very
On Saturday 12 Dec 2009 08:25:26 jdd-gmane wrote: little control . I know there were people saying they don't have enough devices with the old system well maybe they need to completely Re- think their computing needs/System either that or we have a system whereby you can choose which system you use according to your system requirements big box too many drives hung off it "/dev/disc/by-ID " smaller system 2 or 3 drives hung off it "/dev/hdx " or if you really must insist on this darn scssi naming convention then "/dev/sdx" ect personally i can see no need for this darn silly calling an PATA or IDE device a Scsi device it just adds yet another level of un needed complication and confusion SATA devices should maybe /dev/sat but sdx humm i know this has been beaten up before but i see it as a very valid concern here we are trying to spread Linux and gain more users yet here we also go making it more and more difficult for new users to grasp if there is logic in there somewhere i cant see it . Pete . -- Powered by openSUSE 11.2 Milestone 2 (x86_64) Kernel: 2.6.30-rc6-git3-4- default KDE: 4.2.86 (KDE 4.2.86 (KDE 4.3 >= 20090514)) "release 1" 16:18 up 21 days 6:08, 3 users, load average: 0.05, 0.06, 0.02
On Sat, Dec 12, 2009 at 04:29:50PM +0000, Peter Nikolic wrote:
Le 12/12/2009 08:44, Bob S a écrit : Thin it is time to re- visit the old way of doing things /de/hda ect this /dev/disc/by ID ect is nothing but a mine field over which there is very
On Saturday 12 Dec 2009 08:25:26 jdd-gmane wrote: little control .
The approach of using /dev/disk/by-id makes things more reliable. The device name stays idependent of the order the controllers get initialized. Or think about adding a new disk to an existing system. Your old device names stay independet if a controller or new disks get added.
I know there were people saying they don't have enough devices with the old system well maybe they need to completely Re- think their computing needs/System either that or we have a system whereby you can choose which system you use according to your system requirements big box too many drives hung off it "/dev/disc/by-ID " smaller system 2 or 3 drives hung off it "/dev/hdx " or if you really must insist on this darn scssi naming convention then "/dev/sdx" ect personally i can see no need for this darn silly calling an PATA or IDE device a Scsi device it just adds yet another level of un needed complication and confusion
This approach makes it much easier for the maintainers of the disk sub system. You gain one comman way to access disks independent of the particular interface (PATA,SATA,SCSI) in use. See the documentation to libata. For example http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata.pdf
SATA devices should maybe /dev/sat but sdx humm i know this has been beaten up before but i see it as a very valid concern here we are trying to spread Linux and gain more users yet here we also go making it more and more difficult for new users to grasp if there is logic in there somewhere i cant see it .
There is a logic in libata and users new to Linux will very unlikely think about or know if a device was named /dev/hda or /dev/sdc in the past. The current approach makes things easier in the majority of use cases. Till now I've only found one use case where the old approach is an advantage. That's when you're running virtual systems and you like to have the guest OS disk device name being independent of the disk system used by the host. A person with deeper knowledge of the kernel should correct me if I'm wrong. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2009-12-12 at 18:40 +0100, Lars Müller wrote:
The approach of using /dev/disk/by-id makes things more reliable. The device name stays idependent of the order the controllers get initialized.
I mount by label where ever I can, and the YaST partitioner sets this up nicely most of the times. I have an external disk which sometimes I connect via USB, others via ESATA. I mount it manually, with an entry in fstab... which does not change with the bus type. Sometimes it goes as sdc, others as sdd... who cares? I'm happy with the new system :-) Anyway, the old system is also available... if your disks never change order. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAksj/rgACgkQtTMYHG2NR9UYIgCZAZPRJ5I/D8Tjos9ICKS2oENS KOoAn10Kv89dtJX09h44L/CSoTpTGM8F =sMcC -----END PGP SIGNATURE-----
On 2009/12/12 21:36 (GMT+0100) Carlos E. R. composed:
On Saturday, 2009-12-12 at 18:40 +0100, Lars Müller wrote:
The approach of using /dev/disk/by-id makes things more reliable. The device name stays idependent of the order the controllers get initialized.
I mount by label where ever I can, and the YaST partitioner sets this up nicely most of the times.
I like by label best too, but this thread was started because by-label in 11.2 was not working for Bob S, the OP: http://lists.opensuse.org/opensuse/2009-12/msg00455.html -- " We have no government armed with power capable of contending with human passions unbridled by morality and religion." John Adams, 2nd US President Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.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 Saturday, 2009-12-12 at 16:10 -0500, Felix Miata wrote:
On 2009/12/12 21:36 (GMT+0100) Carlos E. R. composed:
On Saturday, 2009-12-12 at 18:40 +0100, Lars Müller wrote:
The approach of using /dev/disk/by-id makes things more reliable. The device name stays idependent of the order the controllers get initialized.
I mount by label where ever I can, and the YaST partitioner sets this up nicely most of the times.
I like by label best too, but this thread was started because by-label in 11.2 was not working for Bob S, the OP: http://lists.opensuse.org/opensuse/2009-12/msg00455.html
I thought that labels, ids, etc, did not work on grub. There is a map file that "defines" the correspondence beetween both, but I don't know which side is the "boss" side. I think it is the bios who defines them. The "root" command uses grub own's names. Then, the kernel line can use disk labels, but that is once the kernel has loaded already, and this part ignores the /boot/grub/device.map file. Example: title openSUSE 11.0 root (hd0,5) <==== gub names. kernel /vmlinuz root=/dev/disk/by-id/ata-ST3160021A_5JS4VV1F-part6 ^^ ^^-- kernel names. \__ relative to (hd0,5) resume=/dev/disk/by-label/320_swap ^^-- kernel names. .... initrd /initrd ^^^ relative to (hd0,5) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkskCr4ACgkQtTMYHG2NR9WNCgCfVSM80hPabXGowmU9FmkglXTW H7cAn1VSj2r9kmH2qWQ8Ob6jI+TeeVTy =ZI7w -----END PGP SIGNATURE-----
Lars Müller wrote:
On Sat, Dec 12, 2009 at 04:29:50PM +0000, Peter Nikolic wrote:
Le 12/12/2009 08:44, Bob S a écrit : Thin it is time to re- visit the old way of doing things /de/hda ect this /dev/disc/by ID ect is nothing but a mine field over which there is very
On Saturday 12 Dec 2009 08:25:26 jdd-gmane wrote: little control .
The approach of using /dev/disk/by-id makes things more reliable. The device name stays idependent of the order the controllers get initialized.
Or think about adding a new disk to an existing system. Your old device names stay independet if a controller or new disks get added.
Yeah, except, with the old way I could copy an opld drive to a new drive and the new drive would still be that same /dev/sdXx, and all bootloader configs would magically still work without editing or adjusting even though I'd completely replaced the drive. The by-id way breaks in that case. all the id's change. This is not really a problem, or not a larger problem than what by-id solves. I'm just pointing out that there is no single right way for everyone in all cases. (The rest isn't diretced at you Lars, at the thread in general) As for being mystified by hda vs sda... come on if that's a problem then you should not even be trying, just hire the closest 11 yr old to figure out all this hard stuff. As for being mystified by the bios drive ordering vs the OS drive ordering, well, yes, that's the explanation right there. The bios sees things in whatever way it does, and the OS sees things in whatever way it does, and the two do not have anything to do with each other except by coincidence. Neither is the way they see things static over time let alone the same as each other. Various bios config options that you the user may set, may change which devices the bios sees, what kind of device the bios sees some devices as, and what order it sees them in. And all that is also true for the OS. The mystery is why anyone is mystified that these things are mutable. The way to configure the bootloader is no specific particular way. Wish there was? Oh well, tough. The only simple instruction is "Configure the boot loader to reflect what you want to happen, given the particulars of your various hardware and firmware and software." You simply need to know at least a few things about how the bios and the os works, and how the bootloader works so you can know how to make it work with the other two. Not a lot really, but you can't avoid having to know at least a few things. And, these things do not have to be conferred from God. You can google them and do a little trial & error yourself. All 4 elements (hardware, bios, os, bootloader) are required to have a working system, all 4 affect each other, and all 4 are changeable. You change any one element, and it affects all the others and may require a matching change in one or all of the others. You have to understand at least a few things about all 4 sides before you can hope to make things work. But, you only need to know a few things about each, and then you can always make a working system any time no matter what. No stupid being helpless in the face of mysteries. Theres no need for mysteries. Just stop trying to avoid having to learn. Or, if you have other things you'd rather think about, that's fine. We don't all have to be in IT. Go find someone who does grok this stuff, tell them what you want, and then don't mess with it. Or else don't cry to anyone when it breaks. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2009-12-12 at 18:54 -0500, Brian K. White wrote:
Lars Müller wrote:
The approach of using /dev/disk/by-id makes things more reliable. The device name stays idependent of the order the controllers get initialized.
Or think about adding a new disk to an existing system. Your old device names stay independet if a controller or new disks get added.
Yeah, except, with the old way I could copy an opld drive to a new drive and the new drive would still be that same /dev/sdXx, and all bootloader configs would magically still work without editing or adjusting even though I'd completely replaced the drive.
The by-id way breaks in that case. all the id's change.
No, it doesn't break. You simply have to use /dev/disk/by-uuid/ instead. Just choose the method appropriate to your case. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkskMr8ACgkQtTMYHG2NR9XGJACgiMZTKLwPh24eUIDVyOqlteTj M2gAn1bzPz0dfgS2VMpTfPmZvBydTl/E =QAjP -----END PGP SIGNATURE-----
On 2009/12/12 18:54 (GMT-0500) Brian K. White composed:
Or, if you have other things you'd rather think about, that's fine. We don't all have to be in IT. Go find someone who does grok this stuff, tell them what you want, and then don't mess with it. Or else don't cry to anyone when it breaks.
Did you just happen to read the OP that started all this? http://lists.opensuse.org/opensuse/2009-12/msg00455.html What broke was a motherboard. The new motherboard is compatible enough that the kernels/drivers are able to find the disks, but the OS and/or boot loader is/are not smart enough to accommodate what changed as a result. With the old ways, this would not have been a problem. The by-label syntax actually used by 11.2's installer should have kept it working, but it didn't here. -- " We have no government armed with power capable of contending with human passions unbridled by morality and religion." John Adams, 2nd US President Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.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 Saturday, 2009-12-12 at 19:41 -0500, Felix Miata wrote:
What broke was a motherboard. The new motherboard is compatible enough that the kernels/drivers are able to find the disks, but the OS and/or boot loader is/are not smart enough to accommodate what changed as a result.
Again, grub does not read labels. It uses the (hdX,Y) syntax only. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkskPBYACgkQtTMYHG2NR9XwJgCeKQXPjVrlp/dWfGnVkDomFfeq Vk4AmgLWBV85Xq8DSxVJKacQKNqODzwo =ki6l -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 2009/12/13 01:57 (GMT+0100) Carlos E. R. composed:
On Saturday, 2009-12-12 at 19:41 -0500, Felix Miata wrote:
What broke was a motherboard. The new motherboard is compatible enough that the kernels/drivers are able to find the disks, but the OS and/or boot loader is/are not smart enough to accommodate what changed as a result.
Again, grub does not read labels. It uses the (hdX,Y) syntax only.
So we expect, but why did a device.map file's contents upthread by jdd-gmane contain (hd1) /dev/disk/by-id/usb-Generic_... and (hd0) /dev/disk/by-id/ata-WDC_WD5000BEVT...? The point of my comment was about a failure to boot following hardware replacement that would not have occurred in the absence of as yet undetermined boot "failsafe" measures instituted sometime between 11.0 release and 11.2 release. The OP has been able to boot 11.0 (on PATA) post-replacement, but not 11.2 (on SATA). https://bugzilla.novell.com/show_bug.cgi?id=483136#c13 may highlight a clue to the source of the problem. I just confirmed that both 11.1 and 11.2 can boot normally while neither /boot/grub/device.map nor root=<whatever> on the Grub kernel line exist. That tells me something is likely hard-coded in the initrd to the no longer present motherboard. In order to narrow this down probably someone needs to pull a HD out of a system and try to use it in another system that uses the same storage drivers with a mix of HD & SD disks. It may need a bug filed and a looksee by jreidinger or hare or fehr or ???? -- " We have no government armed with power capable of contending with human passions unbridled by morality and religion." John Adams, 2nd US President Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Saturday, 2009-12-12 at 19:41 -0500, Felix Miata wrote:
What broke was a motherboard. The new motherboard is compatible enough that the kernels/drivers are able to find the disks, but the OS and/or boot loader is/are not smart enough to accommodate what changed as a result.
Again, grub does not read labels. It uses the (hdX,Y) syntax only.
Wrong. And right. Grub runs at two different times from two very different contexts. http://www.gnu.org/software/grub/manual/html_node/Device-map.html device.map is read while the OS is running and may have anything in it that the OS understands, which is a lot more than what the bios understands and what grub at boot-time understands. For example, I have boxes booting from usb thumb drives. (I want all of the sata hot-swap drives to be used for raid, and I do not want any internal drives that can't be easily and quickly swapped out by on-site people) To the OS the thumb drive shows up after all of the hard drives on the motherboard, and before all of the other hard drives on add-in cards. To the bios, because I have set the bios settings a certain way and formatted the usb drives a certain way, the usb drive is the first drive. Then again, after the os is all booted up, if I removed and re-inserted the thumb drive, it would become the next higher sdX letter after all the other drives. So it's not /dev/sda or /dev/sdg or /dev/sdn, yet at different times from different contexts it is each of those. So in device.map I usually put a line that uses by-id in that case. (hd0) /dev/disk/by-id/usb-AVIXE_USB_FLASH_DRIVE_000000000000C1-0:0 (The length of the line is utterly inconsequential. Good grief it's a computer, cut & paste was invented a long time ago, it's not like you have to write it in calligraphy with a bamboo stick on calf skin vellum from memory. And conceptualizing? Where "sda" used to refer to an address on a bus on a controller, now a long id string refers to a unique string found on the device itself, wherever and however it might be connected. What's so hard?) I don't know how grub represents the address to the device internally but I doubt it reads device.map at boot time. Only while the os is running is there even such a thing as /dev/anything. One thing I'm not clear on, and which almost suggests the opposite of above, as that, I know that I can use any arbitrary hd# number I want in device.map as long as I use that same number everywhere else in menu.lst and /etc/grub.conf In other words, even if at boot-time a certain device will be the first bios drive, I don't have to call it hd0 in device.map I can have a line that says (hd5) /dev/disk/by-id/usb-AVIXE_USB_FLASH_DRIVE_000000000000C1-0:0 and as long as I use hd5 and hd5,<partition-number> etc in the other files, it works at boot time. That means hd0 does not mean "the drive that will be the first bios drive at boot-time", it refers to some stored internal grub table of devices, stored I know not where. I think, from reading that documentation I referenced, that if device.map didn't exist, then the default behavior would be that hd0 refers to the first bios drive at boot time. I usually need a device.map though, because the drive that will show up as bios drive 0 at boot time is rarely the same drive that the OS, or grub while running inside the running OS, _thinks_ will be drive 0. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2009-12-12 at 16:29 -0000, Peter Nikolic wrote:
Le 12/12/2009 08:44, Bob S a écrit : Thin it is time to re- visit the old way of doing things /de/hda ect this /dev/disc/by ID ect is nothing but a mine field over which there is very
On Saturday 12 Dec 2009 08:25:26 jdd-gmane wrote: little control .
Grub doesn't use the "new" system. Nor the old. Neither does the BIOS. Which is why these boot problems arise. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAksj/ZcACgkQtTMYHG2NR9VUCgCfdctjn9oXuVjrS6RhgQdTLTkm Sc0AoJahCFl3auqCZhw5a648zEO9Rznh =Gg4M -----END PGP SIGNATURE-----
participants (6)
-
Brian K. White -
Carlos E. R. -
Felix Miata -
jdd-gmane -
Lars Müller -
Peter Nikolic