Geronimo:
> Jochen Schulz wrote:
>> Geronimo:
>>>
>>> the last update of debian broke my system completely!
>>
>> I am very sorry for your wasted time and loss of data. I see why you
>> need to let off steam.
>
> Thank you very much! - usually I'm not that coarse.
That's ok. I am glad my mail didn't anger you even more. :)
>> Nevertheless I think this threads leads nowhere unless you are more specific
>> about the hardware in use and what kind of upgrade you actually ran. Instead
>> of insulting Debian developers you could try to help them get the problem
>> fixed (or make them aware in the first place).
>
> With my last post I wrote about my specific hardware.
I see. Didn't see it before sending my mail. I summarize what I know
until now:
- You have five disks (SSD or hard disks, shouldn't matter):
/ on sda1, ext4
/boot on sda2, ext2
swap on sdc1
/usr on sdc2, ext4 (btw, it's "UNIX system ressources", not "user")
another swap on sdd2
/var on sdd2, ext4
sdb and sde appear to be unused with respect to the squeeze system
(You may use them with squeeze, but they don't hold any
system-relevant data.)
- Some of these disks are attached to a secondary SATA controller
(RocketRAID 230x).
- Other disks are attached to the mainboard's (GA880GM-UD2H) controller.
- Your setup worked fine even after you upgraded from lenny to squeeze.
- You recently upgraded to the next point release and in the process
were asked to reboot. After that, your system didn't boot. Btw, I am
curious what exactly triggered the reboot warning. I cannot remember
having seen that.
Ok so far? Then let me ask a couple of questions:
- Which disks are connected to which controller?
- How did you upgrade to 6.0.1?
- Which packages were upgraded in the process? -I ask because the news
item for the point release doesn't mention grub at all (only
grub-installer, which you probably don't use) and that's one reason
why I suspect your problem isn't directly related to the upgrade to
6.0.1. All of dpkg, apt-get aptitude keep logs in /var/log.
(Oh great! I have never noticed apt-get's "term.log"s before!)
- How often did you reboot the system after the upgrade from lenny to
squeeze? I am not interested in the exact number, I just want to
ensure you did it at all. :)
- How did you configure the secondary controller? AHCI?
- Have you tried shuffling your disks around? Does the system respond
differently depending on the controller for / or /boot?
>> If you are under the impression that every package needs to pass
>> coordinated QA testing before it enters stable, then you are wrong.
>
> I followed quite a time several debian MLs and yes, my opinion from reading
> the discussion between developers was, that debian has a coordinated QA
> testing.
Well, the term "coordinated" might be a bit misleading. What I meant
was: I don't expect the grub maintainers (or any other DD) to
systematically test their package with various different hardware
configurations, filesystems etc. I guess they grab the release tarball
from upstream, patch it a little bit, compile it locally and in the best
case they test on their local machine (which might be a simple virtual
machine). Then they upload it to sid (or experimental, if they expect
alpha quality) and hope upstream didn't release total junk.
This is pure speculation and I may be wrong on that specific example.
But that's the general process as far as I understand it. The rest is
done by the user/developer community running sid or testing.
>> If nobody tested your setup using testing or sid, then you are basically
>> out of luck.
>
> I had the same issue when squeeze was testing and I reported it to this ML.
> But most comments leaded to my own problem.
It's always great to see how fast mailing list mirrors and search
engines catch up new posts. :)
> No one was willing to accept, that there's a big issue with grub.
Oh, there are definitely issues. It probably wouldn't be part of so many
distributions if "grub legacy" was still maintained.
>>> ... and the installer? Crashes on installing, when /usr and /var are
>>> different partitions which should not be formatted. Huh???
>>
>> This looks like a separate issue which you might want to report against
>> debian-installer. BTW, using unformatted /var and/or /usr for a fresh
>> installation looks like a bad idea to me.
>
> So, may be you can guide me to a better use case, when the system is broken
> and the machine does not work any more.
Well, I am not too proficient in these things either. I throw my
problems at Google like everyone else. :) But installing a new system on
top of an old one wasn't a good idea when I still used Windows 95 (good
riddance) and it still isn't a good idea today. /usr may contain
binaries which the system doesn't know about and thus don't receive
security updates. And /var contains system-specific data like dpkg's
database that you don't want to re-use on a new installation.
But anyway: if you have a reliable way of crashing the installer, use
reportbug (pseudo-package: debian-installer) to make the d-i team aware
of the problem. You cannot expect DDs to search the user lists for
problems in their packages. (Ok, you can trigger Joey Hess pretty
reliably by using "d-i" or "debian installer" in the subject, but don't
abuse that. ;-)).
J.
--
I think the environment will be okay.
[Agree] [Disagree]
<http://www.slowlydownward.com/NODATA/data_enter2.html>
Attachment:
signature.asc
Description: Digital signature