OpenBSD installation on eeepc 1000

[sutures]

Installation seems to go well, until I halt the system and reboot. System sits with a scrolling screen of death flashing by too fast to read. Something about Inodes and time there is a "fix YES" at the end of some of the lines. I can't really tell what is going on as it is scrolling too fast, and I am completely new to any *BSD. So I thought I would drop in and give you as much as I can so you can tell me I was making a stupid mistake, lol. 1st off, this is my first attempt at any BSD. I am using the installation instructions from the openbsd.org website. The eeepc has 4 partitions by default on the 8 gig SSD (wd0). Only one is used for the OS. The others are for recovery software. The second partition on the disk (a little over 3 gigs in) is the OS partition, I am leaving the others alone so I can recover back to the default xandros OS if needed. I have tried doing a single partition and label over the whole 4 gig OS part. I have tried breaking them up (as recommended by the instructions) over the 4 gig part. I have even tried spreading them around over the primary 8 gig SSD, 32 gig secondary SSD and a SD card for good measure. Everytime is the same thing.

Any help would be appreciated, but I know I am not offering much to go on. I am hoping it's a well known, obvious answer to an experienced user.

[jggimi]

Can you "scroll up" at all? On a 101-key PC keyboard, this is often Shift-PageUP.

"inodes" is a keyword that tells me there is a filesystem problem of some kind, but to determine what kind, more info would be needed.

Reboot the install media, and from the shell, issue:

# fdisk wd0
# disklabel wd0

Assuming your SSD device presents itself as wd0, of course.

The fdisk command will tell us about your MBR partition table.
The disklabel command will tell us about OpenBSD partitioning, within the OpenBSD MBR partition. There are additional lines of output, but the partition information (with start/stop/size info) is what to focus on.

Assuming your OpenBSD disklabel partitions are valid, you could run fsck against them -- this will at least check that each partition has a valid and correct filesystem on it. Note: wd0b is your swap space; and wd0c is the entire physical drive, so don't bother running fsck against them.

e.g.:

fsck -p /dev/wd0a

If the -p "preen" function of fsck fails, the filesystem is either not valid, or is damaged. The latter is possible, but less likely than the former.

[ocicat]

From what I can tell, Asus has come out with three different generations of the EeePC -- the 701, 900, & 1000 series. The misc@ archives indicates some traffic from about a year ago of a number of people successfully installing onto the 1000H:

http://marc.info/?l=openbsd-misc&w=2...eepc+1000h&q=b

Only you will be able to answer whether you have the same model.

Originally Posted by sutures

Installation seems to go well, until I halt the system and reboot. System sits with a scrolling screen of death flashing by too fast to read. Something about Inodes and time there is a "fix YES" at the end of some of the lines.

From your description (& from searching the archives where you were attempting to install FreeBSD...), it sounds like you are trying to set up a dual-boot system with the existing Xandros installation trying to preserve it if you are unsuccessful in installing one of the *BSD's.

If this is a correct assumption, it is unclear from your message how and/or if you resized the MBR partition in which Xandros resides such that space would be freed for another operating system, so let me review the basics:

• The Intel architecture first executes instructions defined in the BIOS to initialize all known hardware components. At its end, the BIOS checks to see if the MBR signature value of 0xAA55 is defined at the end of the first 512 bytes of the hard drive's first sector. If this value is found, it assumed that the drive is properly initialized, so execution is then handed off to the first of the sector also known as the Master Boot Record. Normally, the instructions poke about the table found at the end of the MBR to ensure that only one partition (of four possible...) is defined as active. If this is true, then continues the process attempting to boot whatever operating system exists in what is defined as active.
• When OpenBSD was installed, if you did not set its fdisk(8) (MBR) partition as active, what you may be describing is Xandros attempting to boot again.
• If you did not resize the amount of space Xandros occupies (because by default Asus will have configured Xandros to take up all hard drive space available...), the inode mess described may be accounted for by the fact that OpenBSD was installed on top of part of Xandros.
• If the Xandros installation was using any of the other three MBR partitions for what you call "system recovery" could have been seen in the fdisk(8) output at the beginning of installing OpenBSD.

