*** This bug is a duplicate of bug 445852 ***
https://bugs.launchpad.net/bugs/445852
Note the workaround in Bug 445852 involving editing udev is NOT workable
for a new Ubuntu installation, because even if you update the udev rule
before the installer reboots, the udev change gets reverted with
*** This bug is a duplicate of bug 445852 ***
https://bugs.launchpad.net/bugs/445852
@Felix: my deepest apologies for writing it wrongly. At some point I
will try again and try to identify where I went wrong. Currently I am
finding the filesystem corruption to be more of a problem than grub
wr
*** This bug is a duplicate of bug 445852 ***
https://bugs.launchpad.net/bugs/445852
Am Dienstag, den 15.12.2009, 17:11 + schrieb Tommy Trussell:
> It sounds like you're saying that even though I mounted the /dev and
> /proc and chroot-ed into the mounted target I still must explicitly
> s
*** This bug is a duplicate of bug 445852 ***
https://bugs.launchpad.net/bugs/445852
I have finally confirmed that the errors appear when I invoke /lib/udev
/devkit-disks-probe-ata-smart as described in Comment #108 of Bug
445852. So I will declare this bug to be a duplicate of that one. (Plus
@Felix Zielcke: Thank you for the explanation. Maybe the bug is not with
grub but maybe the Debian installer not specifying the right device, or
something getting confused about which is the target device... ? I was
finally able to get a small Debian installation working on an SD card
using http://
Am Montag, den 14.12.2009, 15:52 + schrieb Tommy Trussell:
> A comment: it's blasted hard to make a bootable USB or SD card using
> the
> ASUS EEEpc alone. Grub apparently has a bug where it writes everything
> to the SSD regardless of where you specify it, AND /dev/ sometimes
> populates the r
i've been so focused on getting an installation running I lost track of
Bug 445852 -- lots of new info there the last few days.
--
beta installer left ASUS EeePC 900 unbootable
https://bugs.launchpad.net/bugs/430333
You received this bug notification because you are a member of Ubuntu
Bugs, which
I have finally seen a corrupted block after several hours of activity
using badblocks. Unfortunately, the corrupted block wasn't in the place
I was TRYING to make one. :-(
A comment: it's blasted hard to make a bootable USB or SD card using the
ASUS EEEpc alone. Grub apparently has a bug where it
and I finally got Debian up and running on an SD card -- no desktop,
just the terminal. What a PAIN. I'm hoping to start testing with
badblocks soon. I just hope I can get the SSD to fail in a way I can
test it.
I suspect this may be the same underlying bug as
http://bugzilla.kernel.org/show_bug.c
I finally got Arch up and running with Gnome on the SSD, and so far
there's no problems. It's kernel version 2.6.31-ARCH. It may take some
time before the bug propagates again on my machine as it was stable for
about a month before eating itself.
--
beta installer left ASUS EeePC 900 unbootable
h
Rather than going "downstream" from Ubuntu, I think I will go "upstream"
to Debian. I was thinking I would create a boot volume on a USB stick or
SD card -- enough to at least get me a terminal prompt and networking.
If the current working hypothesis is correct, some revision in kernel
2.6.31 (or e
Hey, thanks. I zeroed the drive, and was able to reformat it afterwards.
I'll try a couple of different distros as well. Starting with Arch.
(Mainly to see what it's like to have to stick you hands into your
system files.) I have some basic linux/coding skill, but nothing much
beyond being able to
My comment to shadowblast101 was so he might "rescue" his drive by
writing zeroes to it (so the regular utilities won't barf when they look
at it)...
I looked into how to use dd to write different patterns -- the trick is
to pipe the output of /dev/zero through /usr/bin/tr to convert to
whatever p
I would suggest to overwrite the device with a random, but defined
pattern instead of all zeroes (like DEADBEEF or something :P). This way,
you can verify the integrity afterwards. Zero bytes can be produced by
accident, DEADBEEF can't. So you will then see where the drive fails,
i.e., whether the
@shadowblast101: As per the eeeuser thread mentioned above, have you
tried "zeroing" out the SSD?
Boot from a Live distro on a USB key or SD card and issue the following
command at a terminal prompt:
dd if=/dev/zero of=/dev/sda bs=1M
(Oh, and it might make sense to be absolutely sure your SSD i
After attempting to install Arch, Debian, and Windows XP, I can safely
say that my SSD is entirely corrupted to the point were all of the
installations failed. I don't know if it's bad hardware or what, but I
can no longer use the SSD for anything.
--
beta installer left ASUS EeePC 900 unbootable
>From what we found out, this is a kernel bug. To report it upstream, it
should still be tested whether it also resides in other distributions
(preferrably with a vanilla kernel).
I'd suggest to test Debian first, then perhaps Gentoo with a
minimalistic set of kernel modules.
** Also affects: lin
** Attachment removed: "Screenshot-SMART Data.png"
http://launchpadlibrarian.net/36346740/Screenshot-SMART%20Data.png
--
beta installer left ASUS EeePC 900 unbootable
https://bugs.launchpad.net/bugs/430333
You received this bug notification because you are a member of Ubuntu
Bugs, which is sub
I have the exact same Patriot SSD in my AsusEEE 900, and have basically
the exact same corruption issues.
I'm running vanilla Ubuntu 9.10 right now, and the system will last for
about a month before something breaks. Before I had Kubuntu 9.04, and
never had a problem. I updated to 9.10 and the sys
I am marking this as invalid for grub 2 as it is either a Linux bug or a
hardware failure.
We can not consider this bug confirmed for any package as long as a
hardware failure is still the most likey cause of the problem.
I suggest finding someone on one of the many forums who has the exact
syme
@Tommy
I suggest asking on one of the many forums whether there is anybody with
the same model and have him or her try to reproduce the error.
We can not consider this bug confirmed if a hardware failure is still
the most likely cause.
--
beta installer left ASUS EeePC 900 unbootable
https://
I just replaced the 32gig upgrade SSD with the original 4gig SSD and ...
WOW. It works great (so far)
Much faster boot. No noticeable corruption. No long pauses with the disk
activity light on. Given the good performance I don't anticipate finding
any corruption, but I will try a few things to
@Dominik: OH and I don't know what "Default BIOS options" you are
suggesting -- there aren't many I have changed on this unit. It has been
a few weeks since I have reverted to Ubuntu Karmic 9.04 NBR, but I fully
expect it to work as it did before. (Boots quickly; No noticeable
corruption; Most hard
@Dominik: If you have a recommended distro that is known to work well on
an ASUS netbook, I can certainly try it. All the ones I have tried on it
so far (other than its stock Xandros) have been Ubuntu-based. (I started
with the one now called Easy-Peasy, and also Eeebuntu, and maybe one
other I'm n
I just completed a fresh install using Ubuntu Karmic 9.10 NBR release
version, except I chose to format the root partition as ext3 instead of
ext4. On reboot, I get the rescue:grub> prompt.
I imagine the filesystem is as hosed as before, but I'll leave it a
couple of days in case someone wants to
@Diminik: Thanks for the suggestions. I know an expert could learn more
about it with some write and read tests, especially using the earlier
beta releases where the installation failed every time. I don't think I
saw it at any of the links in my comment above, but somewhere I was
reading that peop
I think this might be a Linux bug, i.e., not specific to Ubuntu.
As this is a UNIX-style application, no userland application should
contain code that can produce the corruption you describe.
This said, the component most likely being responsible is the libscsi
driver module doing the real disk o
I have been using the release for an hour or so daily for several weeks.
I believe this problem is much less noticeable but not completely fixed,
and probably will blow up worse again with time. This past weekend I
noticed Evince wouldn't open. I cannot remember the last time I used
Evince on this
@Tommy:
So, is this bug fixed for you?
--
beta installer left ASUS EeePC 900 unbootable
https://bugs.launchpad.net/bugs/430333
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
htt
OK now I've installed the release version several times.
http://releases.ubuntu.com/9.10/ubuntu-9.10-netbook-remix-i386.iso
...except of course I used the torrent link. ;-)
The first time I installed the release version I saw errors running fsck
on the new root partition. There were broken applets
update: I downloaded and installed the 20091020.2 image
http://cdimage.ubuntu.com/ubuntu-netbook-remix/daily-live/20091020.2/ --
I chose to use the entire disk (which failed so badly before) but this
time the installation completed normally. After the first boot, there
are lots of GNOME warnings (f
I installed the 20090917 daily build. First the bad news:
When I installed using the full drive, the installation failed, though there
was a difference -- at the end of the installation sequence, it put up a dialog
saying
"Executing upgrade-grub failed. This is a fatal error."
Sure enough, I
Sorry to clutter the bug report with my notes, but after lots of
research I have decided the utility that MIGHT have worked to create an
image of the trashed filesystem is the "forensics" version of dd called
dcfldd (available in universe repo).
I'm installing the 20090918 daily build now.
--
be
The file I created with dd was only 30902344704 bytes ("28.8 GB"
according to Nautilus), so the bad blocks were probably just dropped. It
did compress down to "3.6 GB". But I'm guessing the interesting stuff is
probably not in there.
Tomorrow I will try today's daily build and see if the filesyste
I finally figured out to get dd to read the partition:
$ dd if=/dev/sda1 of=/media/label/asus.20090918.iso conv=noerror,sync
Lots of errors scrolled by (not captured). Should I have directed the
errors to a file?
The last error (so far; still copying) was at 6143488 bytes (6.1MB).
Once this is d
On Fri, Sep 18, 2009 at 01:57:18PM -, Tommy Trussell wrote:
> Maybe I could create an iso of the trashed 32GB filesystem for further
> analysis? I think I can plug in a big external drive and do that, then
> compress it and upload it somewhere.
I'm not sure where I'd put it :-), so there might
[looked at several things via irc yesterday with cjwatson at #ubuntu-
installer on irc.freenode.net. The freshly-installed filesystem is
trashed in a very strange way.]
I won't be available on irc very much today, but let me know if I should
try something else.
Maybe I could create an iso of the
OK -- the bad news is I got the rescue:grub> prompt on the reinstall.
The good news is the bug seems to be repeatable!
If I don't get to you on irc, let me know what to look for. I will leave
it alone this time!
--
beta installer left ASUS EeePC 900 unbootable
https://bugs.launchpad.net/bugs/430
Sorry I destroyed the evidence.
The fresh install with the smaller partition sizes DID work this time.
HOWEVER it was strange... it took a long time to boot up, then after the
desktop appeared GNOME complained about some non-functioning applets. I
told it not to remove them, though it took numerou
I don't know exactly where the problem is right now so I'm unable to
advise on what limits are relevant. Indeed, it might not even be a limit
at all, but some other thing that didn't turn up in my tests ...
While I respect that you might need the computer to work, it's actually
a shame that you're
I chose "manual partition" & created a 7000 MB (which became 7007 MB)
root partition and kept the existing 1373MB swap partition.
I don't understand why, but the manual partitioner says it formatted,
fsck'ed, THEN it says it resized (!!) the ext4 partition, and now DRAT!
it looks like it filled th
Colin: I will try the reinstall again and put 10GB or less on the root
install. It doesn't seem like 32GB should be considered "large" for ext4
but maybe it is too big for this SSD disk??
--
beta installer left ASUS EeePC 900 unbootable
https://bugs.launchpad.net/bugs/430333
You received this bug
Colin: To create the filesystem, I booted from the cdimage listed above
on a USB stick, ran the Install Ubuntu option from the boot menu, and
chose to wipe out the existing Ubunt 9.04 installation with the new 9.10
installation.
--
beta installer left ASUS EeePC 900 unbootable
https://bugs.launch
I just tried to fsck /dev/sda1, and it's reporting lots of errors. LOTS
of errors, including missing inodes, etc. I let fsck fix stuff, then
tried again. Now grub is completely hosed -- error: invalid extent.
root says "Unknown command 'root'
help says "Unknown command 'help'
SO that was the pro
It's OK for it to say ext2 - GRUB's ext2 module handles all of ext[234].
You're not the first person to report problems with large ext4
filesystems, though (note that I couldn't reproduce this with a sample
small filesystem), and it may be an overflow of some kind within ext2.c;
this is definitely
45 matches
Mail list logo
