Are people actually reading this whole thread, or just coming here to
complain? It's broke! Help me! Seriously, people. The underlying
problem behind these issues is with GRUB2. We've already discussed this
at length. A workaround solution has been described in detail at least
TWICE. If you
This thread has become completely absurd, and I'll no longer be checking it.
People who know how to read have already recovered their installs, so my work
here is done.
Good day.
--
Wubi/Karmic boot: kernel panic - not synching: VFS
https://bugs.launchpad.net/bugs/477169
You received this bug
You need to be following bug #477169 for the most up to date info on
this problem, as well as a workaround solution.
--
After 9.10 grub update can not boot into Wubi install
https://bugs.launchpad.net/bugs/477104
You received this bug notification because you are a member of Ubuntu
Bugs, which
Agostino: I know for a fact that when I originally discovered the
problem, booting into Windows and then trying to boot back into the
Wubi install made no difference. Files that read as corrupted in grub2
were still read as corrupted. As per your theory, it is true that if
you look through the
Agostino: really? That's very interesting. The fact that I now have
two installs on the exact same machine, one had the problem after
updates and was repaired with a separate /boot filesystem, and the
other a fresh install with all updates and no problems at all, makes me
wonder... Could it
Agostino: although older versions of Wubi installs made use of
rootflags=syncio as mount options for mounting the root filesystem,
the current version doesn't. Bug #204133, comment #59 would tend to
support this, at least in theory.
HOWEVER, my root filesystem is in fact the default ext4, which
In response to my own previous message, it was actually the
/etc/grub.d/10_lupin script called by update-grub which I needed to
patch so that running update-grub properly creates grub.cfg with
boot.disk for the grub loopback device, and root.disk for the kernel's
loopback root device.
This and my
I finally had a chance to test the -15 kernel update. There was
absolutely no problem whatsoever with this kernel, as I expected. The
only underlying problem is the aforementioned grub2 problem, which I'm
now considering worked around with a separate /boot filesystem as a
solution, plus my two
I see two problems evident from some of your grub.cfg files, if in fact
you're attempting to make use of a separate /boot filesystem as I
recommended:
1) The loopback line should be referencing boot.disk, *not*
root.disk. I'm pretty sure that grub is doing this in /usr/lib/grub
Not to be rude, but the only reason I'm checking this ticket is to help
people work around a critical grub2 bug that occurred as a result of a
recent major update. I was affected by the problem, immediately came up
with a workaround solution, and that's what I'm trying to help people
with. We
Response to 82: if you properly created the separate boot.disk
filesystem containing grub, your kernel(s) and initrd(s), it must BE
MOUNTED before you run grub-install hd0 (assuming we're talking about
your primary hard drive). You didn't mention any error messages after
running grub-install, so
Is this with the newer -15 kernel update? Can you confirm the same
problem occurs with -14? Using my method I've successfully restored
normal booting ability for -14 and any kernels I've built from the
sources associated with that kernel version.
I have not yet tested -15, so I'd like to rule
Alex, can you please upload your current grub.cfg file? If you can in
fact boot your -14 kernel by editing the grub boot command line, there's
no reason why it shouldn't also work from the menu, unless your grub
menu entry for the -14 kernel is somehow wrong or isn't properly being
updated.
--
Everyone go back and read #69 and #70, which is a workaround solution to
all this mess.
Now go read it again.
--
Wubi/Karmic boot: kernel panic - not synching: VFS
https://bugs.launchpad.net/bugs/477169
You received this bug notification because you are a member of Ubuntu
Bugs, which is
As was already commented on, go to bug report 477169, and read #69 and #70.
Complete workaround solution to the problem.
If it doesn't work, go read it again.
--
After 9.10 grub update can not boot into Wubi install
https://bugs.launchpad.net/bugs/477104
You received this bug notification
You saved me the trouble of typing all this up. :)
I would add that it isn't necessary for you to define a loop0 *and* a loop1 in
grub, as grub only needs to know about your new boot.disk in order to boot.
The loop= kernel parameter referencing root.disk is unrelated, and has
nothing to do
It isn't the kernel update that broke anything, it's grub2 losing the
ability to see the new kernel file. In all my tests (I've been able to
reproduce every single error everyone has gotten), grub2 was always the
root cause.
As a test, I created a complete duplicate of my Wubi install as ext3
Fresh Ubuntu 9.10 wubi install here. And here's the deal:
After updating and regenerating /boot/grub/grub.cfg (which is the same as
original), a fresh boot drops me to the grub prompt. Grub2 is unable to read
any text files at all now, which is the obvious reason for being dumped to the
grub
A few more observations:
I mentioned that running grub-install modifies c:\wubildr and deposits a tons
of files into /boot/grub on the linux side.
The files are being copied from /usr/lib/grub/i386-pc. I have no idea why
they're being copied, as a stock install does not locate these files in
*** This bug is a duplicate of bug 477104 ***
https://bugs.launchpad.net/bugs/477104
** This bug has been marked a duplicate of bug 477104
After 9.10 grub update can not boot into Wubi install
--
Wubi/Karmic boot: kernel panic - not synching: VFS
https://bugs.launchpad.net/bugs/477169
Adding bug #477169 as a duplicate, because it is. That's exactly what
happened to my first install if initrd is updated. If the kernel is
updated, it's invalid magic number. In fact it looks like any file
which is updated from the original stock install reads as garbage from
within grub2. For
21 matches
Mail list logo