Whether your Xandros installation can be recovered now is unclear from the information presented.

It is also unknown from your message as to what version of OpenBSD was being installed.

From your earlier messages, it appears that you are new to the *BSD's & perhaps to their installations which requires knowledge of the MBR & partitioning up front. Attempting to configure a dual-boot as a first exercise is also a bit ambitious.

If you have been using some type of system recovery disk provided by Asus, I suspect that it simply reinstalls Xandros to take up whatever space is available on the SSD. If you want to continue delving into a dual-boot configuration, you will need to determine whether this can be resized. Undoubtedly, this will require Linux tools. GParted is a common choice.

If I have characterized your situation correctly, & you have been able to restore Xandros through some CD, my suggestion is to install OpenBSD by itself. Forget about dual-booting for now. Gain the experience of a simple installation before tackling something more complicated.

[sutures]

I can answer some questions, but the laptop is at the house and I am at work.

First, I don't want to dual boot. I simply want to preserve the original 3 gig partition that holds a compressed image
Of the default OS so I don't have to dig around for the restore disc. As the eeepc ships from the factory with out a cd
Drive, it comes with a recovery partition on the ssd. Instead of booting from a cd you hit F9 during post to stat an
automated restore that it pulls from the first partition on the disk. I am installing onto the second portion without resizing
Any partitions. I simply changed the file system type to A6 and marked it as active. With the label utility I set wd0a to 250m
And mountpoint of /. I labeled the rest as wd0d and mounted /usr. I initialized wd1 whole disk and labeled wd1d 1024m
Mountpoint /tmp. Labeled the rest wd1e mountpoint /home. Initialized sda0 whole disk /var (cheap 2 gig sd card)

Automated restore from ssd still works.

Wow. Typing all that on the blackberry sucked...

[sutures]

Gah. This whole thing looks like it may be put on hold again. Was just notified that I have to get a comptia security+ cert by mid nov or I loose my job...

[sutures]

OK, quick update. Last night I restored the original Xandros OS and performed an install to a 4 gig 30Mb/s SD card. Set it up to boot from the SD card and mounted /home to the 32 gig SSD. Boots fine now. So the problem has to be the partition table on the 8 gig SSD, I don't know if I overlapped the partitions or if the problem was the "magic number" thing I was reading about. Either way I will run it from the SD card until I figure out if I can make OpenBSD do what I want it to do. Basically make wireless work, get XFCE on it for a window manager. I only really use it for internet anyway, hopefully it will be a little more flexable and less laggy than the default OS (5-10 seconds to open a web page and be able to scroll up/down on the page). Seems like I am not asking much, but we will see. Thanks for the help, I may revisit this issue at a later time if I decide it works well enough to completely wipe the default partition table.

Is there some documentation somewhere that I can read to let me know what portions of the file tree can be mounted read only for most day to day operations? Like I know that you have to have write access to the /usr folder for compiling programs, but sense you are not always compiling, can you mount it read only most of the time, but remount it rw if you need to compile something and then remount ro after the compile is done? Or do you have to have rw to run programs that are installed to /usr? I guess what I am looking for is documentation on how the base filesystem is utilized by the OS so I can optimize it for use on a SSD without wearing out the disk.

[jggimi]

Write-necessary structures for the standard OS: /etc, /var, /tmp, /home, /root, /dev.

[BSDfan666]

Note that /dev and /etc cannot be separate partitions, so / must be mounted read/write.

[jggimi]

Actually, if one is careful with how one modifies /etc/rc, one can indeed have a read-only /dev, and mount a writeable /dev during multi-user initiation. So it is -possible- to have /dev and /etc in their own, writeable partitions.

For an example of how that can work, grab any of the .iso files at the link in my sig. Take a look at the /etc/rc in it, and examine the /backups directory, too.

(Not that I would recommend it, modern flash memory does not have the write limitations of the older stuff.)

[BSDfan666]

BSDfan666 fails again, sorry.