7.1pre install on scsi/sata : impossible?

Moo-Crumpus · 2005-12-13 22:44:05

Before I add a bug report, I wanted to ask if someone could second that

- for scsi cdroms no nodes are created - like /dev/scd0 - so one can not load modules from the setup cdrom
- for sata cdroms no nodes are created - as the kernel is still unpatched to support sata-atapi
- you can't switch keyboard layout so native languaged people are somehow stuck trying to type "ls /dev/ | grep cd" or "ls /dev/scd*"
- autoprobe of network modules fails (maybe in follow of issue 1 and 2) at least for forcedeth and sklin98
- some fs are not supported without modprobing, like jfs, xfs

paranoos · 2005-12-13 23:56:48

i think it's best to just go ahead and file the bug report. if only one person is experiencing a problem, it can still be a bug.

i think some of those problems can be solved by modprobing kernel modules (assuming the modules you need are in fact included), and there isn't anything wrong with that ... it simply has to be addressed by the documentation.

apeiro · 2005-12-14 17:59:21

Moo-Crumpus wrote:

- for scsi cdroms no nodes are created - like /dev/scd0 - so one can not load modules from the setup cdrom
- for sata cdroms no nodes are created - as the kernel is still unpatched to support sata-atapi

Yea, this needs fixing. Maybe you can help me out? I'm a scsi idiot and only have archaic ide drives. What nodes/majors/minors do sata/scsi users need? The install environment uses a static /dev for 0.7.1, so I need to create these nodes manually.

- you can't switch keyboard layout so native languaged people are somehow stuck trying to type "ls /dev/ | grep cd" or "ls /dev/scd*"

There will be a "km" utility in 0.7.1-final which helps you load keymaps and consolefonts. I'm also an i18n idiot, so let me know if this is sufficient for non-US keyboard users.

- autoprobe of network modules fails (maybe in follow of issue 1 and 2) at least for forcedeth and sklin98

The autoprobe in the installer is poor at best. We have the superior hwdetect now, but busybox's built-in modprobe will not work with the new modalias stuff, so 0.7.1 is stuck with the old, not-so-great autoprobing.

The plan is to change the 0.8 installation environment significantly. Right now we cram what we can into a 1.4mb root image, which means no room for things like the real module-init-tools, udev, etc. The advantage is that the root image used by the CD is exactly the same as the floppy disk one. I don't think many people use/need the floppy disk install, so I'm going to look for a better way of doing it for 0.8.

- some fs are not supported without modprobing, like jfs, xfs

These are modules for the same reason as above, so that I could package them on a separate floppy disk. When booting from the install CD, these modules will be loaded automatically, so users don't notice any problems.

paranoos · 2005-12-14 21:18:20

ahh... i always wonder, why can't we do this or that nifty thing in the install cd. i forget that arch has install floppies as well.

i've encountered folks on the forums occasionally who love that arch still provides floppies for installation, so i suppose it'd be helpful to keep that around in its current form. perhaps the install cd could use the standard kernel with the initrd-full.img ... is that possible? this way there's a special small kernel for floppies, and just the plain old kernel for the cd, with proper hwdetect and a full bash shell instead of busybox (which has been the culprit of bad backups for me in the past).

scarecrow · 2005-12-14 21:38:51

No problems here with SATA controllers (no sata-atapi though), but I do have pretty ordinary Intel stuff present. I also have an Ultraplex 40 hooked on an Adaptec 2904, and it just works- but I use the archck kernel (slightly modded), no idea what happens with the stock one.
I can confirm the sklin98 issue, somehow it seems that the module included in the current "vanilla" kernel revisions is broken, or rather not functioning with all the hardware implementations of the Yukon Marvell chipset. It's not an Arch thing, as I saw it happening with Mandriva, Kanotix, Vector and Slax (latest versions) as well...
But the solution is fairly easy: get from the Marvell site the latest stock, non-GPL driver and compile it. It worked just fine for me on my lappy.

Moo-Crumpus · 2005-12-15 11:41:17

apeiro wrote:

Moo-Crumpus wrote:
- for scsi cdroms no nodes are created - like /dev/scd0 - so one can not load modules from the setup cdrom
- for sata cdroms no nodes are created - as the kernel is still unpatched to support sata-atapi
Yea, this needs fixing. Maybe you can help me out? I'm a scsi idiot and only have archaic ide drives. What nodes/majors/minors do sata/scsi users need? The install environment uses a static /dev for 0.7.1, so I need to create these nodes manually.

