Logs from the problem partition:
paste.debian.net/17486/

The partition is still available, just haven't gone back to try it yet. Been busy setting up for a continuous rolling, testing install with aptitude and Synaptic. I'll let you know if Synaptic breaks anything, but it is handy.

The problem.
Tried the bizcard Debian testing install.
Install went well.
I did install the 2.6.18 kernel that was offered.
I asked for the testing install but had Etch repositories after running smxi the first time on the new install. (to get a config file). Then apt-type=aptitude and restarted smxi.


Problem occurred after installing new nvidia 173.xxxx driver and rebooting. Could not login. Grub was confused, could not login to sidux, on part1, either. Really unusual.

Reinstalled grub onto the original sidux partition. It would boot but would not run X.

Took advantage of the opportunity to install Erebus-Xfce-2008-02, and change to testing and aptitude.

sidux is the best and fastest installing distro
I have ever used.


This is not a pressing problem, just a curiosity.
I'll have to try the bizcard install a time or two to learn the ropes.
Back to top

You didn't do the correct install.

You installed etch/stable, not Testing.

there is only one way to reach the option to install sid/testing/stable, and that's to start the businesscard installer, and at the grub boot, select advanced options, then select the advanced install from the list.

If you do not see the option to pick unstable/testing/stable during the install process, you didn't start the installer using the right grub option, and you should exit, and do it over.

The smxi part about picking your distro is legacy, and has nothing to do with installing etch, testing, or sid, I need to get that cleaned up and make that cleaner, that was from an earlier idea I had that never happened.

I'm assuming you may have gotten the old grub, which will not boot ext3 partitions made for the new grub. I had this problem on a test install, all you need to do is boot with a livecd and install the new grub to mbr and it's all fine again. It took me a while to learn that, but that's why that happens.

I would not use etch in this way, not to multiboot, I use etch for machines that have a purpose, and which aren't dual / multi boot systems. Though I do play with it, but it's a bad idea, because of the grub issues.

To multiboot etch, its grub should be installed to partition root, not mbr. But remember, the new grub boots all old grubs fine.

Also keep in mind that Debian is not apparently handling uuid of /etc/fstab and /boot/grub/menu.lst yet, this causes problems in some cases, especially if you try to install sidux kernels.

also, you picked some mirrors that smxi can't handle re updating the sources, smxi can only handle standard ftp.us.debian.org <ftp/http://. country .debian.org syntax, that is>mirrors, the other stuff is far too complicated to handle.

also, it looks like you installed the desktop using business card. I have no idea what that does, beyond installing a lot of bad gnome or kde bloat.

I would wipe that one out, reformat the partition with a new livecd or parted magic, then reinstall.

Remember, if you do not see the question to select which debian type to install, you did not do it right.

See the businesscard install thread here for details and how to do it right. And if you didn't uncheck the desktop option in the later package group install section, you will get pretty much every package in the world installed to your desktop, which most people don't want or need.

Also, there's no need to manually set debian to use aptitude, it's built with aptitude, so that's an option in smxi already during the first run, to pick apt-get or aptitude.

Your first try had about as much luck as my first try installing etch explicitly on a multiboot system, that's when I learned about the old grub and formatting of partitions. However, all my other installs, testing, sid, are normal and fine, they just work.
Back to top

by the way, in my opinion, the Debian installer is almost purely for geeks only, it's about the very worst installer in terms of user friendliness and functionality I've seen in any major distro. The little tricks and weird things you need to know put this installer at the very bottom of the list of installers I have seen and used, I'm sad to say.

It has far too many places where errors or bugs happen, and they don't get fixed. For example, I had to start using businesscard installer cd because netinstall wouldn't even boot for me at one point.

I'm not sure why this is such a weak area in Debian. The installer does basically work, but only if you already know all the things you need to know to run it the way you want. User friendly it is not.
Back to top

Thanks for the notes. I figured I was in trouble when I saw that it called itself Etch, but I kept on to see what would happen. :)

And I remembered that I hadn't selected Expert install.
It usually takes a few iterations to learn the foibles of installers; and I agree, Debian is more obtuse than most. That's probably why sidux installer seems so much better --it is.

I followed your steps in converting the new erebus install to testing and aptitude. Then the choice is whether to leave it at Lenny or continue with testing. I really like the idea of testing: same rolling install but less breakage and more stability.
Back to top

Well, keep in mind, what you're doing with sidux isn't officially approved, switching sources to testing, but I would like to see your continued reports on how this works over time, that's for sure.

So if you can maybe just post every month or two with any specific issues you might experience with that, it would form a nice empirical knowledge base for others.

Personally, because I have some bugs in kde I cannot fix, probably caused by some early alpha kanotix->sidux conversion testing I did (no other conversion install I maintain has these issues, so it's not specific to just kanotix->sidux, it's something on just my system, related to locales I think, but I'm not sure), I am thinking of switching my main box to running full clean debian testing instead of sidux.

But you are right, the sidux install process fixes some issues that the debian installer isn't handling, most important, setting UUID ( would be better if set LABEL first, then UUID as fallback if no label) in fstab and menu.lst, that's some very solid work by kelmo that is top level.

I plan on adding a simplified fstab /dev/h|sdxy to LABEL / UUID converter in smxi when I find the time and energy, I can cheat because I don't have to generate the stuff, I just have to translate to uuid, which is a lot easier.

However, you can't really compare the sidux installer and the debian installer, the debian one works completely differently, it actually builds your system live, from apt, step by step, and offers quite a few more configuration options. But it's not good for quick installs, that's for sure, but Debian isn't meant to be installed more than one time, so that's not really that big a deal. I see the debian installers as being written for and by debian network/system admins, not for end users.

The sidux installer basically just writes the core config files, then dumps whatever is on the cdrom to hard disk, sort of anyway. That is a very different install logic and method, and it also has some bugs, most notably, the lingering failure to create separate /home, which is quite annoying if it appears, and forces users to do some fairly intricate command line stuff before anything else happens.
Back to top

Just a note:
Ran the "expert" parameter,
chose "Advanced Options" from the menu,
and the testing distribution (actually the default).

It trundled along and in about 30 minutes I have a new Debian testing install on part9, swap and it can see my /opt partition.

Curiously, when I ran,
# aptitude update && aptitude install mc synaptic
it offered to install about 150 other things. It said they were new installs and upgrades. So I declined and will wait for more time to see what they are, before continuing to build a testing system to compare to my converted sidux2testing system which is running like a clock, BTW.

Yes, I have been criticized for mentioning aptitude, so I really don't plan to bring it up over there. I have learned a lot from using kanotix->sidux for the last few years. I appreciate their point of view and don't have to argue my point, just do what I need to change my focus to a solid, dependable and ever-ready system.

Time will tell how well aptitude, synaptic and less than rigorous methods of installing and upgrading on a system following testing function. As you mentioned, the next year will provide some answers after Lenny is released and new stuff begins to arrive.

I do appreciate the people who run sid/sidux since I believe they lead to a better testing experience. I just want to place myself a bit more behind the curve.

Thanks for the pointers.
Back to top