Bug#497791: Bug #497791, confirmation
Am Freitag, den 31.07.2009, 10:09 +0200 schrieb Adolf Winterer: Suggestion: If you do not want to add an additional prompt, then please add a text on the screen showing the check box, clearly stating something like this: If grub is NOT installed in the MBR on this computer, then you need to enter the command 'grub-install /dev/XdYn' from a root shell. Caution: Not doing so will leave your computer in an unbootable state. Well I talked now with Robert about it and we added now: Note: It is possible to install GRUB to partition boot records as well. However, this forces GRUB to use the blocklist mechanism, which makes it less reliable, and therefore is not recommended. We just don't want to recommend it to install GRUB to a bootsector instead of MBR because of the blocklists. -- Felix Zielcke Proud Debian Maintainer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#497791: Bug #497791, confirmation
Am Tuesday 28 July 2009 09:54:23 schrieb Felix Zielcke: Am Dienstag, den 28.07.2009, 09:44 +0200 schrieb Adolf Winterer: Am Monday 27 July 2009 16:25:29 schrieb Felix Zielcke: Am Montag, den 27.07.2009, 15:26 +0200 schrieb Adolf Winterer: Hi, I can confirm the problem. This is the sequence that leads to the problem: * Install Lenny 5.0.2 This will automatically use grub2, the system is perfectly bootable. * Add Squeeze to the sources.list After updating the package list the packages grub-common and grub-pc are shown as updateable. * Update grub-common and grub-pc During the update a requestor shows up in the terminal window of Synaptic asking for the device to install grub into. Here it is /dev/sda3. The You probable mean /dev/sda. We don't ask for partitions. I must have misread the prompt then. On the other hand, grub is _not_ installed in the MBR of the device (where rEFIt resides), but in the partition /dev/sda3. How could the procedure work correctly if /dev/sda is specified. It can't. If you want to have grub in a bootsector of a partition instead of MBR you currently have to run grub-install /dev/sda3 yourself. Yesterday I installed another system (MacBookPro5,2) from scratch (base install Lenny) and updated all packages _except_ grub-pc and grub-common to Testing. Today I bootet up and performed the update on these two packages only, no other action. This time I got a graphical prompt from Synaptic, it offered a checkbox (default was unchecked, I left it in this state as I need GRUB in a partition) for installation of GRUB into /dev/sda. The prompt specifically asked for a _device_, being much clearer than the textual version AFAIR. The difference in the type of the prompting used (textual vs. graphical) seems to come from the order in which the packages were updated. The Synaptic package was updated this time _before_ the GRUB packages. As expected the system did not boot up, producing the error again, which could be overcome by the (now known) trick, replacing the line with search.. with a line saying 'insmod linux' in the grub editor. After the reboot all I did was issuing grub-install /dev/sda3 and shutting down the system again. The system startet without any problem then. This clearly shows that the _only_ problem is the missing grub-install /dev/sda3 for a GRUB installation in a partition. The usage of UUIDs is definitely not an issue. I just installed now lenny in a vm, upgraded grub-pc and grub-common to squeeze and selected /dev/sda and rebooted. Worked fine. What was your partitition layout? Was grub in the MBR of the device? Yes grub was in MBR. There was only one partition on the disk. This makes the difference then. Then I did dpkg-reconfigure grub-pc to remove the selections of /dev/sda and tried the same. And it failed with unknown command initrd. Replacing the root=UUID with root=/dev/sda1 didn't help. Well anyway it's a bug we already fixed and that's why we implemented the debconf prompt now. Hmm, but I had the problem. Could it be possible this only occurs, if grub does not reside in the MBR? Yes See above. Are you sure that /dev/sda was seletected the 2nd time you were asked? There was no selection by option list, it was a prompt that asked for a string, anything could have been entered. Do you confuse this maybe with the kopt migration dialog from menu.lst? I know this kind of problem from another case. But on this installation there is not /boot/grub/menu.lst. And, the problem was fixed by issuing the grub-install command. In another report somebody already wished to enter a device manually. But AFAIK debconf doestn't support it in one prompt to have a multiple choice and can enter a device yourself, so we'd need to add a 2nd one which I don't really like. Suggestion: If you do not want to add an additional prompt, then please add a text on the screen showing the check box, clearly stating something like this: If grub is NOT installed in the MBR on this computer, then you need to enter the command 'grub-install /dev/XdYn' from a root shell. Caution: Not doing so will leave your computer in an unbootable state. * Permanent solution Something is wrong with using UUIDs in connection with booting, because uncommenting the according line in /etc/defaults/grub: GRUB_DISABLE_LINUX_UUID=true and running update-grub changes the file /boot/grub/grub.cfg. The line with search ... --fsuid ... is still present, but the line with linux ... has changed to reflect /dev/sda3 as boot device. Therefore the presence of the line containing search ... or the length of the line do not seem to be a problem, but using the UUID is. That's maybe for you a solution. But the real solution is to make sure that grub-install gets run when the package gets upgraded, so you won't
Bug#497791: Bug #497791, confirmation
Am Monday 27 July 2009 16:25:29 schrieb Felix Zielcke: Am Montag, den 27.07.2009, 15:26 +0200 schrieb Adolf Winterer: Hi, I can confirm the problem. This is the sequence that leads to the problem: * Install Lenny 5.0.2 This will automatically use grub2, the system is perfectly bootable. * Add Squeeze to the sources.list After updating the package list the packages grub-common and grub-pc are shown as updateable. * Update grub-common and grub-pc During the update a requestor shows up in the terminal window of Synaptic asking for the device to install grub into. Here it is /dev/sda3. The You probable mean /dev/sda. We don't ask for partitions. I must have misread the prompt then. On the other hand, grub is _not_ installed in the MBR of the device (where rEFIt resides), but in the partition /dev/sda3. How could the procedure work correctly if /dev/sda is specified. requestor pops up again, this time I only hit the enter key as there is only one target to install to. The installation process continues then with no apparent error. If you get asked twice then this may be a bug in Synaptic. I never used it. I use Synaptic quite often, normally with good results. But yes, there had been some strange things in the past (e.g. with LILO the non-execution of the lilo command was one of these). I just installed now lenny in a vm, upgraded grub-pc and grub-common to squeeze and selected /dev/sda and rebooted. Worked fine. What was your partitition layout? Was grub in the MBR of the device? Then I did dpkg-reconfigure grub-pc to remove the selections of /dev/sda and tried the same. And it failed with unknown command initrd. Replacing the root=UUID with root=/dev/sda1 didn't help. Well anyway it's a bug we already fixed and that's why we implemented the debconf prompt now. Hmm, but I had the problem. Could it be possible this only occurs, if grub does not reside in the MBR? Are you sure that /dev/sda was seletected the 2nd time you were asked? There was no selection by option list, it was a prompt that asked for a string, anything could have been entered. Did you see the output of grub-install? Maybe try dpkg-reconfigure grub-pc I will try later with another system that needs to be installed and updated. * Permanent solution Something is wrong with using UUIDs in connection with booting, because uncommenting the according line in /etc/defaults/grub: GRUB_DISABLE_LINUX_UUID=true and running update-grub changes the file /boot/grub/grub.cfg. The line with search ... --fsuid ... is still present, but the line with linux ... has changed to reflect /dev/sda3 as boot device. Therefore the presence of the line containing search ... or the length of the line do not seem to be a problem, but using the UUID is. That's maybe for you a solution. But the real solution is to make sure that grub-install gets run when the package gets upgraded, so you won't be affected by other bugs in the parser etc. For example there were now in the squeeze version a few parser bug fixes, though they didn't affect the default generated config. I will issue a manual grub-install before reboot with the next installation and report back. Thank you for supporting me. Adolf Winterer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#497791: Bug #497791, confirmation
Am Dienstag, den 28.07.2009, 09:44 +0200 schrieb Adolf Winterer: Am Monday 27 July 2009 16:25:29 schrieb Felix Zielcke: Am Montag, den 27.07.2009, 15:26 +0200 schrieb Adolf Winterer: Hi, I can confirm the problem. This is the sequence that leads to the problem: * Install Lenny 5.0.2 This will automatically use grub2, the system is perfectly bootable. * Add Squeeze to the sources.list After updating the package list the packages grub-common and grub-pc are shown as updateable. * Update grub-common and grub-pc During the update a requestor shows up in the terminal window of Synaptic asking for the device to install grub into. Here it is /dev/sda3. The You probable mean /dev/sda. We don't ask for partitions. I must have misread the prompt then. On the other hand, grub is _not_ installed in the MBR of the device (where rEFIt resides), but in the partition /dev/sda3. How could the procedure work correctly if /dev/sda is specified. It can't. If you want to have grub in a bootsector of a partition instead of MBR you currently have to run grub-install /dev/sda3 yourself. I just installed now lenny in a vm, upgraded grub-pc and grub-common to squeeze and selected /dev/sda and rebooted. Worked fine. What was your partitition layout? Was grub in the MBR of the device? Yes grub was in MBR. There was only one partition on the disk. Then I did dpkg-reconfigure grub-pc to remove the selections of /dev/sda and tried the same. And it failed with unknown command initrd. Replacing the root=UUID with root=/dev/sda1 didn't help. Well anyway it's a bug we already fixed and that's why we implemented the debconf prompt now. Hmm, but I had the problem. Could it be possible this only occurs, if grub does not reside in the MBR? Yes Are you sure that /dev/sda was seletected the 2nd time you were asked? There was no selection by option list, it was a prompt that asked for a string, anything could have been entered. Do you confuse this maybe with the kopt migration dialog from menu.lst? In another report somebody already wished to enter a device manually. But AFAIK debconf doestn't support it in one prompt to have a multiple choice and can enter a device yourself, so we'd need to add a 2nd one which I don't really like. * Permanent solution Something is wrong with using UUIDs in connection with booting, because uncommenting the according line in /etc/defaults/grub: GRUB_DISABLE_LINUX_UUID=true and running update-grub changes the file /boot/grub/grub.cfg. The line with search ... --fsuid ... is still present, but the line with linux ... has changed to reflect /dev/sda3 as boot device. Therefore the presence of the line containing search ... or the length of the line do not seem to be a problem, but using the UUID is. That's maybe for you a solution. But the real solution is to make sure that grub-install gets run when the package gets upgraded, so you won't be affected by other bugs in the parser etc. For example there were now in the squeeze version a few parser bug fixes, though they didn't affect the default generated config. I will issue a manual grub-install before reboot with the next installation and report back. Thank you for supporting me. Thanks for replying fast :) -- Felix Zielcke Proud Debian Maintainer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#497791: Bug #497791, confirmation
Hi, I can confirm the problem. This is the sequence that leads to the problem: * Install Lenny 5.0.2 This will automatically use grub2, the system is perfectly bootable. * Add Squeeze to the sources.list After updating the package list the packages grub-common and grub-pc are shown as updateable. * Update grub-common and grub-pc During the update a requestor shows up in the terminal window of Synaptic asking for the device to install grub into. Here it is /dev/sda3. The requestor pops up again, this time I only hit the enter key as there is only one target to install to. The installation process continues then with no apparent error. * Reboot the system Now the system cannot boot any longer. Instead of booting grub displays error: unknown command linux. * Use the grub editor at startup Here I replace the line containing the literals search --fs-uuid with insmod linux and the system successfully boots up. But this is only a temporary workaround to get into the system again. * Permanent solution Something is wrong with using UUIDs in connection with booting, because uncommenting the according line in /etc/defaults/grub: GRUB_DISABLE_LINUX_UUID=true and running update-grub changes the file /boot/grub/grub.cfg. The line with search ... --fsuid ... is still present, but the line with linux ... has changed to reflect /dev/sda3 as boot device. Therefore the presence of the line containing search ... or the length of the line do not seem to be a problem, but using the UUID is. Some additional informations on the setup: Hardware is a MacBook Pro, with rEFIt 0.13 as boot manager for dual boot. Partitions are: EFI Partition is /dev/sda1 Mac OS X is in /dev/sda2 /root is in /dev/sda3 (grub is installed into this partition) /home is in /dev/sda4 Regards, Adolf Winterer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#497791: Bug #497791, confirmation
Am Montag, den 27.07.2009, 15:26 +0200 schrieb Adolf Winterer: Hi, I can confirm the problem. This is the sequence that leads to the problem: * Install Lenny 5.0.2 This will automatically use grub2, the system is perfectly bootable. * Add Squeeze to the sources.list After updating the package list the packages grub-common and grub-pc are shown as updateable. * Update grub-common and grub-pc During the update a requestor shows up in the terminal window of Synaptic asking for the device to install grub into. Here it is /dev/sda3. The You probable mean /dev/sda. We don't ask for partitions. requestor pops up again, this time I only hit the enter key as there is only one target to install to. The installation process continues then with no apparent error. If you get asked twice then this may be a bug in Synaptic. I never used it. I just installed now lenny in a vm, upgraded grub-pc and grub-common to squeeze and selected /dev/sda and rebooted. Worked fine. Then I did dpkg-reconfigure grub-pc to remove the selections of /dev/sda and tried the same. And it failed with unknown command initrd. Replacing the root=UUID with root=/dev/sda1 didn't help. Well anyway it's a bug we already fixed and that's why we implemented the debconf prompt now. Are you sure that /dev/sda was seletected the 2nd time you were asked? Did you see the output of grub-install? Maybe try dpkg-reconfigure grub-pc * Permanent solution Something is wrong with using UUIDs in connection with booting, because uncommenting the according line in /etc/defaults/grub: GRUB_DISABLE_LINUX_UUID=true and running update-grub changes the file /boot/grub/grub.cfg. The line with search ... --fsuid ... is still present, but the line with linux ... has changed to reflect /dev/sda3 as boot device. Therefore the presence of the line containing search ... or the length of the line do not seem to be a problem, but using the UUID is. That's maybe for you a solution. But the real solution is to make sure that grub-install gets run when the package gets upgraded, so you won't be affected by other bugs in the parser etc. For example there were now in the squeeze version a few parser bug fixes, though they didn't affect the default generated config. -- Felix Zielcke Proud Debian Maintainer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