Device Names

A device name can be thought of as a gateway to a kernel driver that controls a device rather than the device itself. Hence there can be multiple device names some of which may offer slightly different characteristics, all mapping to the same actual device.

The device names of the various SCSI devices are found within the /dev directory. Traditionally in Linux, SCSI devices have been identified by their major and minor device number rather than their SCSI bus addresses (e.g. SCSI target id and LUN). The device pseudo file system (devfs) moves away from the major and minor device number scheme and for the SCSI subsystem uses device names based on the SCSI bus addresses [discussed later in Section 3.3 and see reference: W5]. Alternatively, there is a utility called scsidev which addresses this issue within the scope of the Linux SCSI subsystem and thus does not have the same system wide impact as devfs. Scsidev is discussed later in Section 3.4 and ref: W6.

Eight block major numbers are reserved for SCSI disks: 8, 65, 66, 67, 68, 69, 70 and 71. Each major can accommodate 256 minor numbers which, in the case of SCSI disks, are subdivided as follows:

[b,8,0] /dev/sda
[b,8,1] /dev/sda1
....
[b,8,15] /dev/sda15
[b,8,16] /dev/sdb
[b,8,17] /dev/sdb1
....
[b,8,255] /dev/sdp15

The disk device names without a trailing digit refer to the whole disk (e.g. /dev/sda) while those with a trailing digit refer to one of the 15 allowable partitions [2] within that disk.

The remaining 7 SCSI disk block major numbers follow a similar pattern:

[b,65,0] /dev/sdq
[b,65,1] /dev/sdq1
....
[b,65,159] /dev/sdz15
[b,65,160] /dev/sdaa
[b,65,161] /dev/sdaa1
....
[b,65,255] /dev/sdaf15
[b,66,0] /dev/sdag
[b,66,1] /dev/sdag1
....
[b,66,255] /dev/sdav15
....
[b,71,255] /dev/sddx15

So there are 128 possible disks (i.e. /dev/sda to /dev/sddx) each having up to 15 partitions. By way of contrast, the IDE subsystem allows 20 disks (10 controllers each with 1 master and 1 slave) which can have up to 63 partitions each.

SCSI CD-ROM devices are allocated the block major number of 11. Traditionally sr has been the device name but scd probably is more recognizable and is favoured by several recent distributions. 256 SCSI CD-ROM devices are allowed:

[b,11,0] /dev/scd0 [or /dev/sr0]
[b,11,255] /dev/scd255 [or /dev/sr255]

SCSI tape devices are allocated the char major number of 9. Up to 32 tape devices are supported each of which can be accessed in one of four modes (0, 1, 2 and 3), with or without rewind. The devices are allocated as follows:

[c,9,0] /dev/st0 [tape 0, mode 0, rewind]
[c,9,1] /dev/st1 [tape 1, mode 0, rewind]
....
[c,9,31] /dev/st31 [tape 31, mode 0, rewind]
[c,9,32] /dev/st0l [tape 0, mode 1, rewind]
....
[c,9,63] /dev/st31l [tape 31, mode 1, rewind]
[c,9,64] /dev/st0m [tape 0, mode 2, rewind]
....
[c,9,96] /dev/st0a [tape 0, mode 3, rewind]
....
[c,9,127] /dev/st31a [tape 31, mode 3, rewind]
[c,9,128] /dev/nst0 [tape 0, mode 0, no rewind]
....
[c,9,160] /dev/nst0l [tape 0, mode 1, no rewind]
....
[c,9,192] /dev/nst0m [tape 0, mode 2, no rewind]
....
[c,9,224] /dev/nst0a [tape 0, mode 3, no rewind]
....
[c,9,255] /dev/nst31a [tape 31, mode 3, no rewind]

The SCSI generic (sg) devices are allocated the char major number of 21. There are 256 possible SCSI generic (sg) devices:

[c,21,0] /dev/sg0
[c,21,1] /dev/sg1
....
[c,21,255] /dev/sg255

Note that the SCSI generic device name's use of a trailing letter (e.g. /dev/sgc) is deprecated.

Each SCSI disk (but not each partition), each SCSI CD-ROM and each SCSI tape is mapped to an sg device. SCSI devices that don't fit into these three categories (e.g. scanners) also appear as sg devices.

Pseudo devices [see Section 10.1] can cause devices that are usually not considered as SCSI to appear as SCSI device names. For example an ATAPI CD-ROM may be picked up by the ide-scsi pseudo driver and mapped to /dev/scd0 .

