vectorlinux 7.0

[9ae6]

Hello
When the VL 7.0 will be ready?

9ae6

[uelsk8s]

I am thinking we will start the Beta process in a couple weeks, and then the RC stage about 30-60 days after that

[9ae6]

Ok thank you.
I love vectorlinux

Best regards,
9ae6

[caieng]

Greetings!

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".

Please let me know if I could be of help to you....

regards,
CAI ENG

[GrannyGeek]

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

[demigaucher]

Hi all

I could not succeed in installing VL7Beta   

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 my
normal 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:

title VECTOR LINUX (on hda1)
root (hd0,0)
kernel /boot/vmlinuz root=/dev/hda1 ro vga=normal

Please, note that the letter of the drives are "h" in both lines.

Since VL7BETA is still experimental, I did not want to overwrite my working boot loader: while
installing VL7BETA (in hda8), I choose to install neither lilo nor grub, planning to create
later 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 was
being 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:

title Vector Linx 7 BETA EXPERIMENTAL (on partition
root (hd0,7)
kernel /boot/vmlinuz root=/dev/hda8 ro vga=normal

Result: kernel panic.

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:

title Vector Linx 7 BETA EXPERIMENTAL (on partition
root (hd0,7)
kernel /boot/vmlinuz root=/dev/sda8 ro vga=normal

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: it
was 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 I
did 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 critically
on the smooth (and automatic) installation of a graphical interface.



Demigaucher
happily running VL6.0 on a shuttle X
with AMD Athlon X1900+ @1463 MHz, 512 MB ram

[GrannyGeek]

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.

The VL7 beta 1 bug reports section ( http://forum.vectorlinux.com/index.php?topic=12938.0 ) may be a better place to post your problems if you don't get an answer here.
--GrannyGeek

[uelsk8s]

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

Code:

title Vector Linx 7 BETA EXPERIMENTAL (on partition8 )
root (hd0,7)
kernel /boot/vmlinuz root=/dev/sda8 ro vga=normal

the first hd0,7 is grubs hard disk naming, it has nothing to do with libata(sdx) and AFAIK it will not change.

here is lilo for VL6.0 and VL7.0

Code:

# Partition 4: Linux VL6.0
image = /boot/tamu/vmlinuz-vector-sda6
    root = /dev/hda6
    label = vector-sda6
    read-only
   
# Partition 5: Linux VL7.0
image = /boot/tamu/vmlinuz-vector-sda7
    root = /dev/sda7
    label = vector-sda7
    read-only

I had to manually change /etc/lilo.conf and change the /dev/sda6 to /dev/hda6 then rerun lilo.

hope that clears it up a little, and sorry for any confusion this caused.
Uelsk8s

[pierce.jason]

and soon it will be gone from the kernel altogether.

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.

[GrannyGeek]

Thanks for the explanation, uel. I'll work on fixing my lilo.conf and see if I can boot all the OSes on my hard drive.

I agree that it's time we did what the rest of the Linux world is doing as far as partition identification.
--GrannyGeek

[rm-r]

If I may add some comments:

Optical and Usb devices always did use the scsi convention
Recall the old "hdc=ide-scsi" emulation when users had problems to find "burners" ?
(sd, sr)

Devfs (prior to udev rules) - SCSI Persistent naming was used previously to avoid confusion using detachable media
w/out that, un-plugged, re-plugged device names changed
(scsi device chain naming)
Devfs may STILL be used -or script new rules for udev -which is redundant now

Alternatives:

If multiple O/systems are used, chain-loading is Req'd anyway
If confusion of which is the issue - insert a comment (#) in fstab,
noting what the old description was - and what it contains

E.G.
/dev/sda1  /boot   ext2  noauto,users,rw      0 0  ## hda1 BOOT  Gentoo

Conversely, use I.E. gparted (easiest way) to add partition labels
man fstab

Technically, Grub/grub2 is more flexible, can be repaired more readily than Lilo
Either can be created manually then loaded,  to boot from any media desired.

(See Rescatux, SuperGrub Disk or grub manual to repair)