Adam Pribyl <pri...@lowlevel.cz> skribis: > Kernel in dmesg identifies the device like /dev/sdf, doing > mknod /dev/sdf b 8 80; mknod /dev/sdf1 b 8 81; mount /dev/sdf1 /mnt > solves the problem. So definitely the drive is at sdf. It looks to me > like there is some built in limit in udev for number of "scsi" devices > in this case or something.
Hmm, I have no idea. We’re using a relatively old version of udev, maybe that will be solved when upgrading. >>> as there is only 1GB of RAM and it seems the install fetches too much >>> packages into ramdisk. Why is it not using the target file system >>> already? >> >> Hmm, it’s actually initially populating the local store, on the RAM >> disk, right. I agree that’s a problem we should address. >> >> However, most stuff are already in the store, unless the configuration >> being built uses many more packages, or use Xorg and related stuff. Is >> it what’s happening? > > The config.scm is as sugessted (just hostname and device modified): Hmm, OK. I’m surprised that this requires downloading more than 1GiB of stuff. I’m looking at a fix, but that’s not as simple as I would have liked. > Nothing special. I tried to bind mount the /gnu to a target drive, the > download went OK (cca 1.4G) but then led to different kind of failure. I’d be interested in knowing about that one as well. :-) Thanks, Ludo’.
