On Sun, 20 Jul 2014, Ludovic Courtès wrote: > Adam Pribyl skribis: > >> On Sat, 19 Jul 2014, Ludovic Courtès wrote: >> >>> Adam Pribyl skribis: >>> >>>>> Sorry, I was completely wrong, the new liveUSB has e2fsprogs, >>>>> however I probably do have the problem with ahci module too, and I >>>>> confused the old /dev/sda harddrive which is now missing, and >>>>> /dev/sda USB. So this is it. My HDD is not visible with the new USB >>>>> image. >>>> >>>> OK, one more correction - the ahci module is loaded and HDD detected, >>>> but /dev/sdf is not created. There is just sda to sdd.. >>> >>> Once the USB installation is booted, it’s actually udev which takes the >>> responsibility of loading modules like AHCI (the problem David reported >>> is in the *installed* system, where the AHCI modules have to be >>> available in the initrd.) >>> >>> So there really are this many storage devices in the machine? >> >> Yes and no - there is a USB reader with many interfaces. They are >> reorder with this kernel and sda is now sdf. sda is the USB flash >> drive with the installation. > > Sure, but is there an actual USB storage device plugged in each on of > these interfaces? This is an internal card reader, devices like /dev/sdb, sdc, sde are reserved but empty - like an empty CDROM drive. > >>> Does running ‘udevadm trigger’ helps detect any missing device? >> >> Tried that before - no. > > Maybe there’s just nothing to detect, no? > > I don’t really understand what the problem is. What makes you think it > should detect sdf? What’s the target device node? 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. >> After a few mknods, I ended with "guix system init.." at Not enought >> space > > Before it started copying stuff? > >> 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): (use-modules (gnu) (gnu system grub)) (operating-system (host-name "foo") (timezone "Europe/Paris") (locale "en_US.UTF-8") (bootloader (grub-configuration (device "/dev/sdX"))) (file-systems (list (file-system (device "/dev/sdX1") (mount-point "/") (type "ext4"))))) 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. > Thanks, > Ludo’. Adam Pribyl