I saw the announcement at distrowatch, and downloaded, yesterday, 09 February 2011, the beta version of VectorLinux 7.0.

Thanks.

Today, I attempted to install VL 7.0 on my two main test vehicles, both P3 machines, one at 1.1 GHz with 1 GB memory, and AGP S3 graphics controller , the other at 1.4 GHz with half a gig of memory and a Trident PCI video controller. I failed to install this beta version of VL 7.0, on either machine. The process halted on the first computer BEFORE reaching the screen asking the user to assign a satisfactory screen resolution. The computer simply stopped, without sending an error message, as if stuck, waiting.... The second computer did not have that problem, it moved right along, and presented the user with the choice of display resolution. I chose 1280 x 1024, because that is the resolution to which I am accustomed, with either Windows 98, (or XP), or Puppy Linux, or PCLinuxOS XFCE, all of which demand that the user choose the resolution desired, (i.e. not a default setting) just as did VL 7.0. The error message with VL on this second computer was terse, but informative, I suppose: words to the effect that the screen resolution selected was invalid.

I then attempted again, to install VL 7.0 on this second machine, but, again met with failure, despite having accepted the proposed default video resolution, i.e. 1024 x 768.

I have not tried going down, further, to 800 x 600, though, I would not be averse to doing so, pending feedback from the forum. I cannot use such a mediocre resolution, however, for my application, so, ultimately, I would need to change the resolution, post installation. Is there a program available for doing that, analogous to the program required for adjusting screen resolution with either Puppy Linux or PCLinuxOS?

I will be glad to post, or send by email, whichever log files would be of use, in addressing these two problems. The two computers are in different rooms, using different keyboards, mice, etc, and also two different monitors, of course. Alternatively, I can proceed to attempt to install this beta version on more modern computers, but, my application for VL requires use of one of these "old" computers, so for me, a test with newer devices is rather "inutile".

Today, I attempted to install VL 7.0 on my two main test vehicles, both P3 machines, one at 1.1 GHz with 1 GB memory, and AGP S3 graphics controller , the other at 1.4 GHz with half a gig of memory and a Trident PCI video controller. I failed to install this beta version of VL 7.0, on either machine. The process halted on the first computer BEFORE reaching the screen asking the user to assign a satisfactory screen resolution. The computer simply stopped, without sending an error message, as if stuck, waiting.... The second computer did not have that problem, it moved right along, and presented the user with the choice of display resolution. I chose 1280 x 1024, because that is the resolution to which I am accustomed, with either Windows 98, (or XP), or Puppy Linux, or PCLinuxOS XFCE, all of which demand that the user choose the resolution desired, (i.e. not a default setting) just as did VL 7.0. The error message with VL on this second computer was terse, but informative, I suppose: words to the effect that the screen resolution selected was invalid.

Today I installed VL7 beta 1 on one of my computers that is of about the same vintage as yours. The video is an ATI Radeon 9200 AGP4 card with 128 megs of its own RAM. I have a Samsung 19" lcd monitor with resolution of 1280x1024. With the many alphas of VL7 I installed, I could never install at this resolution. If I chose it at the first screen before the GUI installation itself, the screen would go black with a floating message about Not Optimum Resolution. I had to reboot via the power button. After I rebooted (cold boot) and the installation started over, I chose 1024x768 and everything proceeded without error.

When I installed beta1 today, I simply chose 1024x768 the first time and everything proceeded as it was supposed to.

NOTE: If this is the resolution selection you're talking about, it applies only to the GUI installation. When VL's installation is complete, you can choose your desired 1280x1024 resolution through VASM and you'll get it. I don't know if you got that far.

The first time I booted the installation CD, it never got to the screen where you choose resolution for the GUI installation. It hanged on some line that I didn't note and I had to shut off with the power button. I then rebooted and this time the installation had no problems getting past the original stopping point and proceeded without error and VL7 beta 1 is working well, with a few exceptions, at 1280x1024.--GrannyGeek

Eagerly burned a CD and checked the md5sum: OK. Booted on the CD, made all the process, including the first reboot. I met two problems:

1. using GRUB: the denomination of hard disks is incoherent (provisionally solved) 2. "failed to install the X server"

1. GRUB: I have a multiboot, using grub to boot several systems, including VL6.0, which is mynormal operating system, in the first partition. Grub was installed in the past by VL6.0 itself, overwriting lilo (command "grubconfig"), and the lines in its /boot/grub/menu.lst to boot itself are:

Since VL7BETA is still experimental, I did not want to overwrite my working boot loader: whileinstalling VL7BETA (in hda8), I choose to install neither lilo nor grub, planning to createlater an additional entry in menu.lst of VL6.0. But for the fist reboot, I let the install CD in place, and simply used it as a boot disc, typing:"linux boot et..." using the denomination hda8 to point to the partition where VL7BETA wasbeing installed.

Did not work (don't remember the exact message). I attempted then the following: boot on old VL6.0, create the additional entry in /boot/grub/menu.lst, in which I simply copied the old lines, but changing the index of the partition: root (hd0,0) becoming root (hd0,7) and /dev/hda1 becoming /dev/hda8, leading to:

I had noticed, during the installation, that the partitions were named "sda" in place of the usual "hda". This was an hint, and I tried changing some "s" to "h" in the entry above. Surprisingly, the only combination which could finally boot VL7BETA was a MIXTURE of both:

Please, note that in the second line, the letter "h" is used, while in the third one it is an "s"

So, there is some incoherence that should be cleared in the future: all "s" or all "h", but no mixture.

This explains why, when I tried to use the burned CD for the first reboot of the newly installed VL7BETA, it did not work: the very first menu explaining how to use this CD as a boot disc to boot an existing system gives an example in which the letter "h" is used. Good for booting old VL6.0, but incorrect now to boot VL7BETA, which needs sda in place of hda. So this explanation should be modified (but how ?).

2. X SERVER: In the old VL6.0 installation, after the first reboot and the congrats message, when offered the screen to configure the X server, I used "VXCONF". I had simply discovered, by trials and errors, that this choice worked for me. Later I had to choose "ati" for driver. Same remark: itwas empirical.

Now, with VL7BETA, after the choice of "VXCONF", no choice is offered. This is simpler for the user,but my installation invariably ends with the message:

Failed to install the X server (your graphical installer) etc...

I tried to copy in /etc the file xorg.conf of my old VL6.0: same error message.

The most surprising is that I attempted to install the alpha version of VL7, issued some time ago, and Idid not meet these problems !

Two last remarks:

- I noticed that the menu to create the additional users has been made more intuitive (less risk to click on "next" in place of "create user" ). Could be even clearer if the title of the button were "create this user".

- When the installer asks for reboot, the CD is not ejected automatically. Can puzzle newbies, including myself.

My opinion it that the most severe problem is related to this X server: the audience of a distro depends criticallyon the smooth (and automatic) installation of a graphical interface.

I use LILO, not Grub, and that /hda/sda issue exists in VL7 and has throughout the alphas. I can't boot to any of my multiple OSes that were identified as hdsomething when they were installed. Also, I can't boot with LILO to Windows, which was also identified as hda1 in earlier LILO installations.

Someone posted a solution using symlinks but I never bothered to work through it. I agree that something needs to be done because someone having other OSes on their computer and unfamiliar with VectorLinux may freak out when s/he can't start their other OSes.

I use LILO on a floppy disk to boot this computer. My other computer does not have a floppy drive, so I use the VL installation disk to boot to VL. I never overwrite the MBR on a system with multiple OSes.

I will try to address the hda, sda drive naming. It has been 2-3 years since the kernel and most other distros switched to the new libata(sdx) naming scheme for IDE hard disks. In the past in order to keep compatibility we decided to go with the legacy option. It is getting harder and harder to use this legacy naming scheme and soon it will be gone from the kernel altogether. So starting with VL7.0 we have decided to become compatible with the rest of the linux world and move to the libata(sdx) naming scheme.We know this will cause problems for some.

The easiest way to boot any linux system is to give the kernel the sda or hda designation that it expects.this is correct for VL7.0-B1 using grub-legacy

I know this is currently achieved by using the older pata drivers as first-choice, and using sata drivers only when sata/scsi devices are needed.

However, would it be possible to use only the sata drivers(like you're saying), and have udev assign naming based on bus-type?

Seems udev is smart enough to recognize a cdrom on sata driver as being different. And smart enough to recognize a usb device on sata driver as being different.

I wish I were more familiar with udev and could specifically mention, or even formulate, the label or such that would be needed for this. But udev is almost like black magic to me and I always end up breaking things horribly when I attempt to write udev rules lol.

Perhaps having differentiated naming is not as important as it once was, but this is in fact one of my favorite features of vector. Being able to see at a glance in fstab, mount, df, etc.... which lines are my legacy hardware storage.