[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: System installation from a USB stick

From: Adam Pribyl
Subject: Re: System installation from a USB stick
Date: Mon, 21 Jul 2014 09:44:29 +0200 (CEST)
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)

On Sun, 20 Jul 2014, Ludovic Courtès wrote:

Adam Pribyl <address@hidden> skribis:

On Sat, 19 Jul 2014, Ludovic Courtès wrote:

Adam Pribyl <address@hidden> 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

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

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

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))

         (host-name "foo")
         (timezone "Europe/Paris")
         (locale "en_US.UTF-8")
         (bootloader (grub-configuration (device "/dev/sdX")))
           (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.


Adam Pribyl

reply via email to

[Prev in Thread] Current Thread [Next in Thread]