The linux/Documentation/devices.txt file supplied within the kernel source is the definitive reference for Linux device names and their corresponding major and minor number allocations.

http://www.faqs.org/docs/Linux-HOWTO/SC … tml#dnames

yazdzik · 2005-12-16 06:27:48

Dear Friends,

http://bbs.archlinux.org/viewtopic.php?t=16835

Is this a similar issue?

Best,
M

Moo-Crumpus · 2005-12-16 08:31:17

yazdzik wrote:

Dear Friends,
http://bbs.archlinux.org/viewtopic.php?t=16835
Is this a similar issue?
Best,
M

For the sata problem, yes. sata owns the same node scheme then scsi. They are not touched as long as you don't hack the libata.h files. Therefore, without a sata prepared / hacked kernel, you'll not be able to install from sata cd source, afaik.

Moo-Crumpus · 2005-12-16 09:01:10

I managed to go a step further by

mknod /dev/scd0 b 11 0
loaddisk /dev/scd0

But in the end, the installation of grub freezes in the first try. Restart setup script, retouch configuration, install grub then will lead to a questiton for the current root path - hell, it is mentioned in grub's menu.list. Is anybody else questioned for that?

I tried to install lilo in spite of grub, and run into another error, as this script will install into /dev(hda, and does not care wether there is such a node or not.

Haven installed grub, I noticed no initrd26.img was created, but a daig1.img. Guess what - can't boot with this one, booted into cd again, mounted root to /mnt/, chrooted to it, and did mkinitrd full. Can#t boot it either, kernel panic is the result:

 No init found, try passing init= to kernel

I need advice, I think. Am I the only scsi user?

phrakture · 2005-12-16 16:22:46

Hmmm, I'd have to try this again, but I was able to install 0.7 just fine on a full SATA system. It might be different with 0.7.1, I haven't tried.

It may take some time to move data around and clear a partition so that I can install, but I would be willing to test at some point.

Moo-Crumpus · 2005-12-16 17:00:11

Might depend on the sata chip. I had none scsi issues with 0.7.

Next step: still have to create the nodes by hand, but grub installs well if fs is not xfs. Jfs is OK, f.e. Well, seems to be an xfs / grub bug then.

Still no initrd26.img is created, and if I boot, it sucks.

Moo-Crumpus · 2005-12-18 06:36:47

initrd26.img is doing now. Still the nodes have to be created by hand, but Judd is going to fix it. I have tested now reiserfs, jfs, xfs - things are quite well. The grub installation still has a hang on the first trial if installed on xfs, but hey. Thanks for help and testing, and of course fixing.

apeiro · 2005-12-18 19:10:58

Moo-Crumpus wrote:

Still the nodes have to be created by hand, but Judd is going to fix it.

Okay, I've fixed the fd0 node and I've added nodes scd0-4 to the installation environment. Also added sr0-4, but they mirror the major/minors of scd, so nothing new there.

Were there any other nodes you were missing, Moo-Crumpus?

Moo-Crumpus · 2005-12-19 09:21:02

Not for me, thanks, apeiro.

Arch Linux

#1 2005-12-13 22:44:05

7.1pre install on scsi/sata : impossible?

#2 2005-12-13 23:56:48

Re: 7.1pre install on scsi/sata : impossible?

#3 2005-12-14 17:59:21

Re: 7.1pre install on scsi/sata : impossible?

#4 2005-12-14 21:18:20

Re: 7.1pre install on scsi/sata : impossible?

#5 2005-12-14 21:38:51

Re: 7.1pre install on scsi/sata : impossible?

#6 2005-12-15 11:41:17

Re: 7.1pre install on scsi/sata : impossible?

#7 2005-12-16 06:27:48

Re: 7.1pre install on scsi/sata : impossible?

#8 2005-12-16 08:31:17

Re: 7.1pre install on scsi/sata : impossible?

#9 2005-12-16 09:01:10

Re: 7.1pre install on scsi/sata : impossible?

#10 2005-12-16 16:22:46

Re: 7.1pre install on scsi/sata : impossible?

#11 2005-12-16 17:00:11

Re: 7.1pre install on scsi/sata : impossible?

#12 2005-12-18 06:36:47

Re: 7.1pre install on scsi/sata : impossible?

#13 2005-12-18 19:10:58

Re: 7.1pre install on scsi/sata : impossible?

#14 2005-12-19 09:21:02

Re: 7.1pre install on scsi/sata : impossible?

Board footer