You are not logged in.
Pages: 1
I use Arch for a few months now and I'm beginning to like it more and more. As I heard that Judd Vinet has all his servers running Arch, I thought I'd try Arch on a testpc to see how it would run as a server OS. I wanted to use LVM for my partitioning, so I made a /boot partition (150MB), a swap partition (4GB), a root partition (20GB) and the rest LVM (250GB). On the LVM-to-be-partition I did a `lvm pvcreate /dev/sda6`, then `lvm vgcreate system /dev/sda6`, then `lvm lvcreate --size 10GB --name tmp system`,` lvm lvcreate --size 10GB --name usr system`, `lvm lvcreate --size 10GB --name var system` and finally `lvm lvcreate --size 10GB --name home system`. Then I started /arch/setup and installed as I normally would, but I mounted /tmp, /usr, /var and /home on the LV's. In rc.conf I switched USELVM="no" to USELVM="yes", enabled the LVM-hook in mkinitcpio.conf and installed grub.
Now the problem: When I boot, the system switches to framebuffer, but I have no vga=791 option parsed to the kernel via grub. The problem is that the resolution is quite high and it isn't easy to read. Passing "nofb" or "vga=normal" doesn't change a thing. When initrd has finished booting and passed control to kinit, the switching happens at udev. Does anyone recognise this problem and have a solution to this problem?
Oh, and the part at booting, when initrd is finished and the "Arch Linux" text appears, that text is not in the white/light-blue colors but gray.
Offline
changing LVM stuff shouldn't have changed your framebuffer settings.
For a server, you don't need to use an attached monitor; you change stuff from another machine by setting up ssh.
If you specify vga=769 or similar, you can get a low 640x480 resolution.
EDIT: /boot/grub/menu.lst has this table of modes:
# FRAMEBUFFER RESOLUTION SETTINGS
# +-------------------------------------------------+
# | 640x480 800x600 1024x768 1280x1024
# ----+--------------------------------------------
# 256 | 0x301=769 0x303=771 0x305=773 0x307=775
# 32K | 0x310=784 0x313=787 0x316=790 0x319=793
# 64K | 0x311=785 0x314=788 0x317=791 0x31A=794
# 16M | 0x312=786 0x315=789 0x318=792 0x31B=795
# +-------------------------------------------------+Last edited by vogt (2008-03-08 20:04:56)
Offline
changing LVM stuff shouldn't have changed your framebuffer settings.
For a server, you don't need to use an attached monitor; you change stuff from another machine by setting up ssh.
If you specify vga=769 or similar, you can get a low 640x480 resolution.
EDIT: /boot/grub/menu.lst has this table of modes:
# FRAMEBUFFER RESOLUTION SETTINGS # +-------------------------------------------------+ # | 640x480 800x600 1024x768 1280x1024 # ----+-------------------------------------------- # 256 | 0x301=769 0x303=771 0x305=773 0x307=775 # 32K | 0x310=784 0x313=787 0x316=790 0x319=793 # 64K | 0x311=785 0x314=788 0x317=791 0x31A=794 # 16M | 0x312=786 0x315=789 0x318=792 0x31B=795 # +-------------------------------------------------+
Problem with that table is that it is framebuffer. I don't want framebuffer at all. Of course I manage my server through SSH, but still I think this shouldn't happen. And the lack of colors after the initrd is finished is also strange. After some research in inittab, I found out that after init gets control, it starts /etc/rc.sysinit, which displays the message "Arch Linux Core Dump, www.archlinux.org, copyright blabla". That message is in grey and not in the usual colors white and light-blue. A little later in /etc/rc.sysinit, it checks for /etc/start_udev and executes it twice, once with the parameter "init" and then with the parameter "uevents". The switch to framebuffer occurs when rc.sysinit executes line 77: "status "Loading UDev uevents" /etc/start_udev uevents".
Then I looked at /etc/start_udev at the function "udev_uevents" which is executed if start_udev gets "uevents" as parameter. The udev_uevents-function executes the functions "trigger_device_events" and "wait_for_queue" which start /sbin/udevtrigger and /sbin/udevsettle. It leads me to the conclusion that /sbin/udevtrigger somehow executes the switch to framebuffer. As /sbin/udevtrigger is executed on every ArchLinux-system and only with LVM in my situation switches to framebuffer, I think that the udev-hook in the initrd does something different if LVM is present.
Could anyone verify my problem by installing Arch Linux, where / is on a normal partition and /tmp, /usr, /var and /home are on a LVM ?
EDIT 1: I already have removed the LVM2-hook from my initrd to check if it had anything to do with my problem. Because the / filesystem is not on LVM, I don't need the LVM2-hook. Removing the LVM2-hook didn't make any difference.
EDIT 2: Passing the vga=771 option or any other of those listed in that table has the result that udev doesn't change to the 1280x1024 framebuffer setting, but the colors still miss. They appear when rc.multi is started (when I get the message "INIT: Entering runlevel 3". Then all colors are back again.
Last edited by jealma (2008-03-08 22:03:54)
Offline
I installed arch again, with now only /home on LVM, /var, /tmp and /usr on "normal" partitions. No problems with the colors and framebuffer resolution. Then I moved /tmp to LVM and rebooted, no problem. Then I moved /usr to LVM and rebooted. As soon as the boot process came to udev, it switched to framebuffer.
Next, I made a /usr map on the / partition and mounted the LVM-usr over it. No framebuffer problems. Then I began renaming folders in the /usr on the root partition to a temporary name, and it seems that the boot process needs something from /usr/bin. If that directory is not present at boot during udev, it switches to framebuffer. Is that information helpful?
Offline
how about booting with video=vesa:off
And then blacklisting (in rc.conf...or some other places) any hardware specific framebuffer modules (which would be be the cause of framebuffer loading after most of the startup is done). Check for those with lsmod | grep fb
But in any case, booting with vga=769 is as readable as without vesafb (though what drives the graphics card in that case?), and that resolves the original issue of a lack of readability.
You can also specify a bigger font with setfont (there's also a field in rc.conf to specify the prefered font).
Last edited by vogt (2008-03-14 06:20:07)
Offline
Pages: 1