Bug#495049: why is (fd0) hard-coded into the grub image?
Am Freitag, den 15.08.2008, 19:49 +0200 schrieb Felix Zielcke: http://lists.gnu.org/archive/html/grub-devel/2008-08/msg00442.html Just like raid, lvm needs to scan all device. I think this is caused when it try to open (fd0), and fails. The grub_errno is not cleared, it's carried out and cause the rescue shell. I just tried to get you to confirm this for me. Robert has now commited in upstream SVN the proposal from Bean. So please try current upstream SVN version, if you still have this bug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495049: why is (fd0) hard-coded into the grub image?
Am Freitag, den 15.08.2008, 03:18 -0700 schrieb [EMAIL PROTECTED]: I should point out that when grub drops into the rescue prompt, it coughs up the message error: unknown device fd0. Perhaps this is why it goes into rescue mode? Thanks for telling us. This is a bit different then: GRUB doestn't load normal.mod because there is no string normal in core.img My device.map file, as previously listed, does not contain an entry for fd0, because the machine does not in fact have a floppy drive. Wondering if this might help, I added the entry (fd0) /dev/fd0, and reinstalled grub. I think you understand something wrong. The problem is that GRUB thinks fd0 is your bootdevice, even though your device.map is right. Of course it doestn't help if you make your harddisk to fd0. Why should GRUB then suddenly see it as hd0 ? Some questions suggest themselves: -- why is there a hard-coded dependency on fd0, when neither device.map nor grub.cfg mention it? -- is the fd0 dependency the reason why grub drops into rescue mode? Please stop assuming things if you don't understand how GRUB works. -- why does adding an fd0 entry to device.map not resolve this error? Why should GRUB then think your harddisk is hd0 instead of fd0 which it currently does? Finally, I suggest the following patch for clarifying exactly what grub-install is doing, at least until some of these issues are resolved. Please read man bash There's an -x option which does something like that. For example run: bash -x /usr/sbin/grub-install /dev/sda I assume you don't know enough C to understand the whole sourcecode. That's totally okay of course you don't need that to report a bug. But please just state your problem. I already wanted to make that to you clear with my I think it's normal that core.img doestn't contain the string normal to load normal.mod Please let it to Robert and me trying to find out the `why?'. It is totally okay if you would your report just like this for me grub goes to rescue mode with unknown device fd0 I only need to do insmod normal normal then the menu comes up and I can boot my system I have LVM on / That means: just state your problem and details of your system for example that you use LVM Don't tell us that probable XYZ is the problem and that it's easy to fix, if you are not sure that it is. And error messages like that unknown device fd0 are shown for a reason and so should be in your bug report _submission_. (that means not in the 3rd mail but instead already in the 1st) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495049: why is (fd0) hard-coded into the grub image?
Am Freitag, den 15.08.2008, 09:28 -0700 schrieb [EMAIL PROTECTED]: I would have mentioned it before, except that it didn't seem relevant, because I don't have a floppy disk, and neither device.map nor grub.cfg refer to it. Aha, it doestn't seem relevant because you don't have a floppy drive and you didn't found a place why grub thinks that you have one. Ok. because -- I didn't say that. You made it up. Please stop assuming things if you don't understand how GRUB works. If the problem is that GRUB thinks fd0 is your bootdevice, then actually it seems that I understood the situation correctly. From your bug submission: It turns out that the file core.img does not contain the string normal. -- why does adding an fd0 entry to device.map not resolve this error? If (fd0) is an unknown device, then why doesn't (fd0) /dev/fd0 make it known? Because the file is called device.map Which means map linux devices to grub devices. I assume you don't know enough C to understand the whole sourcecode. You assume wrong. I still assume that, because you even failed to choose the right severity of this report. The Debian documentation about this is very clear. Honourly I don't have still any motivation at all for this report. Luckly I have already forwarded this to grub-devel and somebody had an idea. So now you can proof how much your C knowledge is and your understanding of GRUB sourcecode. please add to disk/lvm.c to the mod_init function: grub_errno = GRUB_ERR_NONE; please do not forgot to do grub-install /dev/sda or whatever the disk is you boot from, else the real GRUB isn't updated but of course you know that. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495049: why is (fd0) hard-coded into the grub image?
Am Freitag, den 15.08.2008, 10:51 -0700 schrieb [EMAIL PROTECTED]: Forget it, I'll fix it myself, and send the patch to upstream. Great, why didn't you do that first if you know everything better? This does nothing to explain why grub is worried about (fd0), when none of its inputs mention any such device, as I pointed out several times already. But I suppose that your lofty arrogance prohibits you from addressing such mundane questions. http://lists.gnu.org/archive/html/grub-devel/2008-08/msg00442.html Just like raid, lvm needs to scan all device. I think this is caused when it try to open (fd0), and fails. The grub_errno is not cleared, it's carried out and cause the rescue shell. I just tried to get you to confirm this for me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495049: grub-pc: does not boot because module normal is not loaded
Am Mittwoch, den 13.08.2008, 19:13 -0700 schrieb Ian Bruce: I installed grub because lilo wouldn't boot any more. My root fs is on lvm; I don't know if this is related. After running grub-install and rebooting, grub drops into the grub rescue prompt. The pc, lvm, and ext2 modules are loaded, ls finds the root volume, and the variable root is set appropriately. Only the variable root or the prefix too? Investigation shows that if the following commands are issued: insmod normal normal -- then the boot menu specified by grub.cfg appears, and the system boots properly. It turns out that the file core.img does not contain the string normal. It seems like this problem should be easy to fix. Are sure that if you boot you only type insmod normal normal and then the menu shows? i.e. nothing before like set prefix or set root? That would be very weird if GRUB set it's variables right, but still fails to load grub.cfg by it's own. [EMAIL PROTECTED]:~$ strings /boot/grub/core.img|grep normal [EMAIL PROTECTED]:~$ I think that core.img doestn't contain the string `normal' is just well normal, grub2 works fine for me, but I don't have LVM or RAID ;) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427492: grub-efi: method to 'bless' ?
Hello, unfortunately neither Robert and me don't know how important this really is. On IRC we talked with Bean (one of upstream developers) Unfortunately he didn't reply yet to the report, as I suggested. He discovered that Debian has efibootmgr [0] and wanted even to look if GRUB can include something of it. Junichi, is this package what you want? For me it looks like that grub-efi should just recommend/suggest that efibootmgr package. [0] http://packages.debian.org/en/sid/efibootmgr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492964: grub-pc: cross install Windows: invalid identifier
Am Mittwoch, den 30.07.2008, 11:20 +0200 schrieb Sladan:
I did grub-install sda and selecting Windows in the Grub2 menu returns
invalid identifier.
I really don't know what I should do with your report.
Maybe you can reproduce this and tell us when exactly that is shown?
In the console it says root=hd1,2 when Linux works. It's root=hd1,3 after
trying the Windows entry.
### BEGIN /etc/grub.d/30_os-prober ###
menuentry Microsoft Windows XP Home Edition (on /dev/sda3) {
set root=(hd1,3)
chainloader +1
}
I think this is with intent.
Normally the chainloader command should never return, i.e. should
suceed.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494662: description of unifont package is a bit wrong now
Package: unifont Version: 1:5.1.20080808-2 Severity: minor Hello, It's really great that you found a solution with Robert for our unifont.hex problem. I just noticed that the first line of it is now a bit wrong: `This metapackage is a convenient way to install both the PCF bitmap version and the scalable TrueType outline version of GNU Unifont.' Now that it contains the unifont.hex and unifont-full.hex, it isn't anymore a metapackage and the description should mention, that it now includes these 2 hex files. -- System Information: Debian Release: lenny/sid APT prefers experimental APT policy: (500, 'experimental'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages unifont depends on: ii ttf-unifont 1:5.1.20080808-2 TrueType version of the GNU Unifon ii xfonts-unifont 1:5.1.20080808-2 PCF (bitmap) version of the GNU Un unifont recommends no packages. Versions of packages unifont suggests: ii unifont-bin 1:5.1.20080808-2 utilities for manipulating the GNU -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494589: grub-pc: grub-install fails on GPT volume
Am Montag, den 11.08.2008, 10:09 -0400 schrieb Edward Allcutt: grub-setup fails in exactly the same way, however grub-fstest seems to have no problem at all with the new core.img: [EMAIL PROTECTED]:~# grub-fstest -vvv /dev/sda1 cmp /grub/core.img \ /boot/grub/core.img; echo $? 0 Am I using grub-fstest wrong or does this imply grub-setup is broken? Weird that this worked for you, I had to use: fz:~# grub-fstest -vvv /dev/hda cmp (loop,2)/boot/grub/core.img /boot/grub/core.img fz:~# grub-fstest -vvv /dev/hda ls (loop,2)/boot/grub/core.img core.img hda2 contains my linux / As you can see with `grub-fstest -h' it has a ls command which works just like real GRUB's one. grub-fstest is using loop instead of hd as you can see above. grub-setup: info: couldn't open the core image grub-setup: info: error message = file not found I should have written that part on my mail too. So please try again grub-fstest like above. I've also noticed that when using grub-emu I get other errors: grub insmod (hd0,1)/grub/gpt.mod error: invalid arch independent ELF magic For all I know this is normal but it seemed worth mentioning. This is really normal, nothing to worry about. grub-emu just doestn't support the modules at all. But you shouldn't need them, i.e. `ls' command should display your harddisks and partitions just like real GRUB's one or grub-fstest's. Would `dd bs=512 if=/dev/sda1 | gzip sda1` be sufficient as the filesystem image or would the GPT table be necessary too? I just started with the GRUB project and I think Robert is neither a filesystem/partition expert so better have this whole discussion upstream (i.e. grub-devel). It doestn't hurt if you attach the first 1024 bytes of your disk which should contain enough information of the GPT (according to Wikipedia). I forgot that you already have a /boot partition so that should be small enough already :) By the way: bzip2 compresses better then the gzip you used above and the grub-devel lists rejects mails something bigger as 1 MB or so. So better find a place to upload the boot.img like rapidshare. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494460: grub-pc: update-grub unable to generate a graphical gfxterm menu
Am Sonntag, den 10.08.2008, 13:10 +0100 schrieb Adeodato Simó: * Felix Zielcke [Sun, 10 Aug 2008 01:01:25 +0200]: The new upload for lenny will build-depend on the old version, so hopefully all buildds will then use the lenny version to build the packages. They won't. Ok, thanks for your reply. I'm still so new to that `Co-maintaining a Debian package' thing :) Luckly we only need that unifont for amd64 and i386. It isn't a problem for us to upload a binary for both. But if we build depend on that older version which works for us and the buildds won't use it, then this sounds to me it doestn't get build at all, because then the build depency can't be satisfied? I just want to clarify this if we have in the future again such a problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494460: grub-pc: update-grub unable to generate a graphical gfxterm menu
Am Sonntag, den 10.08.2008, 14:23 +0100 schrieb Adeodato Simó: * Felix Zielcke [Sun, 10 Aug 2008 14:22:05 +0200]: Luckly we only need that unifont for amd64 and i386. It isn't a problem for us to upload a binary for both. That is normally frowned upon, but I'm ok if you do that for now, since rebuilds on testing will produce valid packages in any case. But if we build depend on that older version which works for us and the buildds won't use it, then this sounds to me it doestn't get build at all, because then the build depency can't be satisfied? That's correct. Thanks again that you clarify this for me. Robert probable already knows these things already anyway :) As I wrote that `hopefully buillds use lenny version' I even forgot that he already said we just upload binaries for amd64 and i386 which has the font. Luckly there's now a new unifont-bin which includes it again. I forgot even -proposed-updates. So the buildds are just using the enviroment the packages was uploaded for. There has to be a reason why stable|testing -proposed-updates does exist :) This really makes sense to me now so thanks again to you. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494589: grub-pc: grub-install fails on GPT volume
Am Sonntag, den 10.08.2008, 16:22 -0400 schrieb Edward Allcutt: I looked at the changelog for 1.96+20080724-6 from sid but it doesn't seem to contain anything relevant. You could try current upstream SVN[0], which is a bit more recent (i.e. last change today) then the 0724-X which we currently stick for lenny. The 0730-1 in experimental isn't that much newer as you can see and it has not a few bugfixes backported from upstream for the recent 0724-X releases. Hopefully we can make soon another trunk upload to experimental. The most recent previous version I could find was 1.96+20080429-1 from snapshot.debian.net. This version does not exhibit the problem and that's what I'm reverting to each time to keep my system bootable. (It would probably be fine after a simple upgrade but I'm not sure if overwriting core.img during grub-install would mess things up.) Only grub-install/grub-setup recreates and embed core.img and they are never called by the postinst, except `grub-install --grub-setup=/bin/true' if you choose to chainload grub2 from grub-legacy, because for this to work there needs to be a core.img :) By the way: You can set packages on hold with aptitude with `=' Then that package will never be updated. If you want to have it updated again you have to remove the hold with `+' Now for the errors. The basic grub-install invocation: [EMAIL PROTECTED]:~# grub-install --no-floppy '(hd0)' grub-setup: error: Cannot read `/boot/grub/core.img' correctly grub-setup tries to read the core.img with the functions real GRUB would use and compares it with the result it gets by reading with OS functions i.e. what everyother linux binary on your system uses to read files. Of the recent changes, patches/00_strengthen_apple_partmap_check.diff introduced in 1.96+20080724-3 seems most relevant. I doubt, because grub-setup is able to detect your extN partition, you see that in the log, there's no `ext2 detection failed' but many `Reading `hd0,1'' after `detecting ext2' So it looks like fs/ext2.c isn't that correct for the extN you have on /boot The best would be probable if you could reproduce with a small filesystem image and would send that to [EMAIL PROTECTED], you need to be subscribed though. With recompiling from source you can specify ./configure --enable-grub-fstest, then you get grub-fstest which might help in finding out what's wrong. (I say extN because ext2.mod supports now even ext4dev extents) [0] http://svn.savannah.gnu.org/viewvc/trunk/grub2/?root=grub svn co svn://svn.sv.gnu.org/grub/trunk/grub2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494158: [grub2] update-grub: uses wrong ordering algorithm (sorts 1.2.3-foo before 1.2.3.1-foo)
Am Freitag, den 08.08.2008, 19:59 -0300 schrieb Henrique de Moraes Holschuh: On Fri, 08 Aug 2008, Felix Zielcke wrote: I really should have sticked with my easy debugging method I already mentioned in the report (that echo /tmp/x thingy) I thought removing the greedy g on the regexps would just solve the problem for us, but it doestn't: fz:/etc/grub.d# dpkg --compare-versions 2.6.26-1-amd64~rc1-git1 gt 2.6.26-1-amd64; echo $? 0 fz:/etc/grub.d# dpkg --compare-versions 2.6.26-1-amd64~rc1~git1 gt 2.6.26-1-amd64; echo $? 1 This looks for me more then a dpkg issue. ~x-y should be like ~x~y i.e. that the above one returns the same. No, dpkg is quite correct in its implementation of ~. You really need to use it only once on kernel-style -rc prefixes (i.e. prefixes that mean you are BEFORE a given version). Oh sorry that I didn't make it clear. 2.6.26-1-amd64-rc1-git1 should be BELOW 2.6.26-1-amd64. When there are 2 ~ then it does work in that case. If there's only one then it does NOT work in that case. See here with 1 (i.e. from Robert's regexp the greedy /g removed) ~rc1-git1 Found linux image: /boot/vmlinuz-2.6.26-1-amd64-rc1-git1 Found linux image: /boot/vmlinuz-2.6.26-1-amd64 Found initrd image: /boot/initrd.img-2.6.26-1-amd64 Found linux image: /boot/vmlinuz-2.6.26-1-amd64-rc1 Here with the greedy regexp. i.e ~rc1~git1 Found linux image: /boot/vmlinuz-2.6.26-1-amd64 Found initrd image: /boot/initrd.img-2.6.26-1-amd64 Found linux image: /boot/vmlinuz-2.6.26-1-amd64-rc1 Found linux image: /boot/vmlinuz-2.6.26-1-amd64-rc1-git1 I try to say it in other words: The dash AFTER the ~ seems to reset the `~ means lower then empty string' ~rc1-git1 is treated NEWER then the one with the empty string. It doestn't matter (at least for the lenny release) if this is a bug or if that is intendet, we have to find a solution for this problem. Heh. I will try to take a stab at it in two or three days. Thanks very much :) And I forgot the method used before (and still in lenny) sorted -test below -rc but I think we just need to replace ~test with ~atest or something like that to make that work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494383: grub-pc: Grub2 cannot find LVM volume groups with a dash (-) in the name
Hello, Am Freitag, den 08.08.2008, 22:23 +0200 schrieb root: grub-probe: error: Unknown device linux--vg-boot Autodetection of a file system module failed Please specify the module with the option --modules explicitly I never used LVM before so maybe I did something wrong, but I think the lvm2 Debian package has a bug: fz-vm:~# pvcreate /dev/sdb Physical volume /dev/sdb successfully created fz-vm:~# vgcreate linux-vg /dev/sdb Volume group linux-vg successfully created fz-vm:~# lvcreate -L 1M linux-vg Rounding up size to full physical extent 4,00 MB Logical volume lvol0 created fz-vm:~# ls /dev/mapper/ control linux--vg-lvol0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494383: grub-pc: Grub2 cannot find LVM volume groups with a dash (-) in the name
Hi, Am Samstag, den 09.08.2008, 12:26 +0200 schrieb Felix Zielcke: fz-vm:~# ls /dev/mapper/ control linux--vg-lvol0 And again it wasn't that clear with my first mail :( fz-vm:~# l /dev/linux* /dev/mapper/ /dev/linux-vg: insgesamt 0 lrwxrwxrwx 1 root root 27 9. Aug 14:49 lvol0 - /dev/mapper/linux--vg-lvol0 /dev/linuxvg: insgesamt 0 lrwxrwxrwx 1 root root 25 9. Aug 14:49 lvol0 - /dev/mapper/linuxvg-lvol0 /dev/mapper/: insgesamt 0 crw-rw 1 root root 10, 60 9. Aug 14:49 control brw-rw 1 root disk 253, 1 9. Aug 14:49 linux--vg-lvol0 brw-rw 1 root disk 253, 0 9. Aug 14:49 linuxvg-lvol0 Current upstream SVN shows me: fz-vm:/dev/mapper# grub-probe /mnt/ error: no mapping exists for `linux--vg-lvol0' grub-probe: error: no mapping exists for `linux--vg-lvol0' If I change the double dash to one and mount it again then it works fine. This bug happens at least with recent udev/lvm2 from Debian unstable with kernel.org 2.6.27-rc2 I failed to find out how to workaround this in GRUB and I'm a bit unsure if we even should do this. What happens if this is fixed in lvm2/udev/kernel (wherever it belongs too) and what is with people who like to have 2 dashes in there vg name? (Robert: In this LVM case I think it's not that bad that debian-installer currently prefers LILO over GRUB 2 ;)) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494158: [grub2] update-grub: uses wrong ordering algorithm (sorts 1.2.3-foo before 1.2.3.1-foo)
Am Samstag, den 09.08.2008, 16:54 +0200 schrieb Robert Millan: It doestn't matter (at least for the lenny release) if this is a bug or if that is intendet, we have to find a solution for this problem. It worries me that combinations with -git are a problem. -git wasn't handled at all before, so if it seems hard to get it right without our current time constraints, I'd rather leave it post-lenny. Right we can leave that -rcN-gitN problem to post lenny :) My biggest concern is the regression (in comparison to etch). If we remove the greedy 'g' as you proposed, I take it this gives us working code again? Because we don't need to have a right -rcN-gitN -rcN -gitN ordering, I suggest we use greedy. The greedy makes only a difference for this -rcN-gitN (or -preN-gitN, you get the idea) double problem. I think it's better to have: (with greedy) Found linux image: /boot/vmlinuz-2.6.26-1-amd64 Found linux image: /boot/vmlinuz-2.6.26-1-amd64-rc1 Found linux image: /boot/vmlinuz-2.6.26-1-amd64-rc1-git1 instead of: (without) Found linux image: /boot/vmlinuz-2.6.26-1-amd64-rc1-git1 Found linux image: /boot/vmlinuz-2.6.26-1-amd64 Found linux image: /boot/vmlinuz-2.6.26-1-amd64-rc1 Robert, you're Code (with greedy) with dpkg is probable better, then the one before. We only have now a problem with the ordering of the same base version, e.g. in my case vmlinuz-2.6.26-1-amd64 But we don't need to worry anymore about different base versions :) So for lenny we just use the one you already made, with one little change I suggest: a=`echo $a | sed -e s/~test/~atest/` b=`echo $b | sed -e s/~test/~atest/` With such changes we even can reuse our priority system with dpkg :) the first char(s) after ~ is our priority, in case we need to change it. If we want to have -test below -rc then we have to :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494158: [grub2] update-grub: uses wrong ordering algorithm (sorts 1.2.3-foo before 1.2.3.1-foo)
Am Samstag, den 09.08.2008, 19:50 +0200 schrieb Robert Millan: I'm not very concerned with distinguishing priorities other than what goes before and after the empty string. I'd rather just put all those known suffixes below the empty string and not care about their relative weights, for the sake of simplicity. So if there are no objections, I'd like to check in the patch I sent (with the greedy 'g' as you suggest) and upload that. For lenny I'd say that too. It's for almost everyone probable be better with that dpkg way now. It's just not 100% perfect, but we can discuss this for post lenny is if we should make it more perfect. I still don't understand it anyway why people have many different kernels in /boot/ (e.g. the guy who reported the problem with the big grub.cfg) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494460: grub-pc: update-grub unable to generate a graphical gfxterm menu
tag 494460 pending retitle 494460 i386 builds are missing fonts thanks Am Samstag, den 09.08.2008, 16:44 -0600 schrieb Javier Vasquez: And there's a difference in here, since for i686: # ls /usr/share/grub/ # See 494473 The reason is that the unifont-bin package doestn't provide anymore the file we use to generate the fonts for GRUB. The new upload for lenny will build-depend on the old version, so hopefully all buildds will then use the lenny version to build the packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494460: grub-pc: update-grub unable to generate a graphical gfxterm menu
Am Samstag, den 09.08.2008, 17:38 -0600 schrieb Javier Vasquez: So the reason might just be that things are done differently for these 2 architectures, and the bug is i386 exclusive, :)... I'm mentioning this out of my ignorance, since I still don't get how things still work for one architecture and not the other, given that both have the same versions, and both are not depending upon unifont* which I don't have installed in any architecture... So my only guess is that they do things very different then, :). Binary packages are only uploaded for one archicteture, in our case AMD64. For the other architectures buildds are used to create them for us. It's a *build* depency and that's why it's not listed on the binary grub-pc or grub-common package. Robert used the old version of unifont-bin to create the 24-6 upload, whereas the i386 buildd had already used the new one. But this is not the topic of this report so if you still have questions to that better ask on debian-user list or some other place. So the clue is then to wait for a new update which would fix things then, I guess? Yes and that's why this bug is now tagged pending. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494158: Bug#493389: update-grub: uses wrong ordering algorithm (sorts 1.2.3-foo before 1.2.3.1-foo)
Just CC now both bug reports, although the difference between grub2's and grub-legacy's update-grub should be handled differently. Am Donnerstag, den 07.08.2008, 13:10 -0300 schrieb Henrique de Moraes Holschuh: I was about unsure if I should use 'lt' 'le' 'le-nl' or 'lt-nl' You want to return 1 for A B and 0 otherwise. That's how the code uses CompareVersions(). There is no reason to use -nl versions, the calling code avoids that issue entirely. On grub2 it works a bit different then grub-legacy. CompareVersions() gets called with only 1 value instead of 2 if you have only one kernel, I haven't tried this yet with grub-legacy. And I concentrate more on grub2 because that's the one we replace grub-legacy hopefully soon. Am Donnerstag, den 07.08.2008, 20:51 +0200 schrieb Robert Millan: I think I got it right now, but since we failed an attempt already, and the code around this is so tricky, I'd appreciate if you could test this first: On grub2 it doestn't work with just one as I currently have. update-grub shows: Updating /boot/grub/grub.cfg ... Found Debian background: debian-blueish-wallpaper-640x480.png Found linux image: basename: missing operand Try `basename --help' for more information. done To be a bit more safe with this scripting stuff I currently have /bin/sh as bash and not like normally as dash. After the 2 sed calls I added an echo /tmp/x which gives me this: 1:/boot/2.6.26-1-amd64 2: a:/boot/2.6.26-1-amd64 b: It isn't that easy to get it working for grub2 If CompareVersions() just contains an echo 0 I get just the same as above. The code in 24-5 (lenny) and 30-1 (experimental) which is the one from grub-legacy just works fine for me with only 1 kernel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494158: [grub2] update-grub: uses wrong ordering algorithm (sorts 1.2.3-foo before 1.2.3.1-foo)
I just stick now to the `cloned to grub2' bug, so Robert doestn't hit
me ;)
Am Freitag, den 08.08.2008, 11:01 +0200 schrieb Felix Zielcke:
And I concentrate more on grub2 because that's the one we replace
grub-legacy hopefully soon.
@Henrique: As you can see below grub2's update-grub is a bit different,
Upstream's one only has test_gt() as comparison function and Robert
modified it so it uses CompareVersions()
Even Robert's ported `grub-legacy's update-grub version comparison
thingy' checks only for greater (return value 1 of CompareVersions)
CompareVersions()
{
local a=`echo $1 | sed -e
s,.*/vmlinu[zx]-,,g;s/[._-]\(pre\|rc\|test\|git\)/~\1/g`
local b=`echo $2 | sed -e
s,.*/vmlinu[zx]-,,g;s/[._-]\(pre\|rc\|test\|git\)/~\1/g`
`dpkg --compare-versions $a gt $b`
echo $?
}
test_gt ()
{
local a=`echo $1 | sed -e s/vmlinu[zx]-//g`
local b=`echo $2 | sed -e s/vmlinu[zx]-//g`
return `CompareVersions $a $b`
}
This produces me this:
Found linux image: /boot/vmlinuz-2.6.26-1-amd64-mm1
Found linux image: /boot/vmlinuz-2.6.26-1-amd64
Found initrd image: /boot/initrd.img-2.6.26-1-amd64
Found linux image: /boot/vmlinuz-2.6.26-1-amd64-test1
Found linux image: /boot/vmlinuz-2.6.26-1-amd64-rc1
Found linux image: /boot/vmlinuz-2.6.26-1-amd64-rc1-git1
Found linux image: /boot/vmlinuz-2.6.26-1-amd64-pre1
Found linux image: /boot/vmlinuz-2.6.26-1-amd64-git1
Found linux image: /boot/vmlinuz-2.6.25-1-amd64-mm1
Found linux image: /boot/vmlinuz-2.6.25-1-amd64
Found linux image: /boot/vmlinuz-2.6.25-1-amd64-test1
Found linux image: /boot/vmlinuz-2.6.25-1-amd64-rc1
Found linux image: /boot/vmlinuz-2.6.25-1-amd64-rc1-git1
Found linux image: /boot/vmlinuz-2.6.25-1-amd64-pre1
Found linux image: /boot/vmlinuz-2.6.25-1-amd64-git1
By the way: I know why again where these -pre comes from, it's the one
kernel.org used before they started with -git and -rcN-git
For lenny we should stick with the ordering of etch or so.
But for lenny+1 we should get rid of this old stuff in at least grub2
Today you get only official patches for -git -rcN -rcN-git and -mmN
and the -mm aren't handled ;)
I don't know where these others come from grub-legacy handles like -test and -ac
I couldn't figure out with playing with this ~ thingy how to tell dpkg that
-rc1-git1 is higher then -rc1
So it seems like dpkg --compare-versions isn't that perfect for official
kernel.org patch numbering ;)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494158: [grub2] update-grub: uses wrong ordering algorithm (sorts 1.2.3-foo before 1.2.3.1-foo)
Am Freitag, den 08.08.2008, 13:06 +0200 schrieb Felix Zielcke: This produces me this: Found linux image: /boot/vmlinuz-2.6.26-1-amd64-mm1 Found linux image: /boot/vmlinuz-2.6.26-1-amd64 Found initrd image: /boot/initrd.img-2.6.26-1-amd64 Found linux image: /boot/vmlinuz-2.6.26-1-amd64-test1 Found linux image: /boot/vmlinuz-2.6.26-1-amd64-rc1 Found linux image: /boot/vmlinuz-2.6.26-1-amd64-rc1-git1 Found linux image: /boot/vmlinuz-2.6.26-1-amd64-pre1 Found linux image: /boot/vmlinuz-2.6.26-1-amd64-git1 Found linux image: /boot/vmlinuz-2.6.25-1-amd64-mm1 Found linux image: /boot/vmlinuz-2.6.25-1-amd64 Found linux image: /boot/vmlinuz-2.6.25-1-amd64-test1 Found linux image: /boot/vmlinuz-2.6.25-1-amd64-rc1 Found linux image: /boot/vmlinuz-2.6.25-1-amd64-rc1-git1 Found linux image: /boot/vmlinuz-2.6.25-1-amd64-pre1 Found linux image: /boot/vmlinuz-2.6.25-1-amd64-git1 In case somebody is interested, this is now the output with the unmodified /etc/grub.d/10_linux currently in lenny and experimental which `should' use the grub-legacy method: Found linux image: /boot/vmlinuz-2.6.26-1-amd64-git1 Found linux image: /boot/vmlinuz-2.6.26-1-amd64-mm1 Found linux image: /boot/vmlinuz-2.6.26-1-amd64 Found initrd image: /boot/initrd.img-2.6.26-1-amd64 Found linux image: /boot/vmlinuz-2.6.26-1-amd64-rc1-git1 Found linux image: /boot/vmlinuz-2.6.26-1-amd64-rc1 Found linux image: /boot/vmlinuz-2.6.26-1-amd64-pre1 Found linux image: /boot/vmlinuz-2.6.26-1-amd64-test1 Found linux image: /boot/vmlinuz-2.6.25-1-amd64-git1 Found linux image: /boot/vmlinuz-2.6.25-1-amd64-mm1 Found linux image: /boot/vmlinuz-2.6.25-1-amd64 Found linux image: /boot/vmlinuz-2.6.25-1-amd64-rc1-git1 Found linux image: /boot/vmlinuz-2.6.25-1-amd64-rc1 Found linux image: /boot/vmlinuz-2.6.25-1-amd64-pre1 Found linux image: /boot/vmlinuz-2.6.25-1-amd64-test1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494158: [grub2] update-grub: uses wrong ordering algorithm (sorts 1.2.3-foo before 1.2.3.1-foo)
Am Freitag, den 08.08.2008, 13:06 +0200 schrieb Felix Zielcke: I couldn't figure out with playing with this ~ thingy how to tell dpkg that -rc1-git1 is higher then -rc1 So it seems like dpkg --compare-versions isn't that perfect for official kernel.org patch numbering ;) Ok I noticed I tested this wrong :( fz:/boot# dpkg --compare-versions 2.6.26-1-amd64~rc1 gt 2.6.26-1-amd64~rc1~git1 ;echo $? 0 fz:/boot# dpkg --compare-versions 2.6.26-1-amd64~rc1 gt 2.6.26-1-amd64~rc1-git1 ;echo $? 1 So i think it works if there is only 1 ~ instead of 2 Unfortunately I'm not that good in regexp but I try to figure out how this can be done: -git - ~git -rc - ~rc -rcN-git ~rcN-git -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494158: [grub2] update-grub: uses wrong ordering algorithm (sorts 1.2.3-foo before 1.2.3.1-foo)
Am Freitag, den 08.08.2008, 09:49 -0300 schrieb Henrique de Moraes Holschuh: On Fri, 08 Aug 2008, Felix Zielcke wrote: I couldn't figure out with playing with this ~ thingy how to tell dpkg that -rc1-git1 is higher then -rc1 khazad-dum:~$ dpkg --compare-versions 2.6.23.1-rc1-git3 gt 2.6.23.1-rc1 ; echo $? 0 khazad-dum:~$ dpkg --compare-versions 2.6.23.1~rc1-git3 gt 2.6.23.1~rc1 ; echo $? 0 It will do the right thing, as long as you don't get two ~ in there. You cannot mangle the version string to ~git#~rc# (or ~-git#-~rc#, etc), as that will certainly not give you the right order :P Yes and this double ~ is the problem for this -rc1 -rc1-git1 case. So it seems like dpkg --compare-versions isn't that perfect for official kernel.org patch numbering ;) No, it isn't, otherwise we would not need mangling :) But it *CAN* do all that is needed, if we use ~ correctly. I have only done very little easy things with regular expressions, so I don't know really how to change the comparison code Robert made for grub-legacy so that the ordering is right with dpkg. Seems like we really need to play around with ~ to get it really right. I wonder if that is really better with dpkg and ~ instead of our current method. Plain versions are luckly not a problem with dpkg, but these -rc -mm -git and such are a problem. The majority has probable only different base kernel numbers i.e. 2.6.25 2.6.26 and not for one base version different -rc -mm thingys. But if we fix this now then this should be even fixed for people having more then one of these kernels. Btw. I think I confused again a bit with this test_gt() function in grub2 I have modified that one too [ `CompareVersions $a $b` == 1 ] return $? That's the current one so CompareVersions() can just be the same for grub-legacy and grub2 Well probable better to make this change first on grub-legacy and then adopting it to grub2 and not the other way round. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494158: [grub2] update-grub: uses wrong ordering algorithm (sorts 1.2.3-foo before 1.2.3.1-foo)
I really should have sticked with my easy debugging method I already mentioned in the report (that echo /tmp/x thingy) I thought removing the greedy g on the regexps would just solve the problem for us, but it doestn't: fz:/etc/grub.d# dpkg --compare-versions 2.6.26-1-amd64~rc1-git1 gt 2.6.26-1-amd64; echo $? 0 fz:/etc/grub.d# dpkg --compare-versions 2.6.26-1-amd64~rc1~git1 gt 2.6.26-1-amd64; echo $? 1 This looks for me more then a dpkg issue. ~x-y should be like ~x~y i.e. that the above one returns the same. Maybe I just think again too difficult. There's no need to solve this problem with just one regexp on the 2 versions supplied and then comparing these 2 with just one dpkg call. About these --mm kernels: (probable more for Robert) I forgot we probable should ignore them, i.e. have them above the normal ones as right now 2.6.26-mm1 is higher/newer then 2.6.26 -mm patches contain the things which should go into the next kernel releases. But there's again this double problem i.e. -rc1-mm1: Found linux image: /boot/vmlinuz-2.6.26-1-amd64-mm1 Found linux image: /boot/vmlinuz-2.6.26-1-amd64-rc1-mm1 Found linux image: /boot/vmlinuz-2.6.26-1-amd64 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466797: config script exits nonzero
Debconf specification says: GO Shows the current set of accumulated items to the user and lets them fill in values, etc. If the backup capability is supported and the user indicates they want to back up a step, this command returns the numeric return code 30. I looked now at a diff between version 1.96+20080219-1 reported against and our current lenny branch. Absolutely nothing has changed which could affect this. For me it seems like you Joey were the only one who had it once so far. At least nobody else cared about this bug. I really would like to get rid of old bugreports, but I'm a bit unsure if I should just close it in the hope nobody else really won't have this again or if we should change something. So I leave it now for a while open in the hope of a useful reply :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493389: update-grub: uses wrong ordering algorithm (sorts 1.2.3-foo before 1.2.3.1-foo)
Am Dienstag, den 05.08.2008, 21:40 +0200 schrieb Felix Zielcke:
The grub2 packages have only one update-grub the one in /usr/sbin
Ok and a update-grub2 which exec's update-grub but it's in /usr/sbin
too.
Probable wasn't that clear so another try:
By switching to grub2 as default, there will be no more a update-grub
thingy in /sbin
I doubt we change something with that /sbin thingy on grub-legacy.
But luckly this is not the point of this bug report :)
If I have some time, I will prepare the patch. But please don't wait on me
for it, if someone else has the time to prepare the patch, please do so.
That's very kind of you, I looked shortly at the comparison code and
couldn't figure out how to change it so it uses the dpkg code for it :)
Luckly grub2's update-grub uses now the comparison code of grub-legacy
so it's not that hard to apply it then to both.
Seems like I think even for bash scripts too complicated
Just replace the CompareVersion function with this:
CompareVersions()
{
dpkg --compare-versions $1 le $2
echo $?
}
update-grub shows me this with my debian sid 2.6.26 kernel and files
with names you reported this bug with:
Found kernel: /boot/vmlinuz-2.6.26-1-amd64
Found kernel: /boot/vmlinuz-2.6.25.14.1-t43
Found kernel: /boot/vmlinuz-2.6.25.14-t43
Found kernel: /boot/vmlinuz-2.6.25.13-t43
Found kernel: /boot/vmlinuz-2.6.25.12-t43
I was about unsure if I should use 'lt' 'le' 'le-nl' or 'lt-nl'
I try to find this now out, but please reply what you think is the best
we should use.
As you can see above it's very easy to test this :)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#419157: Bug #419157 [update-grub]: preseed for some menu.lst options
Hello, The 2 bugreports Robert mentioned in the last mail about your report (419157) are fixed long ago now. For the Xen handling there's now another wishlist bug: 469578 For setting the gfxmode variable and the background image: 493106 But we won't make the background image a variable, it would make things just more complicated and it's used anyway only in 05_debian_theme Can you please check with the current lenny version of grub2 if it fits your needs now or if there's still something missing? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469578: 10_linux creates xen boot entries that don't work
Hello, Am Mittwoch, den 06.08.2008, 21:41 +0100 schrieb Ian Campbell: On Thu, 2008-07-31 at 15:41 +0200, Felix Zielcke wrote: Attached is now a patch which ignores Xen kernels, Unless I am misreading the patch it appears to ignore CONFIG_PARAVIRT=y type Xen kernels which is wrong -- these kernels also boot native and so a normal entry should be created for them. This is useful in both dom0 (since it can boot native) and in domU (since native-style entries are used there). Well the patch was anyway made only for people like the reporter who just want to have that update-grub doestn't add any Xen kernel. But if they can be booted like any normal kernel then yes this is a bit wrong. I just used the config entrys which are in grub-legacy's update-grub for xen kernels, which adds kernels with these as Xen ones not normal ones. It seems [0] that Xen Dom0 support will be soon in the official kernel. I don't know anything about the config options which will be then used. In this case there would need to be a _second_ entry created in domain 0 (dom0 vs. domU detected via presence of a hypervisor binary) in addition to the normal native entry. As I already said, I look into it further when Debian has again a kernel build with Dom0 support. For lenny Xen support in grub2 is too late and grub2 is anyway still not the default. So luckly we have enough time for lenny+1 and with grub2 we shouldn't support any old method used. Robert didn't like the idea to copy the whole 10_linux to a 10_xen and thus duplicating the whole logic. Good to know that the new style ones can just run fine with a normal entry created for them, you just can't have DomU's then. In #419157 Robert said a year ago, that the Xen team should handle the 10_xen They should it know anyway better then us how to make Xen entrys But probable I'll bring it up on grub-devel, maybe this should be even upstream supported. Thanks for reading and replying to this bug report :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493389: update-grub: uses wrong ordering algorithm (sorts 1.2.3-foo before 1.2.3.1-foo)
Am Dienstag, den 05.08.2008, 00:48 -0300 schrieb Henrique de Moraes Holschuh: On Mon, 04 Aug 2008, Robert Millan wrote: Why would you want something in /sbin to call something in /usr/s?bin ? You need to port the algorithm. update-grub is in /usr. Crap. I just noticed it is just a wrapper. Why the heck is it not a symlink, which we would notice at first glance? That excessive hand-holding script you guys have is actually WORSE a solution, chances are someone isn't going to notice it until it is too late, NEWS.Debian or not. It is too easy to forget about it after a while, when there is still an executable with the right name in /sbin. The grub2 packages have only one update-grub the one in /usr/sbin Ok and a update-grub2 which exec's update-grub but it's in /usr/sbin too. If I have some time, I will prepare the patch. But please don't wait on me for it, if someone else has the time to prepare the patch, please do so. That's very kind of you, I looked shortly at the comparison code and couldn't figure out how to change it so it uses the dpkg code for it :) Luckly grub2's update-grub uses now the comparison code of grub-legacy so it's not that hard to apply it then to both. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430513: grub-pc fails to install on evms volumes (dm)
I just searched on the grub-devel archived for evms, if there was any progress about it which didn't make it into this bug report. The last message on this report is from Mathias dated 11. February. I found this with evms on grub2's upstream changelog: 2008-07-25 Robert Millan [EMAIL PROTECTED] * util/getroot.c (find_root_device): Skip devices that match /dev/dm-[0-9]. This lets the real device be found for any type of abstraction (LVM, EVMS, RAID..). (grub_guess_root_device): Do not traverse /dev/mapper (for LVM) and /dev/evms (for EVMS) before traversing /dev. If a /dev/dm-[0-9] device is found first, find_root_device() will now skip it. 2008-02-12 Robert Millan [EMAIL PROTECTED] * util/getroot.c (grub_guess_root_device): Inspect /dev/evms before /dev (like it is done for /dev/mapper). This doesn't provide support for EVMS, but at least it is now easy to identify the problem when it arises. The lenny/sid version has it's last upstream changelog from 07-23 so 2 days before the first change. Mathias could you please try it with the current lenny/sid version and with the newer one in experimental, if these evms devices now work better with grub2 ? Hopefully we can get rid of this old report :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488235: ext2.mod should reject extN with INCOMPAT flags which grub doestn't support
forwaded 488235 http://lists.gnu.org/archive/html/grub-devel/2008-07/msg8.html thanks There are 2 threads about this topic but both with same Subject. Above one is the newer and larger one. The original message from me to grub-devel about this can be found here: http://lists.gnu.org/archive/html/grub-devel/2008-06/msg00391.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493744: grub2: Invalid PO file as Spanish translation
tags 493744 + pending thanks Hello, Am Sonntag, den 03.08.2008, 13:04 +0200 schrieb Christian Perrier: The Spanish debconf translation (debian/po/es.po) recently added for grub2 unfortunately has a double escaping of double quotes on one line, which turns it into an invalid file. I just saw your mail. I noticed this already during a rebuild and fixed it in the lenny branch for the next upload. It's now even displayed on the lintian warning page :( A patch to fix this is attached to this bug report. I think you attached the wrong file, because it's about partman lvm which isn't right for grub2 But thanks for the report. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487565: grub-pc: Chainloading fails even without LVM
Hello, Am Sonntag, den 03.08.2008, 08:49 +0200 schrieb Kai Wasserbäch: Hello Robert, hello Felix Robert Millan wrote: I see that Felix suspects this is a false positive when checking for cross-disk install. If you run sh -x grub-install and send us the output, we could make sure about that. As I already told him privately in german the problem is device.map says (hd0) /dev/hdc (hd1) /dev/hdd But /proc/mounts says everything inclusive /boot is on /dev/hdd I don't know if this should be changed, but better not discuss this in this report ;) I hope, this helps in solving the problem. Thanks this double prefix issue is now solved with the ..24-5 upload we made this night and Robert uploaded :) As soon as you got the new ..24-5 version, please do grub-install --grub-setup=/bin/true (hd0) so core.img gets recreated, if you still want to chainload it. Or for the Linux mdraid guys you can use (md0) if your /boot is on /dev/md0 This issue doestn't exist with grub2 in mbr and so core.img gets directly loaded by it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493631: cdbs: please use stamps for configure/build
Package: cdbs
Version: 0.4.52
Severity: wishlist
Hello,
Not even a month before I started to co-maintaining the grub and grub2 packages
with Robert Millan, so I'm still new to this debian/ stuff.
We have a 9 month bug old filed against grub2 that the package wastes CPU cycles
of the autobuilders: #450505
The problem is that grub2 doesn't use any stamps in debian/rules.
I'm very new to this debian/ stuff and dh-make seems to be creating these stamp
rules by default, as can bee seen on the new maint. packaging guide.
I noticed that dpkg-buildpackage calls ./configure 12 times in the beginning and
13 times in the end.
But we only have 8 .debs generated of it and we would even only need to run
../configure 5 times.
Robert and me both think that this belongs more to the build system used in
Debian, then that every package itself has to implement stamps.
-- System Information:
Debian Release: lenny/sid
APT prefers experimental
APT policy: (500, 'experimental'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages cdbs depends on:
ii debhelper 7.0.16 helper programs for debian/rules
Versions of packages cdbs recommends:
ii autotools-dev 20080123.2 Update infrastructure for config.{
Versions of packages cdbs suggests:
ii devscripts2.10.35scripts to make the life of a Debi
pn doc-base none (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478228: grub-probe: can't handle (raid) md-devices
reassign 492897 grub2 #forgot that it applies to whole grub2 not just grub-probe thanks Hello, Am Sonntag, den 03.08.2008, 21:09 +0200 schrieb Thomas Rösch: Hey Felix Sorry for needing so much time - too much work. No problem, thanks for replying to both mails. mdraids with default 0.90 format works fine with grub2 as long as you aren't installing grub in a chroot to it, That is a common case for repair, if your system fails to boot Yeah chroots are needed, but I couldn't get it to work as I played with mdraid 1 and 5 for testing grub on it. There was a problem with 0.90, but I already forgot it. I also don't want to go back. Format 1.x ist the actual format, a new program should support the actual format (and I don't know how to go back ) #492897 is the cloned bug, for the wishlist request to support this. I don't know where /dev/md/6 come from. See #475585 As I tried the whole mdraid stuff out I always had both forms mdN and md/N As long as you have a /dev/mdN without / everything is fine for grub-probe I don't try grub-install , because I have no time to repair my system, if It do not work. :-( It won't work anyway with the super 1.X format. grub-setup is able to detect this and warn about (see the message from Robert about this in this report) But grub-probe doestn't use that code, it uses only the code real grub uses. As I cloned the bug I wanted to leave it open for the case you've still problems with super 0.90. But I leave it now to Robert if he wants to close it or retitle it to sth. like grub-probe fails to warn about unsupported super 1.X I looked a bit at the Code but using the one grub-setup is using isn't that easy in grub-probe, because grub-probe has to care about LVM devices too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487565: grub-pc: Chainloading fails even without LVM
retitle 487565 multibooting core.img leads to double prefix
thanks
Am Samstag, den 02.08.2008, 06:06 +0200 schrieb Kai Wasserbäch:
Followup-For: Bug #487565
Package: grub-pc
Version: 1.96+20080724-2
Hello,
Hello,
I'm not using an LVM on this machine and still get the error that the file
normal.mod can not be found and in the error message there is an doubleslash
displayed (something along the lines UUID={32Bit-Code}/boot/grub//normal.mod).
I installed GRUB2 yesterday, updating from a GRUB1. I installed it in
chainloader mode as was advised in the Debconf message (per pre-selection).
As I'm not quite sure which kind of additional/further information you may
need,
please feel free to ask me for any.
Please type on the rescue prompt of grub set
and then tell us the value of prefix and root
You use only /dev/hdd on your linux but it's (hd1) in device.map
If you're BIOS directly boots from hdd then change your device.map
please, it will only be regenerated if it doestn't exist or is clearly
wrong i.e. missing devices.
Or do you have grub-legacy somehow on (hd0) sdc installed and loading
grub2 from (hd1) sdd?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487565: grub-pc: Chainloading fails even without LVM
Am Samstag, den 02.08.2008, 11:31 +0200 schrieb Felix Zielcke: You use only /dev/hdd on your linux but it's (hd1) in device.map If you're BIOS directly boots from hdd then change your device.map please, it will only be regenerated if it doestn't exist or is clearly wrong i.e. missing devices. Bah, again something which I should do in one email and not 2. Because you have an UUID prefix, I think your device.map order is the problem. grub2 is thinking you want a cross install i.e. have the mbr code on hd0 but /boot on hd1 So if that's the case please change device.map and then do grub-install --no-floppy --grub-setup=/bin/true (hd0) That's what postinst does to generate the core.img with --grub-setup=/bin/true your MBR won't change. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481542: grub2: please user triggers
Am Donnerstag, den 31.07.2008, 16:46 -0400 schrieb Joey Hess: Once apt trigger deferral is implemented, all the triggers will run at the very end of the apt run, which can be quite a long time after the kernel packages are removed and installed. What exactly is this apt trigger derral which will be implemented? Luckly I had to do now a apt-get build-dep grub2 and I noticed the man-db trigger is called after every package is extracted and not after the whole apt/dpkg process after everything setting up. And man-db uses just directory triggers which I first thought of. A trigger which runs after every package has been extracted and not yet configured should work fine for us, too. Will apt change something with that or might there be a problem which I currently can't think of with that method? If it works then I/we only need to find a way that update-grub is run on a grub2 update too but only once if there's kernel update too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481542: grub2: please user triggers
Am Freitag, den 01.08.2008, 12:44 -0400 schrieb Joey Hess: Felix Zielcke wrote: What exactly is this apt trigger derral which will be implemented? #473461 A trigger which runs after every package has been extracted and not yet configured should work fine for us, too. You can't count on triggers doing this, ever. Well, then I think this should be tagged wontfix and we just stay with the current method, that the kernel .deb itself calls update-grub when it's configured. If anyone has an idea how to change the current used method so update-grub gets only called once instead of multiple times, but it does gets called even when dpkg/apt fails to configure every package and so fails probable to run the trigger then please tell us. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473461: #473461 should use dpkg --no-triggers
Please consider the wishlist bug against grub2 for implementing a trigger (481542) before implementing this in apt. Currently update-grub, which generates menu.lst/grub.cfg, gets called on a kernel removal, a kernel install and on grub update itself. As you can see in the report with current sid apt/dpkg the man-db trigger gets called after everything is extracted but before the packages are configured. This would be fine for grub too. But if this gets changed and we can't rely that our trigger gets called after extracting everything then it might be that update-grub doestn't ever get called if the whole apt/dpkg configure run fails at some point and then you probable have only a not anymore installed kernel in the grub menu. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481542: grub2: please user triggers
tag 481542 wontfix thanks Am Freitag, den 01.08.2008, 19:03 +0200 schrieb Felix Zielcke: Well, then I think this should be tagged wontfix and we just stay with the current method, that the kernel .deb itself calls update-grub when it's configured. Ok I talked now with Robert and we both are not changing anything now on the grub-legacy and grub2 packages. I forgot that after the extracting stage there's no initrd for the kernel so we would need to modify update-grub to assume one if the kernel version number seems to be a Debian one. So if anyone wants that there's only one call to update-grub in the whole update process, then please provide a patch against the trunk SVN which avoids the problem that the update-grub trigger might be not run. And please don't forget that /etc/kernel-img.conf which belongs to the kernel-team and not to us needs a change too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493289: grub2: config parser accesses a pointer after grub_free is called on that one
Source: grub2 Severity: important If you press e to edit the menu entry and then you want to boot it with Ctrl-x then it can happen that you get a crash with a malloc magic message or that the text gets corrupted and if you fix it then the malloc magic crash The original report on grub-devel and the fix from Bean for this can be found at: http://lists.gnu.org/archive/html/grub-devel/2008-08/msg00025.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469578: 10_linux creates xen boot entries that don't work
Attached is now a patch which ignores Xen kernels,
by grepping for the config options which uses grub-legacy to detect
them.
It seems [0] that Xen Dom0 support will be soon in the official kernel.
I don't know anything about the config options which will be then used.
So it could be that the config options aren't that right in the future,
when there's again a Xen Dom0 kernel in Debian or if you compile your
own.
But if anyone wants to work on implementing Xen specific handling for
grub2 then please base your work on that patch now.
Don't use the filename as I first did.
[0] http://lists.debian.org/debian-devel/2008/07/msg01012.html
--- /etc/grub.d/10_linux 2008-07-28 12:51:00.0 +0200
+++ /etc/grub.d/10_linux 2008-07-31 14:54:34.0 +0200
@@ -150,7 +150,7 @@
}
list=`for i in /boot/vmlinu[xz]-* /vmlinu[xz]-* ; do
-if grub_file_is_not_garbage $i ; then echo -n $i ; fi
+if grub_file_is_not_garbage $i ! is_xen_kernel $i ; then echo -n $i ; fi
done`
if [ x$list != x ] ; then
--- /usr/lib/grub/update-grub_lib 2008-07-31 13:05:57.0 +0200
+++ /usr/lib/grub/update-grub_lib 2008-07-31 14:41:32.0 +0200
@@ -156,3 +156,22 @@
fi
return 0
}
+is_xen_kernel()
+{
+ ver=`echo $1 | sed -re 's%[-/A-Za-z]*%%'`
+ # according to grub-legacy's update-grub it applies to both.
+ if `grep -q CONFIG_XEN=y /boot/config-${ver}` ; then
+
+# old style non-CONFIG_PARAVIRT kernels with xen0 support.
+if `grep -q CONFIG_XEN_PRIVILEGED_GUEST=y /boot/config-${ver}` ; then
+ return 0
+fi
+
+# new style CONFIG_PARAVIRT kernels with xen support. There is
+# no distinction between xen0 and xenU in these kernels.
+ if `grep -q CONFIG_PARAVIRT=y /boot/config-${ver}` ; then
+return 0
+ fi
+ fi
+ return 1;
+}
Bug#492589: #492589 winecfg crashes on audio tab
As I reported the bug I forgot that my TV Card with BT878 chip has an ALSA audio module, too. But now I tried it with any module removed which has oss snd or audio in it's name or else sounds like it has something to do with that. I removed and purged even every package which contains oss and removed alsa-base, alsa-utils and linux-sound-base I removed ~/.wine and tried it again with my normal useraccount and as root and it still crashes on the audio tab /proc doestn't contain anything related to sound, alsa or oss. So probable more a library issue then with my Soundcard or TV-Card. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493106: New environment variables (for gfxmode and background path and other)
Am Donnerstag, den 31.07.2008, 13:58 +0200 schrieb spamgrinder:
My only change in 00_header script is set gfxmode=1024x768. It
overwrites default 640x480.
I would like to keep the gfxmode variable in /etc/default/grub.
Attached is a patch which adds GRUB_GFXMODE to /etc/default/grub
--- /etc/default/grub 2008-07-31 16:34:38.0 +0200
+++ /etc/default/grub 2008-07-31 16:33:23.0 +0200
@@ -10,3 +10,8 @@
# Uncomment if you don't want GRUB to pass root=UUID=xxx parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true
+
+# The resolution used on graphical terminal
+# note that you can use only modes which your graphic card supports with vbe
+# you can see them in grub with command vbeinfo
+GRUB_GFXMODE=640x480
--- /etc/grub.d/00_header 2008-07-31 16:23:09.0 +0200
+++ /etc/grub.d/00_header 2008-07-31 16:25:02.0 +0200
@@ -31,6 +31,7 @@
if [ x${GRUB_DEFAULT} = x ] ; then GRUB_DEFAULT=0 ; fi
if [ x${GRUB_TIMEOUT} = x ] ; then GRUB_TIMEOUT=5 ; fi
+if [ x${GRUB_GFXMODE} = x ] ; then GRUB_GFXMODE=640x480 ; fi
cat EOF
set default=${GRUB_DEFAULT}
@@ -43,7 +44,7 @@
prepare_grub_to_access_device `${grub_probe} --target=device ${GRUB_FONT_PATH}`
cat EOF
if font `make_system_path_relative_to_its_root ${GRUB_FONT_PATH}` ; then
- set gfxmode=640x480
+ set gfxmode=${GRUB_GFXMODE}
insmod gfxterm
insmod vbe
terminal gfxterm
--- /usr/sbin/update-grub 2008-07-31 16:32:05.0 +0200
+++ /usr/sbin/update-grub 2008-07-28 12:51:00.0 +0200
@@ -152,7 +152,7 @@
export GRUB_DEVICE GRUB_DEVICE_UUID GRUB_DEVICE_BOOT GRUB_DEVICE_BOOT_UUID GRUB_FS GRUB_FONT_PATH GRUB_PRELOAD_MODULES
# These are optional, user-defined variables.
-export GRUB_DEFAULT GRUB_TIMEOUT GRUB_DISTRIBUTOR GRUB_CMDLINE_LINUX GRUB_CMDLINE_LINUX_DEFAULT GRUB_TERMINAL GRUB_SERIAL_COMMAND GRUB_DISABLE_LINUX_UUID GRUB_GFXMODE
+export GRUB_DEFAULT GRUB_TIMEOUT GRUB_DISTRIBUTOR GRUB_CMDLINE_LINUX GRUB_CMDLINE_LINUX_DEFAULT GRUB_TERMINAL GRUB_SERIAL_COMMAND GRUB_DISABLE_LINUX_UUID
exec ${grub_cfg}.new
Bug#481542: grub2: please user triggers
retitle 481542 please use triggers for update-grub thanks I looked now at the man-db package which is a very easy implementation for triggers. I think it would be enough for us to do it like they did. debian/triggers: interest /boot debian/*.postinst: if [ $1 = triggered ]; then update-grub fi IMHO it's important to consider how triggers would handle a situation such as an apt run that removed the running kernel added a new kernel, and then failed. In this case, the grub trigger might not run, which would leave a menu.lst that contained only a nonexistent kernel. Well if removing the current installed kernel suceeded, but installing the new one failed, then I think you don't have any kernel at all in /boot Removing the current kernel should tell dpkg to run our trigger. I don't think that if installing a new kernel fails, that the trigger doestn't get called, as long as the whole install/update apt/dpkg process keeps running But I try to reproduce this. Luckly we currently have currently anyway a package in experimental. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481542: grub2: please user triggers
Am Donnerstag, den 31.07.2008, 16:46 -0400 schrieb Joey Hess: I didn't say that adding the new kernel failed. A later package could fail. Or the power could fail before dpkg got around to calling the triggers. Once apt trigger deferral is implemented, all the triggers will run at the very end of the apt run, which can be quite a long time after the kernel packages are removed and installed. Urm yeah sorry that i misunderstood you. That's really a good question how to deal with that. But I doubt we could anything do on that case. Either we use triggers and risk that it's not run by a powerloss, or some apt/dpkg error elsewhere. Or we just stay with the old method which is btw. not grub's fault, but the kernel-team's which declare a postinst and postrm hook in /etc/kernel-img.conf which get run on a kernel install or remove. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481542: grub2: please user triggers
(This is also potentially a problem with the initramfs-tools triggers, I guess..) I have now installed etch in a VM and then used aptitude to update it to lenny As soon as the kernel is configured, there's a mkinitramfs-kpkg call and after everything is finished the update-initramfs trigger is run. Note that ubuntu has triggerised grub; I don't know how/if they deal0 with that case. I just started to learn about these triggers. I looked at the ubuntu packages. grub2 doestn't have a trigger. But grub-legacy has a interest update-grub trigger. If that means that when another package runs update-grub then not the real one is called, but just dpkg informed to run this trigger, then this would be probable better then my interest /boot trigger. Their linux_2.6.26-5.13 package doestn't have any trigger update-grub stuff, only the postinst_hook and postrm_hook, that our kernel packages probable has too. Their grub-legacy has a kernel-helper and last-good-boot script which hardlinks the last working kernel to /boot/last-good-boot/ so on ubuntu you probable always have a working boot entry on at least grub-legacy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469578: 10_linux creates xen boot entries that don't work
Am Freitag, den 01.08.2008, 02:10 +0200 schrieb Robert Millan: Do we really want this? I thought it was unnecessary because of those Linux versions being obsolete. Yeah now with grub2 and Debian stable lenny we shouldn't support any old style Xen kernels. Probable the best is to just wait untill Xen DomO support is merged in the upstream kernel and then implementing support for that, if there's a need for it. It will probable not change to first load the Xen Hypervisor and then loading the vmlinuz as a module for it. But so far as I understand it it should be then possible to load the same vmlinuz binary as a dom0 and a domU kernel. Anyway, if you're inclined to, I suggest that you bring it up in upstream. As soon as there is a -xen Dom0 kernel I look into it and then probable brining it up upstream :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475585: grub-probe: error: Unknown kind of RAID device `/dev/md/1'
reassign 475585 grub-common
thanks
With current sid I wasn't able to just get the /dev/md/N devices,
but not the /dev/mdN too.
So how did you get it working?
Attached is a patch which I sent to grub-devel too.
Plaese reply, if it now works for you.
Index: util/getroot.c
===
--- util/getroot.c (Revision 1753)
+++ util/getroot.c (Arbeitskopie)
@@ -460,6 +460,12 @@
memcpy (grub_dev, os_dev + 5, 7);
grub_dev[7] = '\0';
}
+ else if (os_dev[7] == '/' os_dev[8] = '0' os_dev[8] = '9')
+ {
+ memcpy (grub_dev, os_dev + 5, 2);
+ memcpy (grub_dev + 2, os_dev + 8, 5);
+ grub_dev[7] = '\0';
+ }
else
grub_util_error (Unknown kind of RAID device `%s', os_dev);
Bug#491977: grub-probe fails with Cannot find a GRUB drive for /dev/dm-N.
Am Dienstag, den 29.07.2008, 08:39 +0200 schrieb martin f krafft: also sprach Robert Millan [EMAIL PROTECTED] [2008.07.29.0014 +0200]: debby:~# dmraid -r [...] I don't know enough about mdadm to determine whose fault is it. But it seems this is really a corner case problem, and only happens in a very specific situation. Therefore I'm lowering severity. I'm CCing the mdadm maintainers; maybe they know how could update-grub reliably obtain the physical device names in your setup, or how to fix mdadm so that it outputs physical devices in a way that makes update-grub happy. mdadm has nothing to do with dmraid. md != dm. Before Robert wrote the Mail I talked with him a bit about this. I have myself a dmraid with a Nvidia nForce Motherboard Chip. I never used mdadm to get my RAID0 working, I always used dmraid which does this for me, without any interaction from me. Am Montag, den 28.07.2008, 22:36 +0200 schrieb Moritz Naumann: debby:~# mdadm -D /dev/md0 .. Number Major Minor RaidDevice State 0 25450 active sync /dev/dm-5 1 2542- spare /dev/dm-2 debby:~# But he used mdadm to get his Raid working, what you shouldn't do. We have now the problem that GRUB sees it as a normal Linux software raid but then fails to install to it. As Robert already said, we need the reail sdN or hdN devices but not the dm-N ones. There are hopefully not many people who use the normal linux software raid to get there fake hardwarwe raid controllers to work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491977: grub-probe fails with Cannot find a GRUB drive for /dev/dm-N.
Am Dienstag, den 29.07.2008, 15:50 +0200 schrieb martin f krafft: also sprach Felix Zielcke [EMAIL PROTECTED] [2008.07.29.1541 +0200]: There are hopefully not many people who use the normal linux software raid to get there fake hardwarwe raid controllers to work. One should hope dmraid never existed or will soon cease to exist. Hm probable it wouldn't be a much differnet if you use dmraid or mdadm on the real sdN and hdN devices. The problem in this case is, dmraid created dm-N devices which map to the sdN and hdN devices (I have them too and I wonde why, I think there just the same as my sdN) and then he used mdadm with the dm-N devices. But if he wanted to use md raid instead of dmraid then he should have used the real sdN and hdN devices. But we have now the problem how to detect this and get GRUB working with it. It's a problem for us, if you use md raid on the dm-N devices. md raid on real sdN and hdN is working fine. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478228: grub-probe: can't handle (raid) md-devices
clone 478228 -1 retitle -1 grub2 should support mdraid 1.X format of superblock severity -1 wishlist thanks /proc/mdstat: md9 : active raid1 sdc9[3] sda9[2] 979952 blocks super 1.0 [2/2] [UU] md6 : active raid10 sdb6[0] sdd6[3] sdc6[2] sda6[1] 97658880 blocks super 1.0 128K chunks 2 near-copies [4/4] [] Guntsche Michael said yesterday on grub-devel now, that grub2 can only handle the default 0.90 superblock format but as you can see above you are using 1.0 even for /boot man mdadm says: The difference between 0.90 and 1.X is that 0.90 only supports 28 devices and 2 TB. The difference between 1.0, 1.1 and 1.2 is only the position where it's stored on the devices. mdraids with default 0.90 format works fine with grub2 as long as you aren't installing grub in a chroot to it, but have booted your system with it. So please recreate your /boot md with default format 0.90 and make sure it's fully synced i.e. /proc/mdstat shows [UU] grub-probe has problems with missing devices or not fully synced raids. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478228: grub-probe: can't handle (raid) md-devices
From: Robert Millan [EMAIL PROTECTED]
But we have a check for this:
/* FIXME: Also support version 1.0. */
if (sb.major_version != 0 || sb.minor_version != 90)
{
grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET,
Unsupported RAID version: %d.%d,
sb.major_version, sb.minor_version);
return 0;
}
isn't this message reflected in grub-probe -vv output?
I saw this today during my mdraid debuginng.
But in the whole Bugreport there's only Scanning for RAID devices and only once
Unsupported RAID version, yours.
But I now read again mdadm(8)
I should have just pasted that part in my mail before.
1.0 stores the superblock at the end of the device.
It doestn't say where 0.90 stores it but the grub code for it looks like it's
in the beginning of it.
1.1 stores it in the start.
1.2 stores it 4K from start.
This is a bit tricky to check all 4 formats.
(that's why I CC the cloned bug.)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492717: debian-installer: choosing grub2 created hd(0, 0) and not hd(0, 1) for windows chainload
Package: debian-installer Severity: minor I have lenny installed with the weekly AMD64 DVD 1 in expert mode and PPPoE for the files not on the first DVD I choose too install grub2 and it put in grub.cfg set root(hd0,0) for chainloading Windows but with grub2 partitions start now with 1 and not like on grub-legacy with 0 So it should be (hd0,1) in my case -- System Information: Debian Release: lenny/sid APT prefers experimental APT policy: (500, 'experimental'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-2-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478228: grub-probe can't handle (raid) md-devices
Hello, grub-probe: info: opening md6 /home/rmh/hacking/grub/debian/upload/grub2-1.96+20080704/kern/disk.c:220: Opening `md6'... /home/rmh/hacking/grub/debian/upload/grub2-1.96+20080704/kern/disk.c:299: Opening `md6' failed. /home/rmh/hacking/grub/debian/upload/grub2-1.96+20080704/kern/disk.c:312: Closing `md6'. grub-probe: error: unknown device md6 Hmm, I don't know how it should look like. So please update grub-common (and better grub-pc also) to 1.96+20080724-2 which should be in the next days in testing on the mirrors. Recreate your devicemap with grub-mkdevicemap --no-floppy and please check your raid config with mdadm. You should be using /dev/md6 devices and not /dev/md/6, because the latter aren't yet supported by grub-probe Try again grub-install and if it fails then again grub-probe -vv I hope that the output then isn't the same as you had. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487565:
Am Montag, den 28.07.2008, 18:36 +0200 schrieb Henry-Nicolas Tourneur: I have the same problem with the latest version available in testing (same as sid). What you mean with same as sid? The Version currently in sid 1.96+20080724-2 just migrated to testing, (I received the mail about it today at 16:39 UTC) this means that ftp-master got just updated but the mirrors of course needs 1-2 days to get the change. But afaik there are no changes related to this. With set you can see what prefix is set to and for me without using raid or lvm it has a slash in the end to and it loads fine. I don't think GRUB2 adds another slash just for md prefixes and not for the normal hd ones If you use RAID 1 then you should be able to replace md with hd without problems in prefix and then try 'insmod normal' If it works you can do 'normal' to get the menu Shouldn't this bug be forwarded upstream ? Feel free to do. [EMAIL PROTECTED] but you need to subscribe first. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#467169: grub-pc: [PATCH] fails to handle resume=/dev/... or more than one option - in debconf
Is there any character we could use for the regexp instead of /, that is known not to collide with any Linux cmdline options ? If it can be simplified this way, I'd prefer that instead. Note that I know of . The kernel documentation has no statement in kernel-parameters.txt on this. What about § ? I don't think it has any special meaning in the Kernel or Bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465144: menu.lst: wrong default entry 0saved
I'd rather have /boot/grub cleaned up from any grub legacy cruft, everything imported into grub2 and simply make grub2 bullet proof, so the chain-loading workaround is no longer necessary If you choose to chainload then debconf tells you to use upgrade-from-grub-legacy which cleans up grub-legacy's file from /boot/grub But else neither grub-legacy's files nor grub2's files are cleaned up from /boot/grub Please see 470400 Is this 0saved problem still an issue with current grub-legacy and grub-pc versions in sid? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487565:
Am Montag, den 28.07.2008, 21:03 +0200 schrieb Henry-Nicolas Tourneur: Oh, I just mean that the version of this package is the same in sid and in testing. I'v installed the package this afternoon and I'm using 1.96 +20080724-2. Fine. prefix = (hd1,1)(md1)/boot/grub root=hd1,1 The prefix looked strange to me, so I typed : set prefix=(md1)/boot/grub insmod normal normal And everything works ok. The original report was with: invalid file '(md0)/boot/grub//normal.mod' Not a double prefix like you have. And this issue should be solved now, I had once a fd prefix and there it displayed afair a doubleslash too. So grub2 is still using it in case prefix doestn't end with / but it now shouldn't have anymore a problem with // If a doubleslash is still for anyone a problem then please tell us. Off course, such a procedure isn't usefull at every startup but I guess that the problem come from the chainload because the only place where I found something about hd1 is menu.lst (and it is hd1,0, not hd1,1, strange). I thought there were recently another bugreport with such a double prefix but I can't find it now. check that /boot/grub/grub.cfg is correctly. But as I'm not sure that it come from the chainload I don't want to run upgrade-from-grub-legacy, to avoid staying with an unbootable system. If grub.cfg is right, then this is probable a chainloading problem. It should work if you use grub2 in the MBR. In case it's not then you already wrote how to fix this so you can boot fine. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491977: grub-probe fails with Cannot find a GRUB drive for /dev/dm-N.
Am Montag, den 28.07.2008, 22:36 +0200 schrieb Moritz Naumann: Number Major Minor RaidDevice State 0 25450 active sync /dev/dm-5 1 2542- spare /dev/dm-2 debby:~# That's very strange. Normally you should have your md devices on real disks or real partitions and then using the md devices for your LVM You shouldn't do this and I even don't see a sense in there. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491404: www.debian.org: providing patch for english /devel/
tag 491404 patch thanks Here's a patch against current cvs of webwml/english/devel/index.html Index: english/devel/index.wml === RCS file: /cvs/webwml/webwml/english/devel/index.wml,v retrieving revision 1.208 diff -u -r1.208 index.wml --- english/devel/index.wml 9 Jul 2008 14:30:32 - 1.208 +++ english/devel/index.wml 28 Jul 2008 23:34:43 - @@ -238,7 +238,7 @@ provide collections of valuable information to maintainers. /dd -dta href=$(DOC)/developers-reference/ch-resources#s-pkg-tracking-systemThe +dta href=$(DOC)/developers-reference/resources#s-pkg-tracking-systemThe Package Tracking System/a/dt dd For developers that wish to keep up-to-date with other packages, the @@ -255,7 +255,7 @@ create, adopt or orphan packages. /dd -dta href=$(DOC)/developers-reference/ch-resources#s-incoming-system\ +dta href=$(DOC)/developers-reference/resources#s-incoming-system\ Incoming system/a/dt dd New packages are uploaded into the Incoming system on the internal @@ -284,7 +284,7 @@ to do to help the project, this is the right place to start. /dd -dta href=$(DOC)/developers-reference/ch-resources#s-experimental\ +dta href=$(DOC)/developers-reference/resources#s-experimental\ Experimental distribution/a/dt dd The emexperimental/em distribution is used as a temporary
Bug#487565: grub2 fails to boot with softraid and chainloading
Am Montag, den 28.07.2008, 21:27 +0200 schrieb Felix Zielcke: The original report was with: invalid file '(md0)/boot/grub//normal.mod' Not a double prefix like you have. I just tried it out now myself in VMware. This wrong double prefix is clearly introduced by chainloading. You won't have that Problem if you directly load grub2 in your MBR just run upgrade-from-grub-legacy and you'll be fine. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491977: grub-probe fails with Cannot find a GRUB drive for /dev/dm-N.
Am Sonntag, den 27.07.2008, 15:07 +0200 schrieb Moritz Naumann: Unfortunately, it doesn't work with 1.96+20080724-2 either: I just saw that PATH contains /usr/local before /usr, I always thought it would be the other way round. So please remove any old grub files lyning there around and maybe even purge grub-common comepletely and install it again. Postinst uses grub-probe in your PATH not directly /usr/sbin/grub-probe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492589: winecfg crashes on audio tab
Package: wine-bin Version: 1.0.0-1 Severity: normal File: /usr/bin/winecfg I have a Creative X-Fi Soundcard with OpenSoundSystem 4.0 installed from the Linux 2.6 AMD64 DEB from http://www.opensound.com/download.cgi winecfg crashes if I click on Audio, attached is the output My sound devices in /dev: # l mixer* dsp* snd* oss/sbxfi0/ lrwxrwxrwx 1 root root 12 27. Jul 16:24 dsp - /dev/dsp_out lrwxrwxrwx 1 root root 20 27. Jul 16:24 dsp0 - /dev/oss/sbxfi0/pcm0 lrwxrwxrwx 1 root root 22 27. Jul 16:24 dsp1 - /dev/oss/sbxfi0/pcmin0 lrwxrwxrwx 1 root root 22 27. Jul 16:24 dsp_in - /dev/oss/sbxfi0/pcmin0 lrwxrwxrwx 1 root root 20 27. Jul 16:24 dsp_mmap - /dev/oss/sbxfi0/pcm0 lrwxrwxrwx 1 root root 20 27. Jul 16:24 dsp_out - /dev/oss/sbxfi0/pcm0 crw-rw-rw- 1 root root 250, 1 27. Jul 11:52 mixer lrwxrwxrwx 1 root root 20 27. Jul 16:24 mixer0 - /dev/oss/sbxfi0/mix0 crw-rw-rw- 1 root root 250, 0 27. Jul 11:52 sndstat oss/sbxfi0/: insgesamt 0 crw-rw-rw- 1 root root 249, 2 27. Jul 11:52 mix0 crw-rw-rw- 1 root root 249, 3 27. Jul 11:52 pcm0 crw-rw-rw- 1 root root 249, 5 27. Jul 11:52 pcmin0 -- System Information: Debian Release: lenny/sid APT prefers experimental APT policy: (500, 'experimental'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-2-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages wine-bin depends on: ii lib32ncurses5 5.6+20080713-1 shared libraries for terminal hand ii libc6-i3862.7-12 GNU C Library: 32bit shared librar ii libwine 1.0.0-1Windows API implementation - libra ii x11-utils 7.3+2 X11 utilities wine-bin recommends no packages. Versions of packages wine-bin suggests: ii libwine-gl1.0.0-1Windows API implementation - OpenG pn libwine-print none (no description available) Versions of packages libwine depends on: ii ia32-libs 2.6ia32 shared libraries for use on a ii libc6-i3862.7-12 GNU C Library: 32bit shared librar -- no debconf information wine: Unhandled page fault on read access to 0x at address 0x7ee018e1 (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x in 32-bit code (0x7ee018e1). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7ee018e1 ESP:0033e570 EBP:0033ebb8 EFLAGS:00010246( - 00 -RIZP1) EAX:0012cbb0 EBX:7ee1458c ECX:00110048 EDX: ESI: EDI:7ee14298 Stack dump: 0x0033e570: 0058 7ee0feb3 7ee0fead 0x0033e580: 00123028 0001 00010020 7ee0fea2 0x0033e590: 7ebafbe0 f7ddfe11 7bc652bb 7ec7fb51 0x0033e5a0: 0033e5bc 0033e5fc 0033e638 7ec7fb51 0x0033e5b0: 0033e5bc 7ecb0548 0033e5c8 00010046 0x0033e5c0: 10de Backtrace: =1 0x7ee018e1 in winecfg (+0x118e1) (0x0033ebb8) 2 0x7ee019c0 AudioDlgProc+0xc0() in winecfg (0x0033ec68) 3 0x7ec8dc8a WINPROC_wrapper+0x1a() in user32 (0x0033ec98) 4 0x7ec8f1ee in user32 (+0xaf1ee) (0x0033ecd8) 5 0x7ec8f34a in user32 (+0xaf34a) (0x0033ed18) 6 0x7ec17a73 DefDlgProcW+0x83() in user32 (0x0033ed48) 7 0x7ec8dc8a WINPROC_wrapper+0x1a() in user32 (0x0033ed78) 8 0x7ec8f47a in user32 (+0xaf47a) (0x0033edb8) 9 0x7ec9462d in user32 (+0xb462d) (0x0033edf8) 10 0x7ec53db7 in user32 (+0x73db7) (0x0033ee58) 11 0x7ec583c5 in user32 (+0x783c5) (0x0033eeb8) 12 0x7ec588dc SendMessageW+0x4c() in user32 (0x0033eef8) 13 0x7ec1d6e4 in user32 (+0x3d6e4) (0x0033f0c8) 14 0x7ec1e7ba CreateDialogIndirectParamAorW+0x3a() in user32 (0x0033f0e8) 15 0x7ec1e801 CreateDialogIndirectParamW+0x41() in user32 (0x0033f118) 16 0x7e8fec95 in comctl32 (+0x4ec95) (0x0033f178) 17 0x7e8ff8f2 in comctl32 (+0x4f8f2) (0x0033f228) 18 0x7e902fea in comctl32 (+0x52fea) (0x0033f5a8) 19 0x7ec8dc8a WINPROC_wrapper+0x1a() in user32 (0x0033f5d8) 20 0x7ec8f1ee in user32 (+0xaf1ee) (0x0033f618) 21 0x7ec8f34a in user32 (+0xaf34a) (0x0033f658) 22 0x7ec17a73 DefDlgProcW+0x83() in user32 (0x0033f688) 23 0x7ec8dc8a WINPROC_wrapper+0x1a() in user32 (0x0033f6b8) 24 0x7ec8f47a in user32 (+0xaf47a) (0x0033f6f8) 25 0x7ec9462d in user32 (+0xb462d) (0x0033f738) 26 0x7ec53db7 in user32 (+0x73db7) (0x0033f798) 27 0x7ec583c5 in user32 (+0x783c5) (0x0033f7f8) 28 0x7ec588dc SendMessageW+0x4c() in user32 (0x0033f838) 29 0x7e914ea8 in comctl32 (+0x64ea8) (0x0033f868) 30 0x7e919ab4 in comctl32 (+0x69ab4) (0x0033f958) 31 0x7ec8dc8a WINPROC_wrapper+0x1a() in user32 (0x0033f988) 32 0x7ec8f47a in user32 (+0xaf47a) (0x0033f9c8) 33 0x7ec9462d in user32 (+0xb462d) (0x0033fa08) 34 0x7ec53ed6 DispatchMessageW+0x96() in user32 (0x0033fa48) 35 0x7ec1ed31 IsDialogMessageW+0x111() in user32 (0x0033fbc8) 36 0x7e90370d in comctl32 (+0x5370d) (0x0033fc28) 37 0x7e903b45 PropertySheetW+0x1d5() in
Bug#492591: evolution: option to have english on name wrote part on replying to an email on non-english systems
Package: evolution Version: 2.22.3.1-1 Severity: wishlist As you can see below my locale is german, when I reply to an email evolution writes Am date schrieb name I would like to have this in english without having whole evolution in english. That's an option I miss from Outlook and Windows Mail the successor of Outlook Express :) -- System Information: Debian Release: lenny/sid APT prefers experimental APT policy: (500, 'experimental'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-2-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages evolution depends on: ii dbus 1.2.1-2 simple interprocess messaging syst ii evolution-common 2.22.3.1-1architecture independent files for ii evolution-data-server 2.22.3-1 evolution database backend server ii gconf2 2.22.0-1 GNOME configuration database syste ii gnome-icon-theme 2.22.0-1 GNOME Desktop icon theme ii gtkhtml3.143.18.3-1 HTML rendering/editing library - b ii libart-2.0-2 2.3.20-2 Library of functions for 2D graphi ii libatk1.0-01.22.0-1 The ATK accessibility toolkit ii libbluetooth2 3.36-1Library to use the BlueZ Linux Blu ii libbonobo2-0 2.22.0-1 Bonobo CORBA interfaces library ii libbonoboui2-0 2.22.0-1 The Bonobo UI library ii libc6 2.7-12GNU C Library: Shared libraries ii libcairo2 1.6.4-6 The Cairo 2D vector graphics libra ii libcamel1.2-11 2.22.3-1 The Evolution MIME message handlin ii libdbus-1-31.2.1-2 simple interprocess messaging syst ii libdbus-glib-1-2 0.76-1simple interprocess messaging syst ii libebook1.2-9 2.22.3-1 Client library for evolution addre ii libecal1.2-7 2.22.3-1 Client library for evolution calen ii libedataserver1.2-92.22.3-1 Utility library for evolution data ii libedataserverui1.2-8 2.22.3-1 GUI utility library for evolution ii libegroupwise1.2-132.22.3-1 Client library for accessing group ii libexchange-storage1.2 2.22.3-1 Client library for accessing Excha ii libfontconfig1 2.6.0-1 generic font configuration library ii libfreetype6 2.3.7-1 FreeType 2 font engine, shared lib ii libgconf2-42.22.0-1 GNOME configuration database syste ii libglade2-01:2.6.2-1 library to load .glade files at ru ii libglib2.0-0 2.17.3-2 The GLib library of C routines ii libgnome-pilot22.0.15-2.4Support libraries for gnome-pilot ii libgnome2-02.22.0-1 The GNOME 2 library - runtime file ii libgnomecanvas2-0 2.20.1.1-1A powerful object-oriented display ii libgnomeui-0 2.22.1-1 The GNOME 2 libraries (User Interf ii libgnomevfs2-0 1:2.22.0-4GNOME Virtual File System (runtime ii libgtk2.0-02.12.11-3 The GTK+ graphical user interface ii libgtkhtml3.14-19 3.18.3-1 HTML rendering/editing library - r ii libhal10.5.11-2 Hardware Abstraction Layer - share ii libice62:1.0.4-1 X11 Inter-Client Exchange library ii libldap-2.4-2 2.4.10-2 OpenLDAP libraries ii libnm-glib00.6.6-2 network management framework (GLib ii libnotify1 [libnotify1 0.4.4-3 sends desktop notifications to a n ii libnspr4-0d4.7.1-3 NetScape Portable Runtime Library ii libnss3-1d 3.12.0-4 Network Security Service libraries ii liborbit2 1:2.14.13-0.1 libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.20.5-1 Layout and rendering of internatio ii libpisock9 0.12.3-5 library for communicating with a P ii libpisync1 0.12.3-5 synchronization library for PalmOS ii libpixman-1-0 0.11.8-1 pixel-manipulation library for X a ii libpng12-0 1.2.27-1 PNG library - runtime ii libpopt0 1.14-4lib for parsing cmdline parameters ii libsm6 2:1.1.0-1 X11 Session Management library ii libsoup2.4-1 2.4.1-1 an HTTP library implementation in ii libusb-0.1-4 2:0.1.12-12 userspace USB programming library ii libx11-6 2:1.1.4-2 X11 client-side library ii libxcb-render-util00.2+git36-1 utility libraries for X C Binding ii libxcb-render0 1.1-1.1 X C Binding, render extension ii libxcb11.1-1.1 X C Binding ii libxcursor1
Bug#491977: grub-probe fails with Cannot find a GRUB drive for /dev/dm-N.
Am Samstag, den 26.07.2008, 18:00 +0200 schrieb Moritz Naumann:
debby:~# dpkg-query -W -f '${Package} ${Status} ${Version}\n' grub\*
grub-common install ok installed 1.96+20080724-1
Am I missing something? Should I take additional measures before retrying?
Please see the message above in the report, The patch from Robert is in
1.96+20080724-2 not -1 which you have installed.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477304: closed by Felix Zielcke [EMAIL PROTECTED] (Grubfails to find /boot/boot/grub/device.map)
reassign 477304 grub fixed 477304 0.97-37 thanks Hello, From: Nick Hastings [mailto:[EMAIL PROTECTED] Interesting but not related to this bug. Yes, I just tried to reproduce it and as you can see on a fresh install with sid version of grub-legacy there's no problem. This is *not* what the bug is about. The bug is about what happens in the case where grub *is* using /boot/boot/grub/. Please read the bug report again. Well I can't remember ever having a /boot/boot, the time I used grub-legacy. But ok that's long ago and I think I didn't use a seperate /boot at that time. This bug probable belongs more to grub-legacy then grub-common which only contains grub-probe and grub-mkimage I don't think the problem is grub-probe, it's more how it's called from grub-legacy scripts I don't bother to read grub-legacy's bug reports, if this wasn't reassigned to grub-common I would have never saw it :) If you really want to reporoduce the bug the same way I did, you need to start by installing woody... Ah thanks for telling. So the problem only happens if your system started with woody or maybe before that? But everyone who started with sarge doestn't have this problem? Anyway it seems that the bug is indeed reproducable and better news it is fixed in grub 0.97-41. Ok I just checked the changelogs between -36 (you reported against) and -41 In -37 * update-grub/grub-install: Pass --device-map to grub-probe. Thanks [EMAIL PROTECTED] (Closes: #476833) Now I now why I didn't found anything useful in 0.97-41 why this /boot/boot could be a problem for grub-probe :) So clearly this bug belongs to package grub and not grub-common and more important it's already fixed. Hurray why all this trouble if it's fixed :) I hope that reassign and fixed 0.97-37 is really correct now. I leave it up to you and Robert if this bug report still isn't correctly handled by me :) Thanks for replying -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473543: if grub.cfg is to big grub-pc (and maybe others) fails to load it and reboot infinitely
You didn't replied yet unfortunately But anyway: I tested it now with 1.96+20080724-1 currently in unstable in VMware Workstation 6.5 Beta build 99530 with other Linux 2.6 64bit as OS As I already said for me both configs show the menu in grub-emu when I place them in /boot/grub/grub.cfg and just start grub-emu. But now I placed your grub.cfg.break in /boot/grub/grub.cfg and rebooted. Welcome to GRUB is shown. then it takes a little while and then VMware fails with vcpu-0:ASSERT vmcore/vmm/cpu/segment.c:521 bugNr=19580 I tried the same config with just commenting out the insmod tga and background image part and it happend again. Though I didn't check if VMware still showed the same error, probable it did. It's a Beta of VMware but I think it shouldn't make that big difference for the GRUB Code running with a big config. So the problem with your config is not fixed :( -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492204:
notfound 492204 1.96+20080626-1 thanks I don't like to have 2 versions found with this bug. This applies now only for current sid version. Probable Robert and me the only people who read this, but just in case :) VMware SCSI Disks are numbered X:Y X means controller, can be 0-3 I only use one so always 0 Y means disk number, can be 0-15 I only ever use 3 so for me 0-2 If you have a harddisk as 0:0 booted kernel with root=/dev/sda1 then grub-install /dev/sda then change in VMware this disk to 0:1 and in BIOS to boot first from 0:1 grub boots fine If you boot the system as above but then do grub-install /dev/sdb then reboot and then go to BIOS put the 0:1 disk before the just booted 0:0 so the new grub setup on sdb gets loaded prefix is fd1,0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492204:
From: Felix Zielcke [EMAIL PROTECTED] If you have a harddisk as 0:0 booted kernel with root=/dev/sda1 then grub-install /dev/sda then change in VMware this disk to 0:1 and in BIOS to boot first from 0:1 grub boots fine If you boot the system as above Shame on me, I wanted to make it very clear on this report and then didn't :) I only meant harddisk 0:0 booted with root=/dev/sda1 not the 0:1 disk booted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488193: update-grub fails
From: Shams Fantar [EMAIL PROTECTED] /boot/grub/device.map : (hd0) /dev/hda (hd1) /dev/sda /etc/fstab : Now we know why grub thinks hd1 is your / try grub-install with --recheck if that creates device.map right else you have to change device.map manually and then update-grub works right. device.map is only created if it either doestn't exist or if you run grub-install with --recheck -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#467501: grub uses fd prefix even if it's neither in device.map nor grub.cfg
forwarded 467501 http://lists.gnu.org/archive/html/grub-devel/2008-07/msg00435.html retitle 467501 grub uses fd prefix even if it's neither in device.map nor grub.cfg thanks Seems like the original problem reported is still not fixed. [0] I just had a fd prefix myself, even though I don't use anything special like software raid or LVM. [0] http://lists.gnu.org/archive/html/grub-devel/2008-07/msg00435.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492204: grub: if installed to sdb and then booted from it just by changing boot order in BIOS prefix becomes fd
Package: grub-pc Version: 1.96+20080626-1 Severity: important grub-install /dev/sdb swap hard disks boot order in BIOS so sdb gets booted prefix for grub is fd instead of hd grub.cfg has it right with hd0 set shows root=fd0,1 prefix=(fd0,1)/boot/grub ls shows (hd0) (hd0,1) (hd1) (hd1,0) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460571: grub: automated migration of menu.lst static entries
This is from 20. January: Peter Hicks wrote : Robert Millan wrote: This makes a good candidate to start a README.Debian. Will you provide a patch? Sure, it shouldn't be too difficult. I'll crack on with it shortly. Did you have in the meantime something for README.Debian of grub2 ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477304: Grub fails to find /boot/boot/grub/device.map
From: Nick Hastings [EMAIL PROTECTED] Well, I was very suspicious that it had left my system in an unbootable state, with nothing in /usr/share/doc/grub-common to indicate how to make it bootable ... no README.Debian etc Yeah the documentation for grub2 isn't that good as for grub-legacy but it still works the same grub-install copys everything it needs to /boot/grub/ and update-grub generates grub.cfg Ok done and it works: thanks for the new boot loader. Well don't thank me for grub2. I just started to help :) Good that it's now fixed for you. But the real problem is still not fixed. I think it's more grub-legacy then grub-probe what needs a fix for this /boot/boot problem. grub2 doestn't have this problem as you now know, too. It seems that if the above steps aren't taken the user will be left with an unbootable system. Should I file a bug report for this? As I said above it stil works the same as on grub-legacy grub2 is still not the default. Debian installer only asks in expert mode to install it, and then it takes care of it. But yes as already said above, more documentation about this wouldn't be that bad As you can see on the bug reports for grub2 there are already a few for missing documentation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475296: update-grub not run
In either case, whenever you want GRUB 2 to be loaded directly from MBR, you can do so by issuing (as root) the following command: . upgrade-from-grub-legacy That sounds like you should be able to just run it and reboot, wether you choose to chainload or not. I have now commited a fix for it, that it calls update-grub if it doestn't exist before. It's a bit unclear yes, as I first looked at it I wondered a bit about that, too. But if you think about it then it does sound like it doestn't install to mbr if you choose to not chainload. If anyone has an idea how to make it better, please tell us. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492056: [INTL:sv] po-debconf file for grub2
tags 492056 + pending thanks From: Martin Agren [EMAIL PROTECTED] Please find attached the Swedish debconf templates translation. Thanks very much. I just commited it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491977: grub-probe fails with Cannot find a GRUB drive for /dev/dm-N.
From: Moritz Naumann [EMAIL PROTECTED] About the md issue: The patch does not seem to fix it (assuming, after 'make install', invoking the the freshly built ./update-grub is the right way to invoke it, and I'm also calling grub-probe the right way): ./configure; make install installs everything to /usr/local not /usr and /usr is before /usr/local in PATH update-grub is just a bash script which invokes some commands In your case it still took the old grub-probe in /usr/sbin/ The best would be to use directly ./grub-probe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491977: grub-probe fails with Cannot find a GRUB drive for /dev/dm-N.
From: Moritz Naumann [EMAIL PROTECTED] debby:~/grub2-1.96+20080704# ./grub-probe -v -d /dev/dm-5 Urm sorry didn't see that you invoked it with ./ and update-grub just generates grub.cfg. grub-install uses grub-probe. grub-probe: error: Cannot find a GRUB drive for /dev/dm-5. Check your device.map Delele /boot/grub/device.map and call grub-install so that it gets regenerated. But make sure it's using the new grub-probe and not the old one from /usr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477304: Grub fails to find /boot/boot/grub/device.map
From: Teodor [EMAIL PROTECTED] At the configuration question I've answered no for the chainloading from grub-legacy. I've rebooted the machine to see if it works and the surprise was that the boot menu was the same, that is from grub-legacy instead of grub2 (with xen options too). The only explanation is that I should have run grub-install (hd0) to *really* switch to grub2, but why the menu.lst from grub-legacy was not removed on purge? Please see #475296 This bug is about /boot/boot problem, which doestn't happen with grub2 Only with grub-legacy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475718: Bug #475718 grub gets confused by hybrid apple/pc partmap
From: Chris Knadle [EMAIL PROTECTED] [sorry for the additional copy; forgot to CC the BTS] No problem. On Monday 21 July 2008 06:44:45 pm, Felix Zielcke wrote: Is this still a problem with grub2 1.96+20080704-2 currently in testing/unstable ? Yes, unfortunately it is. I just tested 0.97-41 and it still has the problem. The last version that doesn't have the problem is grub-0.97-32 -- I've been having to force downgrade back to that version and then keep the package on hold. Well, the old grub-legacy won't have much bugfixes anymore. I just tried, grub2 1.96+20080704-2 -- I can't even complete installing it Thanks for trying it with the new grub2 I'll bring it up on the grub-devel mailing list again to see if I can get some help figuring out how to get this fixed. Thanks, I wasn't subscribed to grub-devel at that time so I didn't knew that Also, either grub2 and/or grub2-pc did not purge cleanly; it left a big mess of files in /boot/grub/ after both were purged, which I had to manually pick through and delete those Please see #470400 [0] If you replace grub-legacy with grub2 completely, i.e. not choosing the chainload option then it should have cleaned up the old grub files If that didn't work for you then please make a new report. If you just purge the old grub package and then install grub-pc they won't get cleaned up [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=470400 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469578: 10_linux creates xen boot entries that don't work
Will list any vmlinu* entry, including xen kernels... ideally it should
exclude xen, as they will have to be handled differently.
I've never used Xen, but i thought the -xen kernel should be run on domU and
dom0.
So how should they be handled, can you please be more specific ?
Below is a patch which ignores *xen* kernels.
--- /etc/grub.d/10_linux2008-07-22 14:05:41.784310665 +0200
+++ /etc/grub.d/10_linux2008-07-22 14:07:30.299012258 +0200
@@ -150,7 +150,7 @@
}
list=`for i in /boot/vmlinu[xz]-* /vmlinu[xz]-* ; do
-if grub_file_is_not_garbage $i ; then echo -n $i ; fi
+if grub_file_is_not_garbage $i ! is_xen_kernel ; then echo -n $i
; fi
done`
if [ x$list != x ] ; then
--- /usr/lib/grub/update-grub_lib 2008-07-22 14:05:20.983966822 +0200
+++ /usr/lib/grub/update-grub_lib 2008-07-22 14:08:46.695117181 +0200
@@ -156,3 +156,10 @@
fi
return 0
}
+is_xen_kernel()
+{
+ case $1 in
+*xen*) return 0 ;;
+ esac
+ return 1;
+}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491872: grub-pc: dual boot needs OS-prober
block 491872 by 476184 severity 491872 wishlist thanks Ok I talked with Robert. It was already recommended and then was changed to suggest because of #476184 See also bug #476684 Thanks for reporting :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478228: Debian bug #478228 grub-probe can't handle (raid) md-devices
From: Thomas Rösch [EMAIL PROTECTED] Hello, I am sorry, i have removed this version and use the old grub again since some month. grub-probe is in grub-common and the old grub depends on it since version 0.97-33 So can you please make sure you have grub-common 1.96+20080704-2 installed and then please try grub-probe again, as you did on your report? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478228: grub-probe can't handle (raid) md-devices
Urm sorry, i think my last mail wasn't that clear :) I forgot that you did reported this against grub-legacy. You can install grub-common without problems with an old grub-legacy even if it's 0.97-33 It only contains grub-probe and grub-mkdevicemap [0] and it doestn't conflict with any package. If it still fails then please show grub-probe -vv output. Thanks. [0] http://packages.debian.org/sid/amd64/grub-common/filelist -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477304: Grub fails to find /boot/boot/grub/device.map
Hello, From: Nick Hastings [EMAIL PROTECTED] Seems to be no errors but it seems that /boot/boot/ is being completely ignored. Please see the results of the install, linux-image reconfigure and file listing under /boot below. I used grub-legacy long ago, and I think I never used it with a /boot partition. But I did use grub2 with a seperate /boot partition. It works fine with just /grub instead of /boot/grub I think I will downgrade to the old grub Please don't, please try grub2 :) If you call grub-install then the *.img and *.mod files get copied to /boot/grub/ which it needs. You can delete /boot/boot and reboot. It will work fine. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470398: grub-pc: please implement full altoptions mechanism from grub-legacy
Hello, I have tried but the list keeps rejecting my mails. You need to subscribe to send mails to [EMAIL PROTECTED] Please do this and start a discussion about this there. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469578: 10_linux creates xen boot entries that don't work
From: Teodor [EMAIL PROTECTED] Sent: Tuesday, July 22, 2008 11:00 PM To: Felix Zielcke [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Gavin Bravery [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Bug#469578: 10_linux creates xen boot entries that don't work The same problem I reported for grub legacy at [1]. You can read there an explanation. After I sent my reply to the bug report, I talked with Robert about it. He pointed me to ask Ian Campbell about that Xen stuff. But thanks for the old bug number. However, this is still going to be a problem in lenny because dom0 support is missing completely and domU support is only on i386. Why is it still a problem for grub in lenny when lenny doestn't support dom0 ? If you're able to compile yourself a Xen kernel, you should be able to modify your menu.lst or grub.cfg I think a 'wontfix' tag would have been more appropriate for grub legacy. At least in grub2 I hope it will be fixed. grub2 currently doestn't support xen kernels I know now that the grub lines for xen dom0 kernels should look different which grub-legacy did. For lenny there will for sure no Xen support in grub2, it's not the default and debian-installer only asks in expert mode to install it. Patches for it are appreciated It's not good btw. to check just for *xen* in the filename. It doestn't need to be true, e.g. when you compile your own Xen kernel. So the best would be to check for this PARAVIRT or XEN stuff in config-kernel if that kernel is a Xen one or not. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486624: update-grub causes error for /dev/.tmp.md0 on SoftwareRAID1
Can you please check with current version in testing/unstable if that's still an issue and please check the patch from Robert [0] [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=8;filename=md.diff;att=1;bug=486624 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488571: Bug #488571 [Intl:pt] updated portuguese translation
You have reported it twice that you have updated translations, both with postgresql-common_88_pt.po attached One went to progesql-common where it belonged to and is already fixed #488570 and one (this one #488571) assigned to grub2 So please reply if you have a portuguese translation for grub2 or if this was a mistake -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#467501: Bug #467501 cannot boot when /boot is in RAID
Running grub-install will wipe the grub1 install and leave me with
grub2, right? Is that more likely to work than the existing chainloading
grub2 from grub1 approach?
Yes, grub-install will replace grub-legacy with grub2.
I don't know if that works better then chainloading.
If you have a rescue CD or such so you can recover grub-legacy to get a
bootable system again, then you can try it out.
I can try an aptitude purge; rm /boot/grub/*.{mod,img}; aptitude
install grub-pc tonight and let you know if that's any better.
I just checked postinst calls grub-install /bin/true if chainloading is used
But only if there wasn't already a /boot/grub/core.img
So to be on the safe side, please do that.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475718: Bug #475718 grub gets confused by hybrid apple/pc partmap
Is this still a problem with grub2 1.96+20080704-2 currently in testing/unstable ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487565: grub-pc: Grub2 fails to boot after upgrade from Grub Legacy
Package: grub-pc Version: 1.96+20080621-1 ii grub-common 1.96+20080512-1 GRand Unified Bootloader, version Please try update both packages to 1.96+20080704-2 currently in testing and unstable and try it again. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469585: Debian BTS #469585 grub-pc: consistently resets immediately after using boot command
Is this still an issue with the current 1.96+20080704-2 in unstable? If you still didn't provide a raw backtrace as Robert Millan told you on 10. March in the Bugreport then please do so http://grub.enbug.org/HowToDebug -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465365: Debian bug #465365 grub-ieee1275: grub-mkdevicemap writes a device.map with No aliases found
Is this still an issue with the current 1.96+20080704-2 in testing/unstable? Have you tried out Robert Millan's patch? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436943: Debian bug #436943 error: out of partition when trying to enter normal mode
Does this still aplly with 1.96+20080704-2 currently in testing/unstable or even with current SVN? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477304: Debian bug #477304 Grub fails to find /boot/boot/grub/device.map
Is this still an issue? Can you please try it with grub-pc 1.96+20080704-2 currently in testing/unstable -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462835: Debian bug #462835 grub-pc: alloc magic is broken
Does this problem still exist with grub-pc 1.96+20080704-2 currently in testing/unstable ? If so can you reproduce this in grub-emu ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
