On Mon, 21 Jul 2014, Ludovic Courtès wrote: > Adam Pribyl 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. It looks around 700MB comes from the USB image itself, another 700MB is to be downloaded. I only have 478MB free ram disk. Together the /gnu has then 1.4GB roughtly. > I’m looking at a fix, but that’s not as simple as I would have liked. Maybe using the flash drive itself will serve better? >> 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. :-) > this involved mount /dev/sdf1 /mnt/ cp -a /gnu /mnt/ mount -o bind /mnt/gnu /gnu from now on, the target /mnt/gnu is filling up during guix system init. it ends up with initializing operating system under "/mnt" copying '/gnu......glibc-2.19.locales'... 2035 operations Bus error Thats it, the installation is not complete, there is just /gnu on target drive. > Thanks, > Ludo’. Adam Pribyl