Installer Finds No CRUX Partitions, Fdisk Missing
I used dd to put the 3.1 ISO onto a USB-stick and that boots nominally. The installer sees all my existing partitions and rightly concludes none are CRUX file systems. It drops me into a shell that I can use to recover. Only one directory in the PATH exists, /bin, and it contains not fdisk, making it impossible to get any further. The Handbook does not indicate a CRUX partition needs to be created prior to booting the installer. -- <not cent from sell> May the LORD God bless you exceedingly abundantly! Dave_Craig______________________________________________ "So the universe is not quite as you thought it was. You'd better rearrange your beliefs, then. Because you certainly can't rearrange the universe." __--from_Nightfall_by_Asimov/Silverberg_________________
It is not clear what criteria the installer uses to decide just what is a CRUX partition. Does CRUX add something to an ext4 partiton, for example, that shows its CRUXness? If not, perhaps my filesystems are too bleeding edge for CRUX to recognize; e.g., tune2fs 1.42.12 (29-Aug-2014) Filesystem volume name: DD Last mounted on: / Filesystem UUID: fdd6fbc7-3dc6-4a92-9f07-cdc6926cce8d Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg extra_isize Filesystem flags: signed_directory_hash Default mount options: user_xattr uid16 nobarrier block_validity discard nodelalloc Filesystem state: clean Errors behavior: Remount read-only Filesystem OS type: Linux Inode count: 1310720 Block count: 5242880 Reserved block count: 1024 Free blocks: 257994 Free inodes: 939749 First block: 0 Block size: 4096 Fragment size: 4096 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8192 Inode blocks per group: 512 Flex block group size: 1024 Filesystem created: Mon Oct 21 07:53:50 2013 Last mount time: Wed Nov 19 14:14:55 2014 Last write time: Wed Nov 19 14:14:55 2014 Mount count: 52 Maximum mount count: 256 Last checked: Wed Nov 5 10:34:37 2014 Check interval: 15552000 (6 months) Next check after: Mon May 4 11:34:37 2015 Lifetime writes: 3533 GB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 First orphan inode: 832 Default directory hash: tea Directory Hash Seed: 002ce074-db54-4d94-b796-4403b10f655e Journal backup: inode blocks -- <not cent from sell> May the LORD God bless you exceedingly abundantly! Dave_Craig______________________________________________ "So the universe is not quite as you thought it was. You'd better rearrange your beliefs, then. Because you certainly can't rearrange the universe." __--from_Nightfall_by_Asimov/Silverberg_________________
Hi David, The CRUX Installer *does not* do anything special; no. It is entirely up to you how things are partitioned, labelled etc. cheers James James Mills / prologic E: prologic@shortcircuit.net.au W: prologic.shortcircuit.net.au On Thu, Nov 20, 2014 at 6:37 AM, David L. Craig <dlc.usa@gmail.com> wrote:
It is not clear what criteria the installer uses to decide just what is a CRUX partition. Does CRUX add something to an ext4 partiton, for example, that shows its CRUXness? If not, perhaps my filesystems are too bleeding edge for CRUX to recognize; e.g.,
tune2fs 1.42.12 (29-Aug-2014) Filesystem volume name: DD Last mounted on: / Filesystem UUID: fdd6fbc7-3dc6-4a92-9f07-cdc6926cce8d Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg extra_isize Filesystem flags: signed_directory_hash Default mount options: user_xattr uid16 nobarrier block_validity discard nodelalloc Filesystem state: clean Errors behavior: Remount read-only Filesystem OS type: Linux Inode count: 1310720 Block count: 5242880 Reserved block count: 1024 Free blocks: 257994 Free inodes: 939749 First block: 0 Block size: 4096 Fragment size: 4096 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8192 Inode blocks per group: 512 Flex block group size: 1024 Filesystem created: Mon Oct 21 07:53:50 2013 Last mount time: Wed Nov 19 14:14:55 2014 Last write time: Wed Nov 19 14:14:55 2014 Mount count: 52 Maximum mount count: 256 Last checked: Wed Nov 5 10:34:37 2014 Check interval: 15552000 (6 months) Next check after: Mon May 4 11:34:37 2015 Lifetime writes: 3533 GB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 First orphan inode: 832 Default directory hash: tea Directory Hash Seed: 002ce074-db54-4d94-b796-4403b10f655e Journal backup: inode blocks -- <not cent from sell> May the LORD God bless you exceedingly abundantly!
Dave_Craig______________________________________________ "So the universe is not quite as you thought it was. You'd better rearrange your beliefs, then. Because you certainly can't rearrange the universe." __--from_Nightfall_by_Asimov/Silverberg_________________
_______________________________________________ CRUX mailing list CRUX@lists.crux.nu http://lists.crux.nu/mailman/listinfo/crux
I tried booting the USB-stick on my Acer Aspire 1 netbook and the installer decided the USB-stick was what it was looking for; i.e., no problem finding the CRUX media and getting to the root prompt. Back on the Gigabyte desktop, it appears CRUX mdev creates /dev/sdh{,1,2} but any examination thereof is not reported. This is what Debian Sid logged in /var/log/kern.log when the USB-stick was plugged in: [ 76.296026] usb 3-2: new high-speed USB device number 3 using ehci-pci [ 76.439490] usb 3-2: New USB device found, idVendor=13fe, idProduct=1e23 [ 76.439676] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 76.439849] usb 3-2: Product: STORE N GO [ 76.440029] usb 3-2: Manufacturer: Verbatim [ 76.440250] usb 3-2: SerialNumber: 07951A09609608D5 [ 76.440915] usb-storage 3-2:1.0: USB Mass Storage device detected [ 76.441205] scsi11 : usb-storage 3-2:1.0 [ 77.485134] scsi 11:0:0:0: Direct-Access Verbatim STORE N GO 5.00 PQ: 0 ANSI: 0 CCS [ 77.485618] sd 11:0:0:0: Attached scsi generic sg8 type 0 [ 77.814504] sd 11:0:0:0: [sdh] 31272960 512-byte logical blocks: (16.0 GB/14.9 GiB) [ 77.815245] sd 11:0:0:0: [sdh] Write Protect is off [ 77.815403] sd 11:0:0:0: [sdh] Mode Sense: 23 00 00 00 [ 77.815998] sd 11:0:0:0: [sdh] No Caching mode page found [ 77.816163] sd 11:0:0:0: [sdh] Assuming drive cache: write through [ 77.863517] sdh: sdh1 sdh2 [ 77.866373] sd 11:0:0:0: [sdh] Attached SCSI removable disk Below are lsusb and lspci -k command outputs, first in the recovery shell, then according to Debian Sid: CRUX (typed from display): Bus 002 Device 002: ID 13fe:1e23 Bus 002 Device 003: ID 058f:6362 Bus 001 Device 001: ID 1d6b:0002 Bus 002 Device 001: ID 1d6b:0002 Bus 003 Device 001: ID 1d6b:0001 Bus 004 Device 001: ID 1d6b:0001 Bus 005 Device 001: ID 1d6b:0001 Bus 006 Device 001: ID 1d6b:0001 Bus 007 Device 001: ID 1d6b:0001 Bus 008 Device 001: ID 1d6b:0001 Bus 009 Device 001: ID 1d6b:0002 Bus 010 Device 001: ID 1d6b:0003 00:00.0 Class 0600: 8086:2e20 00:01.0 Class 0604: 8086:2e21 pcieport 00:06.0 Class 0604: 8086:2e29 pcieport 00:1a.0 Class 0c03: 8086:3a37 uhci_hcd 00:1a.1 Class 0c03: 8086:3a38 uhci_hcd 00:1a.2 Class 0c03: 8086:3a39 uhci_hcd 00:1a.7 Class 0c03: 8086:3a3c ehci-pci 00:1c.0 Class 0604: 8086:3a40 pcieport 00:1c.3 Class 0604: 8086:3a46 pcieport 00:1c.4 Class 0604: 8086:3a48 pcieport 00:1d.0 Class 0c03: 8086:3a34 uhci_hcd 00:1d.1 Class 0c03: 8086:3a35 uhci_hcd 00:1d.2 Class 0c03: 8086:3a36 uhci_hcd 00:1d.7 Class 0c03: 8086:3a3a ehci-pci 00:1e.0 Class 0604: 8086:244e 00:1f.0 Class 0601: 8086:3a16 00:1f.2 Class 0106: 8086:3a22 ahci 00:1f.3 Class 0c05: 8086:3a30 01:00.0 Class 0300: 10de:0141 02:00.0 Class 0c03: 1033:0194 xhci_hcd 04:00.0 Class 0106: 197b:2363 ahci 04:00.1 Class 0101: 197b:2363 pata_jmicron 05:00.0 Class 0200: 10ec:8168 06:00.0 Class 0401: 1120:0004 06:00.1 Class 0980: 1120:7003 06:00.2 Class 0c00: 1120:4001 firewire_ohci Sid: Bus 003 Device 002: ID 058f:6362 Alcor Micro Corp. Flash Card Reader/Writer Bus 003 Device 003: ID 13fe:1e23 Kingston Technology Company Inc. Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 010 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 009 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub 00:00.0 Host bridge: Intel Corporation 4 Series Chipset DRAM Controller (re v 03) Subsystem: Gigabyte Technology Co., Ltd GA-EP45-DS5/GA-EG45M-DS2H Motherboard 00:01.0 PCI bridge: Intel Corporation 4 Series Chipset PCI Express Root Port (rev 03) Kernel driver in use: pcieport 00:06.0 PCI bridge: Intel Corporation 4 Series Chipset PCI Express Root Port (rev 03) Kernel driver in use: pcieport 00:1a.0 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #4 Subsystem: Gigabyte Technology Co., Ltd Motherboard Kernel driver in use: uhci_hcd 00:1a.1 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #5 Subsystem: Gigabyte Technology Co., Ltd Motherboard Kernel driver in use: uhci_hcd 00:1a.2 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #6 Subsystem: Gigabyte Technology Co., Ltd Motherboard Kernel driver in use: uhci_hcd 00:1a.7 USB controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #2 Subsystem: Gigabyte Technology Co., Ltd Motherboard Kernel driver in use: ehci-pci 00:1c.0 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 1 Kernel driver in use: pcieport 00:1c.3 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 4 Kernel driver in use: pcieport 00:1c.4 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 5 Kernel driver in use: pcieport 00:1d.0 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #1 Subsystem: Gigabyte Technology Co., Ltd GA-EP45-DS5 Motherboard Kernel driver in use: uhci_hcd 00:1d.1 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #2 Subsystem: Gigabyte Technology Co., Ltd GA-EP45-DS5 Motherboard Kernel driver in use: uhci_hcd 00:1d.2 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #3 Subsystem: Gigabyte Technology Co., Ltd GA-EP45-DS5 Motherboard Kernel driver in use: uhci_hcd 00:1d.7 USB controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #1 Subsystem: Gigabyte Technology Co., Ltd GA-EP45-DS5 Motherboard Kernel driver in use: ehci-pci 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 90) 00:1f.0 ISA bridge: Intel Corporation 82801JIR (ICH10R) LPC Interface Controller Subsystem: Gigabyte Technology Co., Ltd GA-EP45-DS5 Motherboard Kernel driver in use: lpc_ich 00:1f.2 SATA controller: Intel Corporation 82801JI (ICH10 Family) SATA AHCI Controller Subsystem: Gigabyte Technology Co., Ltd GA-EP45-DS5/GA-EG45M-DS2H Motherboard Kernel driver in use: ahci 00:1f.3 SMBus: Intel Corporation 82801JI (ICH10 Family) SMBus Controller Subsystem: Gigabyte Technology Co., Ltd GA-EP45-DS5/GA-EG45M-DS2H Motherboard Kernel driver in use: i801_smbus 01:00.0 VGA compatible controller: NVIDIA Corporation NV43 [GeForce 6600] (rev a2) Subsystem: Device 196e:021f Kernel driver in use: nouveau 02:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03) Subsystem: Gigabyte Technology Co., Ltd Device 5007 Kernel driver in use: xhci_hcd 04:00.0 SATA controller: JMicron Technology Corp. JMB363 SATA/IDE Controller (rev 02) Subsystem: Gigabyte Technology Co., Ltd Motherboard Kernel driver in use: ahci 04:00.1 IDE interface: JMicron Technology Corp. JMB363 SATA/IDE Controller (rev 02) Subsystem: Gigabyte Technology Co., Ltd Motherboard Kernel driver in use: pata_jmicron 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 03) Subsystem: Gigabyte Technology Co., Ltd Motherboard Kernel driver in use: r8169 06:00.0 Multimedia audio controller: Creative Labs SB Audigy (rev 04) Subsystem: Creative Labs SB Audigy 2 ZS (SB0350) Kernel driver in use: snd_emu10k1 06:00.1 Input device controller: Creative Labs SB Audigy Game Port (rev 04) Subsystem: Creative Labs SB Audigy Game Port Kernel driver in use: Emu10k1_gameport 06:00.2 FireWire (IEEE 1394): Creative Labs SB Audigy FireWire Port (rev 04) Subsystem: Creative Labs SB Audigy FireWire Port Kernel driver in use: firewire_ohci -- <not cent from sell> May the LORD God bless you exceedingly abundantly! Dave_Craig______________________________________________ "So the universe is not quite as you thought it was. You'd better rearrange your beliefs, then. Because you certainly can't rearrange the universe." __--from_Nightfall_by_Asimov/Silverberg_________________
Hi David, I don't understand the issue you are having. Are you having trouble booting the CRUX Media (ISO/USB) or having trouble installing CRUX itself on some hw? cheers James James Mills / prologic E: prologic@shortcircuit.net.au W: prologic.shortcircuit.net.au On Thu, Nov 20, 2014 at 11:05 AM, David L. Craig <dlc.usa@gmail.com> wrote:
I tried booting the USB-stick on my Acer Aspire 1 netbook and the installer decided the USB-stick was what it was looking for; i.e., no problem finding the CRUX media and getting to the root prompt.
Back on the Gigabyte desktop, it appears CRUX mdev creates /dev/sdh{,1,2} but any examination thereof is not reported.
This is what Debian Sid logged in /var/log/kern.log when the USB-stick was plugged in:
[ 76.296026] usb 3-2: new high-speed USB device number 3 using ehci-pci [ 76.439490] usb 3-2: New USB device found, idVendor=13fe, idProduct=1e23 [ 76.439676] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 76.439849] usb 3-2: Product: STORE N GO [ 76.440029] usb 3-2: Manufacturer: Verbatim [ 76.440250] usb 3-2: SerialNumber: 07951A09609608D5 [ 76.440915] usb-storage 3-2:1.0: USB Mass Storage device detected [ 76.441205] scsi11 : usb-storage 3-2:1.0 [ 77.485134] scsi 11:0:0:0: Direct-Access Verbatim STORE N GO 5.00 PQ: 0 ANSI: 0 CCS [ 77.485618] sd 11:0:0:0: Attached scsi generic sg8 type 0 [ 77.814504] sd 11:0:0:0: [sdh] 31272960 512-byte logical blocks: (16.0 GB/14.9 GiB) [ 77.815245] sd 11:0:0:0: [sdh] Write Protect is off [ 77.815403] sd 11:0:0:0: [sdh] Mode Sense: 23 00 00 00 [ 77.815998] sd 11:0:0:0: [sdh] No Caching mode page found [ 77.816163] sd 11:0:0:0: [sdh] Assuming drive cache: write through [ 77.863517] sdh: sdh1 sdh2 [ 77.866373] sd 11:0:0:0: [sdh] Attached SCSI removable disk
Below are lsusb and lspci -k command outputs, first in the recovery shell, then according to Debian Sid:
CRUX (typed from display):
Bus 002 Device 002: ID 13fe:1e23 Bus 002 Device 003: ID 058f:6362 Bus 001 Device 001: ID 1d6b:0002 Bus 002 Device 001: ID 1d6b:0002 Bus 003 Device 001: ID 1d6b:0001 Bus 004 Device 001: ID 1d6b:0001 Bus 005 Device 001: ID 1d6b:0001 Bus 006 Device 001: ID 1d6b:0001 Bus 007 Device 001: ID 1d6b:0001 Bus 008 Device 001: ID 1d6b:0001 Bus 009 Device 001: ID 1d6b:0002 Bus 010 Device 001: ID 1d6b:0003
00:00.0 Class 0600: 8086:2e20 00:01.0 Class 0604: 8086:2e21 pcieport 00:06.0 Class 0604: 8086:2e29 pcieport 00:1a.0 Class 0c03: 8086:3a37 uhci_hcd 00:1a.1 Class 0c03: 8086:3a38 uhci_hcd 00:1a.2 Class 0c03: 8086:3a39 uhci_hcd 00:1a.7 Class 0c03: 8086:3a3c ehci-pci 00:1c.0 Class 0604: 8086:3a40 pcieport 00:1c.3 Class 0604: 8086:3a46 pcieport 00:1c.4 Class 0604: 8086:3a48 pcieport 00:1d.0 Class 0c03: 8086:3a34 uhci_hcd 00:1d.1 Class 0c03: 8086:3a35 uhci_hcd 00:1d.2 Class 0c03: 8086:3a36 uhci_hcd 00:1d.7 Class 0c03: 8086:3a3a ehci-pci 00:1e.0 Class 0604: 8086:244e 00:1f.0 Class 0601: 8086:3a16 00:1f.2 Class 0106: 8086:3a22 ahci 00:1f.3 Class 0c05: 8086:3a30 01:00.0 Class 0300: 10de:0141 02:00.0 Class 0c03: 1033:0194 xhci_hcd 04:00.0 Class 0106: 197b:2363 ahci 04:00.1 Class 0101: 197b:2363 pata_jmicron 05:00.0 Class 0200: 10ec:8168 06:00.0 Class 0401: 1120:0004 06:00.1 Class 0980: 1120:7003 06:00.2 Class 0c00: 1120:4001 firewire_ohci
Sid:
Bus 003 Device 002: ID 058f:6362 Alcor Micro Corp. Flash Card Reader/Writer Bus 003 Device 003: ID 13fe:1e23 Kingston Technology Company Inc. Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 010 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 009 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
00:00.0 Host bridge: Intel Corporation 4 Series Chipset DRAM Controller (re v 03) Subsystem: Gigabyte Technology Co., Ltd GA-EP45-DS5/GA-EG45M-DS2H Motherboard 00:01.0 PCI bridge: Intel Corporation 4 Series Chipset PCI Express Root Port (rev 03) Kernel driver in use: pcieport 00:06.0 PCI bridge: Intel Corporation 4 Series Chipset PCI Express Root Port (rev 03) Kernel driver in use: pcieport 00:1a.0 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #4 Subsystem: Gigabyte Technology Co., Ltd Motherboard Kernel driver in use: uhci_hcd 00:1a.1 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #5 Subsystem: Gigabyte Technology Co., Ltd Motherboard Kernel driver in use: uhci_hcd 00:1a.2 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #6 Subsystem: Gigabyte Technology Co., Ltd Motherboard Kernel driver in use: uhci_hcd 00:1a.7 USB controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #2 Subsystem: Gigabyte Technology Co., Ltd Motherboard Kernel driver in use: ehci-pci 00:1c.0 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 1 Kernel driver in use: pcieport 00:1c.3 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 4 Kernel driver in use: pcieport 00:1c.4 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 5 Kernel driver in use: pcieport 00:1d.0 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #1 Subsystem: Gigabyte Technology Co., Ltd GA-EP45-DS5 Motherboard Kernel driver in use: uhci_hcd 00:1d.1 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #2 Subsystem: Gigabyte Technology Co., Ltd GA-EP45-DS5 Motherboard Kernel driver in use: uhci_hcd 00:1d.2 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #3 Subsystem: Gigabyte Technology Co., Ltd GA-EP45-DS5 Motherboard Kernel driver in use: uhci_hcd 00:1d.7 USB controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #1 Subsystem: Gigabyte Technology Co., Ltd GA-EP45-DS5 Motherboard Kernel driver in use: ehci-pci 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 90) 00:1f.0 ISA bridge: Intel Corporation 82801JIR (ICH10R) LPC Interface Controller Subsystem: Gigabyte Technology Co., Ltd GA-EP45-DS5 Motherboard Kernel driver in use: lpc_ich 00:1f.2 SATA controller: Intel Corporation 82801JI (ICH10 Family) SATA AHCI Controller Subsystem: Gigabyte Technology Co., Ltd GA-EP45-DS5/GA-EG45M-DS2H Motherboard Kernel driver in use: ahci 00:1f.3 SMBus: Intel Corporation 82801JI (ICH10 Family) SMBus Controller Subsystem: Gigabyte Technology Co., Ltd GA-EP45-DS5/GA-EG45M-DS2H Motherboard Kernel driver in use: i801_smbus 01:00.0 VGA compatible controller: NVIDIA Corporation NV43 [GeForce 6600] (rev a2) Subsystem: Device 196e:021f Kernel driver in use: nouveau 02:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03) Subsystem: Gigabyte Technology Co., Ltd Device 5007 Kernel driver in use: xhci_hcd 04:00.0 SATA controller: JMicron Technology Corp. JMB363 SATA/IDE Controller (rev 02) Subsystem: Gigabyte Technology Co., Ltd Motherboard Kernel driver in use: ahci 04:00.1 IDE interface: JMicron Technology Corp. JMB363 SATA/IDE Controller (rev 02) Subsystem: Gigabyte Technology Co., Ltd Motherboard Kernel driver in use: pata_jmicron 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 03) Subsystem: Gigabyte Technology Co., Ltd Motherboard Kernel driver in use: r8169 06:00.0 Multimedia audio controller: Creative Labs SB Audigy (rev 04) Subsystem: Creative Labs SB Audigy 2 ZS (SB0350) Kernel driver in use: snd_emu10k1 06:00.1 Input device controller: Creative Labs SB Audigy Game Port (rev 04) Subsystem: Creative Labs SB Audigy Game Port Kernel driver in use: Emu10k1_gameport 06:00.2 FireWire (IEEE 1394): Creative Labs SB Audigy FireWire Port (rev 04) Subsystem: Creative Labs SB Audigy FireWire Port Kernel driver in use: firewire_ohci -- <not cent from sell> May the LORD God bless you exceedingly abundantly!
Dave_Craig______________________________________________ "So the universe is not quite as you thought it was. You'd better rearrange your beliefs, then. Because you certainly can't rearrange the universe." __--from_Nightfall_by_Asimov/Silverberg_________________
_______________________________________________ CRUX mailing list CRUX@lists.crux.nu http://lists.crux.nu/mailman/listinfo/crux
On Wed, Nov 19, 2014 at 03:37:12PM -0500, David L. Craig wrote: Hello David,
It is not clear what criteria the installer uses to decide just what is a CRUX partition.
the installer tries to found the CRUX media by mounting all CDROM- and block devices and looks for a file named crux-media on it. Have a look at http://crux.nu/gitweb/?p=system/iso.git;a=blob;f=initramfs/init;h=771ec365b5... to see what happens. HTH Juergen
On 14Nov20:1134+0100, Juergen Daubert wrote:
the installer tries to found the CRUX media by mounting all CDROM- and block devices and looks for a file named crux-media on it.
Have a look at
http://crux.nu/gitweb/?p=system/iso.git;a=blob;f=initramfs/init;h=771ec365b5...
to see what happens.
So it appears that in lines 60 and 61, the USB-stick's block device is getting edited out of the candidates. I'll look into what the shell that gets spawned in line 93 sees and report back. Thanks for pointing me at the code involved. -- <not cent from sell> May the LORD God bless you exceedingly abundantly! Dave_Craig______________________________________________ "So the universe is not quite as you thought it was. You'd better rearrange your beliefs, then. Because you certainly can't rearrange the universe." __--from_Nightfall_by_Asimov/Silverberg_________________
On 14Nov20:0634-0500, David L. Craig wrote:
So it appears that in lines 60 and 61, the USB-stick's block device is getting edited out of the candidates. I'll look into what the shell that gets spawned in line 93 sees and report back. Thanks for pointing me at the code involved.
Well, sdh, sdh1, and sdh2 are clearly in /proc/partitions but /init isn't seeing them during the for loop at line 62. I tested with devicetimeout=30 and it still didn't see them. I also tested with root=/dev/sdh1 just to shake it up a little: the first time, the for loop found the CRUX media on /dev/sde (?!), but the second time it failed as before. I am able to successfully run "mount -vv -r /dev/sdh1 /.tmpfs/.media" in the recovery shell and get to the root prompt. If you could tell me how to edit /init before it gets started, I could insert some tracing to attempt to pinpoint the problem--I can't see how BLOCK_DEVICES can fail to contain the iso9660 filesystem's device node unless mdev is unstable at that time. -- <not cent from sell> May the LORD God bless you exceedingly abundantly! Dave_Craig______________________________________________ "So the universe is not quite as you thought it was. You'd better rearrange your beliefs, then. Because you certainly can't rearrange the universe." __--from_Nightfall_by_Asimov/Silverberg_________________
"David L. Craig" <dlc.usa@gmail.com> escribió:
On 14Nov20:0634-0500, David L. Craig wrote:
So it appears that in lines 60 and 61, the USB-stick's block device is getting edited out of the candidates. I'll look into what the shell that gets spawned in line 93 sees and report back. Thanks for pointing me at the code involved.
Well, sdh, sdh1, and sdh2 are clearly in /proc/partitions but /init isn't seeing them during the for loop at line 62. I tested with devicetimeout=30 and it still didn't see them. I also tested with root=/dev/sdh1 just to shake it up a little: the first time, the for loop found the CRUX media on /dev/sde (?!), but the second time it failed as before. I am able to successfully run "mount -vv -r /dev/sdh1 /.tmpfs/.media" in the recovery shell and get to the root prompt.
If you could tell me how to edit /init before it gets started, I could insert some tracing to attempt to pinpoint the problem--I can't see how BLOCK_DEVICES can fail to contain the iso9660 filesystem's device node unless mdev is unstable at that time. --
Boot with init=/bin/sh
On 14Nov20:2223+0900, Alan Mizrahi wrote:
Boot with init=/bin/sh
It doesn't work, and it probably isn't possible given the /bin symlinks aren't established until /init gets to line 130. init='/bin/busybox sh' might do it but the kernel doesn't seem to support that. -- <not cent from sell> May the LORD God bless you exceedingly abundantly! Dave_Craig______________________________________________ "So the universe is not quite as you thought it was. You'd better rearrange your beliefs, then. Because you certainly can't rearrange the universe." __--from_Nightfall_by_Asimov/Silverberg_________________
"David L. Craig" <dlc.usa@gmail.com> escribió:
On 14Nov20:2223+0900, Alan Mizrahi wrote:
Boot with init=/bin/sh
It doesn't work, and it probably isn't possible given the /bin symlinks aren't established until /init gets to line 130. init='/bin/busybox sh' might do it but the kernel doesn't seem to support that.
Ok, how about init=/bin/busybox then? By the way, these are our IRC channels: http://crux.nu/Main/IrcChannels I think you will get help faster there than in the mailing list.
On Thu, Nov 20, 2014 at 07:55:51AM -0500, David L. Craig wrote:
On 14Nov20:0634-0500, David L. Craig wrote:
So it appears that in lines 60 and 61, the USB-stick's block device is getting edited out of the candidates. I'll look into what the shell that gets spawned in line 93 sees and report back. Thanks for pointing me at the code involved.
Well, sdh, sdh1, and sdh2 are clearly in /proc/partitions but /init isn't seeing them during the for loop at line 62. I tested with devicetimeout=30 and it still didn't see them. I also tested with root=/dev/sdh1 just to shake it up a little: the first time, the for loop found the CRUX media on /dev/sde (?!), but the second time it failed as before. I am able to successfully run "mount -vv -r /dev/sdh1 /.tmpfs/.media" in the recovery shell and get to the root prompt.
Sorry, but what's the final problem? Which root prompt do you mean, the one from the recovery shell? If so just exit the recovery shell and init should continue. Btw, do not dd the ISO to a partition, use the device instead, something like dd if=crux-3.1.iso of=/dev/sdh Greetings Juergen
On 14Nov20:1843+0100, Juergen Daubert wrote:
On Thu, Nov 20, 2014 at 07:55:51AM -0500, David L. Craig wrote:
On 14Nov20:0634-0500, David L. Craig wrote:
So it appears that in lines 60 and 61, the USB-stick's block device is getting edited out of the candidates. I'll look into what the shell that gets spawned in line 93 sees and report back. Thanks for pointing me at the code involved.
Well, sdh, sdh1, and sdh2 are clearly in /proc/partitions but /init isn't seeing them during the for loop at line 62. I tested with devicetimeout=30 and it still didn't see them. I also tested with root=/dev/sdh1 just to shake it up a little: the first time, the for loop found the CRUX media on /dev/sde (?!), but the second time it failed as before. I am able to successfully run "mount -vv -r /dev/sdh1 /.tmpfs/.media" in the recovery shell and get to the root prompt.
Sorry, but what's the final problem?
On this Gigabyte desktop, it often fails to find the CRUX 3.1 USB-stick. I have no issues on my Acer Aspire 1 netbook. I suspect the race condition noted in the ISO-NOTES is part of this. The intermediate problem, getting a root prompt, is circumvented. The final problem is providing you with any additional diagnostic data you might be interested in; otherwise, I'll get back to installing CRUX on the Gigabyte box and deciding if I want to replace my Debian Sid primary platform with it. I was offering to run /init with some tracing logic added if I could figure out how to update the script before the kernel hands off the boot to PID 1. -- <not cent from sell> May the LORD God bless you exceedingly abundantly! Dave_Craig______________________________________________ "So the universe is not quite as you thought it was. You'd better rearrange your beliefs, then. Because you certainly can't rearrange the universe." __--from_Nightfall_by_Asimov/Silverberg_________________
Dave, Do you have multiple USB controllers on the Gigabyte desktop? Can you try USB 3 vs. USB 2, or even front vs. back USB ports? If you have another linux installation handy you can rebuild the initramfs on the installation media without too much trouble, though it's a bit tedious. That way you could add debugging stops or prints to the init script. I can provide some details on that tomorrow if needed. Matt
On 14Nov20:2259-0600, Matt Housh wrote:
Do you have multiple USB controllers on the Gigabyte desktop? Can you try USB 3 vs. USB 2, or even front vs. back USB ports?
Indeed, there are two 2.0 slots in the front section along the other common memory card and audio jacks, as well as six 2.0 and two 3.0 slots in the back mobo patch bay. I had only been using the two front slots. All eight in back were detected as /dev/sde without exceptions. The fourth message in this thread (Thu Nov 20 02:05 CET) contains the lsusb and lspci info for the box. I noticed when retesting the front slots again, for the first time when I got into the recovery subshell, /dev did not have the sdh* block nodes (which almost certainly explains why the for loop wasn't trying them). They showed up within a minute without any notification to the display.
If you have another linux installation handy you can rebuild the initramfs on the installation media without too much trouble, though it's a bit tedious. That way you could add debugging stops or prints to the init script.
I can provide some details on that tomorrow if needed.
I'd be happy to capture any data you think would be helpful to help make the installer more robust. I can use my Sid system if you'll give me the procedure to modify and rebuild the ISO--that's something I'd actually like to learn about. -- <not cent from sell> May the LORD God bless you exceedingly abundantly! Dave_Craig______________________________________________ "So the universe is not quite as you thought it was. You'd better rearrange your beliefs, then. Because you certainly can't rearrange the universe." __--from_Nightfall_by_Asimov/Silverberg_________________
On 11/21/2014 15:19, David L. Craig wrote:
I'd be happy to capture any data you think would be helpful to help make the installer more robust. I can use my Sid system if you'll give me the procedure to modify and rebuild the ISO--that's something I'd actually like to learn about.
Dave, Nothing specific I had in mind but if you find anything indicating why the devices take so long to appear then please share. As far as disassembling and reassembling the initramfs, you can do it like so: $ mkdir work; cd work $ cpio -idmv < /path/to/initramfs That will extract the initramfs to the "work" dir. You'll see bin, dev, init, lib, proc, and sys there. "init" is the init script, you can edit it to add whatever break points or output you like, just keep in mind that what it has access to is defined by the included busybox. If you want to build a more featureful busybox for debugging you can replace the one in the initramfs. To reassemble it after making changes: $ cd work $ find . | cpio -o -H newc > ../initramfs.new Then initramfs.new is your new initramfs image for testing. Hope that helps. Matt
participants (5)
-
Alan Mizrahi -
David L. Craig -
James Mills -
Juergen Daubert -
Matt Housh