Btw, i386 builds are now available (same URL). Please test!
On Wed, Sep 02, 2009 at 08:01:48PM +0200, Robert Millan wrote:
Hi,
I uploaded this GRUB snapshot, it's from right after a video framework
restructure commit that I suspect might be the culprit:
http://people.debian.org/~rmh
Btw, i386 builds are now available (same URL). Please test!
On Thu, Sep 03, 2009 at 06:40:28PM +0200, Robert Millan wrote:
Hi,
I uploaded this GRUB snapshot, it's from right after a video framework
restructure commit that I suspect might be the culprit:
http://people.debian.org/~rmh
On Wed, Sep 02, 2009 at 11:05:09PM +0200, Witold Baryluk wrote:
Dnia 2009-09-02, śro o godzinie 20:01 +0200, Robert Millan pisze:
Hi,
I uploaded this GRUB snapshot, it's from right after a video framework
restructure commit that I suspect might be the culprit:
http
that it works in console/text mode aren't helpful at all!
Thanks!
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all
Hi,
I uploaded this GRUB snapshot, it's from right after a video framework
restructure commit that I suspect might be the culprit:
http://people.debian.org/~rmh/grub-after-fb-split/
Please report if it works. Thanks!
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We
On Wed, Aug 26, 2009 at 12:15:59PM +0200, Michal Suchanek wrote:
2009/8/26 Felix Zielcke fziel...@z-51.de:
Am Mittwoch, den 26.08.2009, 09:57 +0200 schrieb Michal Suchanek:
2009/8/26 Robert Millan r...@aybabtu.com:
On Thu, Aug 06, 2009 at 11:04:10PM +0200, Michal Suchanek wrote:
Package
On Fri, Aug 28, 2009 at 03:05:04PM +0200, Michal Suchanek wrote:
2009/8/26 Michal Suchanek hramr...@centrum.cz:
2009/8/26 Robert Millan r...@aybabtu.com:
On Thu, Aug 06, 2009 at 10:24:57AM +1000, Jayen wrote:
Package: grub-pc
Version: 1.96+20090725-1
Severity: critical
Justification
On Wed, Aug 26, 2009 at 09:55:42AM +0200, Modesto Alexandre wrote:
Le mercredi 26 août 2009, Robert Millan a écrit :
Package: grub-pc
Version: 1.96+20090725-1
Severity: normal
Are you completely sure you're using this version?
Yes, i have GPT partitions (6 Tb)
Did you run
On Thu, Aug 06, 2009 at 11:04:10PM +0200, Michal Suchanek wrote:
Package: grub-pc
Version: 1.96+20080724-16
Severity: normal
Btw please try a newer version. Make sure you run grub-install after
updating the package.
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We
Package: grub-pc
Version: 1.96+20090725-1
Severity: normal
Are you completely sure you're using this version?
Did you run grub-install after updating the package?
Don't trust that the debconf template did it for you. Please run it by hand.
--
Robert Millan
The DRM opt-in fallacy: Your
similar to #513592 and
#497791 (and probably others).
What happens if you comment out the search commands? (all of them)
And if you add insmod linux at the beginning of grub.cfg?
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your
, this means when you run grub-install you
should see some warnings explaining why (and how you can avoid this).
Please fix that, and try with a setup that uses embedding instead of
blocklists, then report to us if the problem was fixed.
Thanks
--
Robert Millan
The DRM opt-in fallacy: Your data belongs
is present then you have to install
it manually and upgrades will break it.
What happens if you comment out the search commands? (all of them)
And if you add insmod linux at the beginning of grub.cfg?
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when
it to the
maintainer to close it at his discretion.
Thanks
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all
#476184.
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ
Package: nsis
Version: 2.44-4
Severity: grave
Something nasty happened after the switch to new plugin API. Starting with
win32-loader 0.6.11 (which is the first version to use the new API), the
get_arch() function provided by its plugin works with Wine, but returns garbage
when run on native
I forgot to attach it.
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all.
testcase.tar.gz
Description: Binary
Please try this one.
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all.
Index: kern/i386/pc/startup.S
On Fri, Jul 24, 2009 at 01:45:56PM +0200, Felix Zielcke wrote:
Am Freitag, den 26.06.2009, 18:19 +0200 schrieb Robert Millan:
On Wed, May 27, 2009 at 02:29:47PM +0200, Holger Levsen wrote:
Hi Felix,
On Mittwoch, 27. Mai 2009, Felix Zielcke wrote:
We could remove the `ascii.pf2
, but
rest assured that a fixed snapshot will be uploaded soon.
Thank you very much.
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data
vbeinfo GRUB command
(with unpatched GRUB) print for this mode (0x105, as you need to substract
0x200)? What does linux16 /linux.img vga=ask say about this mode?
Do other modes work?
Thanks!
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you
is also needed.
- Attached patch to (hopefully) fix color properly instead of the hack.
Many thanks!
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove
://bugs.debian.org/cgi-bin/bugreport.cgi?msg=46;filename=lfb_size.diff;att=1;bug=535026
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data
it. Please see:
http://people.debian.org/~rmh/grub/vga_bug/README
for instructions on how you can help.
Thanks in advance
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still
demands I take a 10 minute break
Well there MUST be something else you can do?
Which is non-free as well, but at least it's funny. Can we keep it as a
non-mandatory suggestion?
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your
and (if available) vesafb
output.
Btw, you can also contact me on IRC (nyu @ irc.freenode.net / #grub).
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your
On Tue, Jun 30, 2009 at 03:49:41PM +0200, Robert Millan wrote:
On Tue, Jun 30, 2009 at 03:11:29PM +0800, Jos van Wolput wrote:
I just installed v. 1.96+20090629-1. Unfortunately it doesn't work. The
bug is still the same as I
previously mentioned. I have to revert to v. 1.96+20090611-1
On Tue, Jun 30, 2009 at 03:11:29PM +0800, Jos van Wolput wrote:
I just installed v. 1.96+20090629-1. Unfortunately it doesn't work. The
bug is still the same as I
previously mentioned. I have to revert to v. 1.96+20090611-1.
Did you run grub-install after the update?
--
Robert Millan
pages = 0x0
vesa_attributes = 0x0
capabilities = 0x0
This looks like text mode. I assume you didn't pass vga=773 to linux16?
I need you to include that parameter in your test.
Thanks!
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may
Hi,
Please could you test if this patch helps?
Thanks
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all.
Index
image instead:
http://people.debian.org/~rmh/bzImage
which is gpg-signed:
http://people.debian.org/~rmh/bzImage.sig
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still
then.
Note2: If you can't wait, the patch you want is:
svn diff -r 2372:2375 svn://svn.savannah.gnu.org/grub/trunk/grub2
Thanks!
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
.
- Verify its current state. If the note has now been corrupted,
send me a copy of the old note (prior to corruption).
Btw, which version of gnote are you using?
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data
forget to attach it?
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all.
--
To UNSUBSCRIBE, email to debian-bugs-rc
On Tue, Jun 30, 2009 at 02:19:07AM +0200, Bernat Arlandis i Mañó wrote:
Robert Millan escrigué:
On Tue, Jun 30, 2009 at 01:48:21AM +0200, Bernat Arlandis i Mañó wrote:
I had a note that hadn't been modified since june 8th, I've opened it
with 0.5.1 and it got corrupted immediately. I'm
Good news, 0.4.0-3~squeeze1 is not affected.
I could reproduce the problem with 0.5.1-1. Will run a regression test
and report this upstream.
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening
of the offending note? (prior to corruption, of course)
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all.
--
To UNSUBSCRIBE
. As long as GRUB is in MBR, user will
expect it to work. We can't wipe out files that are critical to its boot
process because it's not something that every user will expect. So the
only option is to be on the safe side.
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We
://packages.debian.org/lenny-backports/gnote
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all
backports.org URI in sources.list ?
Also, what happens if you try
apt-get install gnote libxml++2.6-2
?
and if you try
apt-get install -f
?
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's
Note that this won't longer be a problem on mipsel soon
(see #523939). It still applies to other arches though.
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow
Package: uswsusp
Version: 0.8-1.1+b1
Severity: grave
/var/swap is there but uswsusp runs from inside a chroot. It shouldn't
assume swap is going to be directly accessible when it is a file (for a
dev I guess it's fine since /dev has to be bind-mounted anyway).
S'està configurant uswsusp
Package: libwvstreams4.4-base, wvdial
Severity: grave
This library appears to be unusable on mipsel, as it depends on
getcontext API which isn't yet implemented there:
wvdial: utils/wvtask.cc:198: WvTaskMan::WvTaskMan(): Assertion
`getcontext(get_stack_return) == 0' failed
Aborted.
This
. Thanks.
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ
On Thu, Mar 19, 2009 at 12:25:05PM +0900, Paul Wise wrote:
Do you want me to provide a test case?
That would be helpful.
Attached.
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your
found 519703 2.44-3
thanks
Sorry, the problem's still there. Do you want me to provide a test case?
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you
On Sun, Mar 15, 2009 at 05:18:52PM +0900, Paul Wise wrote:
On Sat, 2009-03-14 at 15:16 +0100, Robert Millan wrote:
When attempting to build a plugin:
i586-mingw32msvc-gcc -Os -Wl,--file-alignment,512 -Werror
-L/usr/i586-mingw32msvc/lib/nsis -lpluginapi sm_cleanboot.c -shared -o
problem still remains, though)
Also, -Werror is considered harmful with stuff being compiled by distros.
Well, in this case it's my own code, and prefer the extra burden over having
the occasional runtime error that turns out to be much harder to debug.
--
Robert Millan
The DRM opt
On Sun, Mar 15, 2009 at 08:05:25PM +0900, Paul Wise wrote:
I'm uploading an nsis with dh_strip -Xlibpluginapi.a, I'm not sure if I
should file a bug on debhelper for the dh_strip side (yak shaving FTW).
I wouldn't. Running strip is usually the right thing.
Thanks
--
Robert Millan
Package: nsis
Version: 2.44-2
Severity: serious
When attempting to build a plugin:
i586-mingw32msvc-gcc -Os -Wl,--file-alignment,512 -Werror
-L/usr/i586-mingw32msvc/lib/nsis -lpluginapi sm_cleanboot.c -shared -o
sm_cleanboot.dll
/usr/i586-mingw32msvc/lib/nsis/libpluginapi.a: could not read
separately?
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ
Package: libsigc++-1.2-dev
Severity: serious
Priority of libsigc++-1.2-dev package is important, but the FTP archive
overrides this to optional.
The result of this is that unless dak has made its magic, debootstrap will
try to install libsigc++-1.2-dev, and fail because libstdc++-dev is not
Package: klogd
Version: 1.5-5
Severity: serious
Priority of klogd source package is important, but the FTP archive overrides
this to extra. In turn, rsyslog is marked as important.
The result of this is that unless dak has made its magic, debootstrap will
try to install both, and fail due to
On Tue, Jan 27, 2009 at 10:33:08PM -0700, dann frazier wrote:
On Mon, Jan 26, 2009 at 12:44:09AM +0100, Robert Millan wrote:
Hi,
Please could you try the attached patch and see if it fixes the
problem?
patch /etc/grub.d/10_linux.in 10_linux.diff
update-grub
hey Robert
? (or
otherwise provide md5sums of /boot/grub/normal.mod so we could try and find
it)
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ
On Tue, Jan 27, 2009 at 02:59:18AM +0200, Guillem Jover wrote:
Hi!
On Sun, 2009-01-25 at 23:49:14 +0100, Robert Millan wrote:
On Sun, Jan 25, 2009 at 03:31:37PM +0200, Guillem Jover wrote:
When gnumach is installed grub-pc fails to install due to at least the
missing function
Package: software-properties-gtk
Version: 0.60.debian-1.1
Severity: grave
On a newly installed Lenny system [1]:
debian:~# software-properties-gtk
/usr/lib/python2.5/site-packages/apt/__init__.py:18: FutureWarning: apt API
not stable yet
warnings.warn(apt API not stable yet,
). Also, try unsetting the root variable,
run the search command, and see if it finds the correct value for it.
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you
installing those files on systems where
they're not useful. The generated boot entry is going to be system-specific
anyway, so there's no use in providing them.
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data
know). Anyway, if you aren't sure, feel free to file
a new one. But please don't followup on #497791.
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you
tell us which of the search commands is failing.
Actually, it'd be good to know if the problem appears at all in grub-emu or
not, too.
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom
, after all.
Sounds plausible. If you can reproduce it in grub-emu, it'll be much simpler.
Then you will probably get a SIGSEV instead of a reboot.
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's
Package: pike7.6
Version: 7.6.112-3
Severity: serious
Tags: patch
Fails to build twice in a row, because the *.bak file generated by
12_perl_init.dpatch is removed by dh_clean, which makes unappliing
impossible.
Patch attached.
(Note: I recommend using tar-in-tar to avoid this kind of problems)
tags 459705 pending
tags 512539 pending
thanks
Hi,
I've uploaded the following NMU to DELAYED/5-day. If you'd rather do the
upload yourself, and need more time, please let me know so I can cancel it.
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when
for considering,
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ
=' -lrt -lpthread -ldl
/usr/lib/libsamplerate.la -lm'
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all
.
Usage:
./prune_pike pike7.6_7.6.112.orig.tar.gz pike7.6_7.6.112.dfsg.orig.tar.gz
Will you try to get this fixed in Lenny?
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
On Thu, Jan 15, 2009 at 07:45:07PM +, Ian Jackson wrote:
Robert Millan writes (Re: [Pkg-xen-devel] Bug#391935: Bug #391935: Re: The
answer from Citrix Xen.org):
This leads me to believe that, if we had kept using the non-free logo, our
set of Debian-specific changes to the package
On Tue, Jan 13, 2009 at 08:24:54PM +, Ian Jackson wrote:
Robert Millan writes ([Pkg-xen-devel] Bug#391935: Bug #391935: Re: The
answer from Citrix Xen.org):
On Sun, Jan 11, 2009 at 02:15:29PM +0100, Bas Zoetekouw wrote:
Actually, I think there were two problems with firefox
tags 239111 patch
thanks
Hi,
Please could you try the attached patch, and confirm that it works? Thanks
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you
to be allowed.
According to DFSG #4, we do not require total freedom for the _name_ of
the program for anyone to whom we distribute the code.
Great. So this bug can be closed?
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your
not going to get fixed in time for lenny. Hence
adding lenny-ignore tags
Hi Neil,
As Rob pointed out there's a serious regression, and I plan to fix it really
soon. So please remove the lenny-ignore tag.
Thanks
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We
On Mon, Jan 12, 2009 at 06:15:52PM +, Robert McQueen wrote:
severity 239111 grave
thanks
Robert Millan wrote:
The whole approach is wrong, so maybe it makes sense to avoid it, or maybe
it's too late for that, and we should issue a critical debconf warning when
XFS is detected.
I
Rob,
Did you hit this problem when installing GRUB to a partition, or to the
whole disk?
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your
On Mon, Jan 12, 2009 at 07:32:49PM +0100, Robert Millan wrote:
I (and upstream in general) believe that the only right way to rely on a
hardcoded list of blocks that live inside a filesystem is _not to_.
Grmf. I was making wrong assumptions. This is not about block lists
(I still think
doing something wrong.
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all.
--
To UNSUBSCRIBE, email to debian-bugs
On Mon, Jan 12, 2009 at 08:28:19PM +0100, Robert Millan wrote:
It's not the log file. Joeyh tried that (see the bug log).
I'm almost certain it's the fwrite() call in install_func. I could be
wrong, but I still don't see why we would want to use xfs_freeze anyway.
And if we _really_
with that approach.
I will try to find some time to test
it as well as Ben's simple freeze; unfreeze patch which I prefer,
You mean the one in #242 ? This looks good to me.
Btw, Ben, could you test your patch on GRUB 2 too? It probably has exactly
the same problem.
--
Robert Millan
of verifiing that GRUB can read the file.
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all.
--
To UNSUBSCRIBE
On Mon, Jan 12, 2009 at 10:08:49PM +, Neil McGovern wrote:
On Mon, Jan 12, 2009 at 07:39:01PM +0100, Robert Millan wrote:
Hi Neil,
As Rob pointed out there's a serious regression, and I plan to fix it really
soon. So please remove the lenny-ignore tag.
I'll believe it when
to comply with the trademark by reading debian/copyright (or would that be
debian/trademark? :-)), why would it be a problem for us (or for them)?
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening
it to be Release Critical. D-I avoids using GRUB Legacy when user
selected XFS, and rightly so. As I said, with GRUB 2 it's going to be
different (if someone wants to know more about the technical details on how
we changed our approach, feel free to contact me).
--
Robert Millan
The DRM opt
Package: mawk
Version: 1.3.3-13
Severity: serious
[...]
cc -g -Wall -O2 -c -o parse.o parse.c
In file included from mawk.h:53,
from parse.y:81:
nstd.h:77: error: expected identifier or ��(�� before ��__extension__��
nstd.h:78: error: expected identifier or ��(�� before
Package: lzma
Version: 4.43-14
Severity: serious
dpkg now depends on lzma, and therefore its priority can't be lower than
required (see policy 2.5, Packages must not depend on packages with
lower priority values)
-- System Information:
Debian Release: 5.0
APT prefers unstable
APT policy:
:
set root=(hd0,1)
search --fs-uuid --set 055ce214-7182-4b61-84e8-c831372d5e64
menuentry Debian GNU/Linux, linux 2.6.27-1-amd64 {
(...)
Note that this was a bug. It was fixed in:
2008-08-01 Robert Millan [EMAIL PROTECTED]
* util/grub.d/10_linux.in
.
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject
, it works and with it being inside the entry
for invaders, it fails.
Sounds like a GRUB bug to me. What version of grub-pc are you using? (make
sure you have run grub-install on that version)
Also, check: grep multiboot /boot/grub/command.lst
--
Robert Millan
The DRM opt-in fallacy: Your
in experimental,
it doesn't? (disregard update-grub calls in this test, but make sure you're
using /etc/grub.d/*_multiboot unmodified).
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
use it.
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED
to
deal with future kernel that do not exist yet and to be done with that
bug.
Please find the patch attached. It works here at least.
Looks reasonable. I checked that in.
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access
.
Robert, can you apply the patch and upload a fixed package to get rid of
2 RC bugs?
Hi,
I'll prepare an upload this weekend.
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
with it. Felix,
what do you think?
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all.
--
To UNSUBSCRIBE, email
?
I already did (see branches/lenny), but I notice the version should be
0.97-47lenny1, thanks for spotting that.
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow
.
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject
fine.
But in the mean time for Grub 1, wouldn't the best solution simply be
to regenerate the device.map in case of errors and try again ?
We tried this, and the solution was worse than the problem. In the end it
had to be reverted.
--
Robert Millan
The DRM opt-in fallacy: Your data
but it displays one line more saying that
device.map got regenerated.
I don't think that find_device() needs any change.
If you want me to upload this as NMU, please say so, otherwise I'll let
you handle it.
Hi,
This is not ok, see my last reply.
--
Robert Millan
The DRM opt-in fallacy
On Tue, Oct 28, 2008 at 09:13:30PM +0100, Raphael Hertzog wrote:
On Tue, 28 Oct 2008, Robert Millan wrote:
On Tue, Oct 28, 2008 at 10:27:29AM +0100, Raphael Hertzog wrote:
I have two concerns with this:
- grub-probe can possibly fail in other circumstances and we will display
/dev/null
+ GRUB_LEGACY_0_BASED_PARTITIONS=1 grub-probe --device-map=${device_map}
-t drive -d $1 2 /dev/null || \
+(echo Cannot find a GRUB drive for $1. Check your device.map.
exit 1)
}
# Usage: convert_default os_device
--
Robert Millan
The DRM opt-in fallacy
. I'll
wipe out that warning for your convenience.
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all
401 - 500 of 810 matches
Mail list logo
