Problem: UUIDs not being used everywhere for disks in stretch

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem: UUIDs not being used everywhere for disks in stretch

Steve McIntyre
Hey folks,

Leif (in CC) pointed this out to me after he did a fresh Stretch
installation over the weekend. I've just verified the problem
myself. Our initial thought was that this might be specific to
installations onto NVME, but I've tested and it's not, it's generic.

Right at the end of a simple installation to a single disk device,
when we run grub-installer, the generated grub.cfg is using
root=/dev/XXXX for the kernel command line rather than what it should
be (root=UUID=YYYY). This bug has managed to slip through our
installation testing as the resulting system will still boot fine for
simple single-disk cases...

I've compared this to a jessie installation using the same setup, and
that did the right thing (i.e. the final grub.cfg used
root=UUID=YYYY).  I've spent some time tracking down what's going on,
and I can see the *first* level of problem at least.

In grub-mkconfig, it looks for entries in /dev/disk/by-uuid/ to match
the UUID for /. If it can't find one, it falls back to using the
direct /dev/ disk device for the rootfs. Checking back, I can see:

 * in jessie, the entries in /dev/disk/by-uuid/ are refreshed after
   we're finished in partman

 * in stretch, they are not. You can see this most obviously - start
   with a blank disk and the only entry that will show up in there
   throughout the installation is for the installation medium

Does anybody have any insights as to how this might have
changed/broken? I'm too tired to dig much further tonight, but I'll
carry on looking tomorrow.

*Finally* - this is not a critical problem in the long run AFAICS. As
soon as people update their grub.cfg in their new system (so a new
kernel, or a new grub, or new versions of various other packages),
the installed system should generate a fixed UUID-style grub.cfg.

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
< Aardvark> I dislike C++ to start with. C++11 just seems to be
            handing rope-creating factories for users to hang multiple
            instances of themselves.

Reply | Threaded
Open this post in threaded view
|

re: Problem: UUIDs not being used everywhere for disks in stretch

Vincent McIntyre-4
We noticed this issue today and there is a further aspect to it.
I won't have time to make a proper bug report for a couple of days.

The initrd path that was given to the pxe netboot installer
gets included in the boot command line, to wit:

   GRUB_CMDLINE_LINUX="initrd=::debian/stretch/amd64/debian-installer/amd64/initrd.gz"

so we ended up with

$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.9.0-3-amd64 root=/dev/sdc1 ro quiet initrd=::debian/stretch/amd64/debian-installer/amd64/initrd.gz

This was for a machine with no NVMe device, just an internal SSD.
During installation the ssd was enumerated as /dev/sdc.
After installation it gets enumerated as /dev/sda.
The other /dev/sdX devices seem to be usb devices in the monitor,
I've attached the hardware-summary.

See also #865473, which may be related.

Best wishes
Vince

Reply | Threaded
Open this post in threaded view
|

Re: Problem: UUIDs not being used everywhere for disks in stretch

Vincent McIntyre-4
the promised attachment, inline

uname -a: Linux testbox 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Skylake Host Bridge/DRAM Registers [8086:191f] (rev 07)
lspci -knn: Subsystem: Dell Device [1028:06b9]
lspci -knn: 00:01.0 PCI bridge [0604]: Intel Corporation Skylake PCIe Controller (x16) [8086:1901] (rev 07)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 [8086:1912] (rev 06)
lspci -knn: Subsystem: Dell Device [1028:06b9]
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-H USB 3.0 xHCI Controller [8086:a12f] (rev 31)
lspci -knn: Subsystem: Dell Device [1028:06b9]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:14.2 Signal processing controller [1180]: Intel Corporation Sunrise Point-H Thermal subsystem [8086:a131] (rev 31)
lspci -knn: Subsystem: Dell Device [1028:06b9]
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Sunrise Point-H CSME HECI #1 [8086:a13a] (rev 31)
lspci -knn: Subsystem: Dell Device [1028:06b9]
lspci -knn: 00:16.3 Serial controller [0700]: Intel Corporation Sunrise Point-H KT Redirection [8086:a13d] (rev 31)
lspci -knn: Subsystem: Dell Device [1028:06b9]
lspci -knn: Kernel driver in use: serial
lspci -knn: 00:17.0 SATA controller [0106]: Intel Corporation Sunrise Point-H SATA controller [AHCI mode] [8086:a102] (rev 31)
lspci -knn: Subsystem: Dell Device [1028:06b9]
lspci -knn: Kernel driver in use: ahci
lspci -knn: Kernel modules: ahci
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation Sunrise Point-H PCI Express Root Port #1 [8086:a110] (rev f1)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation Sunrise Point-H LPC Controller [8086:a146] (rev 31)
lspci -knn: Subsystem: Dell Device [1028:06b9]
lspci -knn: 00:1f.2 Memory controller [0580]: Intel Corporation Sunrise Point-H PMC [8086:a121] (rev 31)
lspci -knn: Subsystem: Dell Device [1028:06b9]
lspci -knn: 00:1f.3 Audio device [0403]: Intel Corporation Sunrise Point-H HD Audio [8086:a170] (rev 31)
lspci -knn: Subsystem: Dell Device [1028:06b9]
lspci -knn: 00:1f.4 SMBus [0c05]: Intel Corporation Sunrise Point-H SMBus [8086:a123] (rev 31)
lspci -knn: Subsystem: Dell Device [1028:06b9]
lspci -knn: 00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection (2) I219-LM [8086:15b7] (rev 31)
lspci -knn: Subsystem: Dell Device [1028:06b9]
lspci -knn: Kernel driver in use: e1000e
lspci -knn: Kernel modules: e1000e
lspci -knn: 01:00.0 PCI bridge [0604]: NVIDIA Corporation NF200 PCIe 2.0 switch for Quadro Plex S4 / Tesla S870 / Tesla S1070 / Tesla S2050 [10de:05be] (rev a3)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 02:00.0 PCI bridge [0604]: NVIDIA Corporation NF200 PCIe 2.0 switch for Quadro Plex S4 / Tesla S870 / Tesla S1070 / Tesla S2050 [10de:05be] (rev a3)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 02:02.0 PCI bridge [0604]: NVIDIA Corporation NF200 PCIe 2.0 switch for Quadro Plex S4 / Tesla S870 / Tesla S1070 / Tesla S2050 [10de:05be] (rev a3)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 03:00.0 3D controller [0302]: NVIDIA Corporation G98 [Quadro NVS 450] [10de:06fa] (rev a1)
lspci -knn: Subsystem: NVIDIA Corporation Device [10de:0619]
lspci -knn: 04:00.0 VGA compatible controller [0300]: NVIDIA Corporation G98 [Quadro NVS 450] [10de:06fa] (rev a1)
lspci -knn: Subsystem: NVIDIA Corporation Device [10de:0619]
lspci -knn: 05:00.0 PCI bridge [0604]: Texas Instruments XIO2001 PCI Express-to-PCI Bridge [104c:8240]
usb-list:
usb-list: Bus 01 Device 01: xHCI Host Controller [1d6b:0002]
usb-list:    Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 01
usb-list:    Manufacturer: Linux 4.9.0-3-amd64 xhci-hcd
usb-list:    Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list:
usb-list: Bus 01 Device 02: xHCI Host Controller [0424:2512]
usb-list:    Level 01 Parent 01 Port 03  Class 09(hub  ) Subclass 00 Protocol 01
usb-list:    Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list:
usb-list: Bus 01 Device 03: xHCI Host Controller [0424:2602]
usb-list:    Level 02 Parent 02 Port 00  Class 09(hub  ) Subclass 00 Protocol 02
usb-list:    Interface 00: Class 09(hub  ) Subclass 00 Protocol 02 Driver hub
usb-list:
usb-list: Bus 01 Device 05: Flash Card Reader [0424:2228]
usb-list:    Level 03 Parent 03 Port 00  Class 00(>ifc ) Subclass 00 Protocol 00
usb-list:    Manufacturer: Generic
usb-list:    Interface 00: Class 08(mstor) Subclass 06 Protocol 50 Driver usb-storage
usb-list:
usb-list: Bus 01 Device 06: USB Optical Mouse [0461:4d22]
usb-list:    Level 03 Parent 03 Port 01  Class 00(>ifc ) Subclass 00 Protocol 00
usb-list:    Interface 00: Class 03(HID  ) Subclass 01 Protocol 02 Driver usbhid
usb-list:
usb-list: Bus 01 Device 04: Dell USB Entry Keyboard [413c:2107]
usb-list:    Level 02 Parent 02 Port 01  Class 00(>ifc ) Subclass 00 Protocol 00
usb-list:    Manufacturer: Dell
usb-list:    Interface 00: Class 03(HID  ) Subclass 01 Protocol 01 Driver usbhid
usb-list:
usb-list: Bus 02 Device 01: xHCI Host Controller [1d6b:0003]
usb-list:    Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 03
usb-list:    Manufacturer: Linux 4.9.0-3-amd64 xhci-hcd
usb-list:    Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
lsmod: Module                  Size  Used by
lsmod: ufs                    73728  0
lsmod: qnx4                   16384  0
lsmod: hfsplus               102400  0
lsmod: hfs                    57344  0
lsmod: minix                  36864  0
lsmod: msdos                  20480  0
lsmod: fuse                   98304  0
lsmod: ntfs                  102400  0
lsmod: battery                20480  0
lsmod: dm_mod                118784  24
lsmod: md_mod                131072  0
lsmod: xfs                  1208320  1
lsmod: libcrc32c              16384  1 xfs
lsmod: jfs                   176128  0
lsmod: btrfs                1060864  0
lsmod: xor                    24576  1 btrfs
lsmod: raid6_pq              110592  1 btrfs
lsmod: vfat                   20480  0
lsmod: fat                    69632  2 msdos,vfat
lsmod: ext4                  585728  7
lsmod: crc16                  16384  1 ext4
lsmod: jbd2                  106496  1 ext4
lsmod: crc32c_generic         16384  16
lsmod: fscrypto               28672  1 ext4
lsmod: ecb                    16384  0
lsmod: mbcache                16384  8 ext4
lsmod: sr_mod                 24576  0
lsmod: cdrom                  61440  1 sr_mod
lsmod: ahci                   36864  2
lsmod: libahci                32768  1 ahci
lsmod: libata                249856  2 ahci,libahci
lsmod: sd_mod                 45056  3
lsmod: uas                    24576  0
lsmod: usb_storage            73728  1 uas
lsmod: scsi_mod              225280  5 sd_mod,usb_storage,libata,uas,sr_mod
lsmod: hid_generic            16384  0
lsmod: usbhid                 53248  0
lsmod: vga16fb                24576  2
lsmod: vgastate               20480  1 vga16fb
lsmod: xhci_pci               16384  0
lsmod: e1000e                245760  0
lsmod: xhci_hcd              188416  1 xhci_pci
lsmod: ptp                    20480  1 e1000e
lsmod: pps_core               16384  1 ptp
lsmod: usbcore               249856  5 usbhid,usb_storage,xhci_pci,uas,xhci_hcd
lsmod: usb_common             16384  1 usbcore
lsmod: fan                    16384  0
lsmod: thermal                20480  0
lsmod: i2c_hid                20480  0
lsmod: hid                   122880  3 i2c_hid,hid_generic,usbhid
df: Filesystem           1K-blocks      Used Available Use% Mounted on
df: none                   3281336        88   3281248   0% /run
df: devtmpfs              16392344         0  16392344   0% /dev
df: /dev/sdc1               967320    293564    607404  33% /target
df: /dev/mapper/install-data
df:                      161987300    194432 161792868   0% /target/data
df: /dev/mapper/install-local
df:                         967320      2444    898524   0% /target/local
df: /dev/mapper/install-opt
df:                        3869352     15608   3637476   0% /target/opt
df: /dev/mapper/install-tmp
df:                        1934672      5856   1812492   0% /target/tmp
df: /dev/mapper/install-usr
df:                        9775612    483052   8776260   5% /target/usr
df: /dev/mapper/install-var
df:                        3869352    154808   3498276   4% /target/var
df: /dev/mapper/install-var+log
df:                        1934672      7200   1811148   0% /target/var/log
df: /dev/sdc1               967320    293564    607404  33% /dev/.static/dev
df: devtmpfs              16392344         0  16392344   0% /target/dev
free:              total         used         free       shared      buffers
free: Mem:      32813352      1321728     31491624       132524        68104
free: -/+ buffers:            1253624     31559728
free: Swap:     63999996            0     63999996
/proc/cmdline: BOOT_IMAGE=::debian/stretch/amd64/debian-installer/amd64/linux auto=true priority=critical vga=normal url=http://10.12.13.14/./preseed/debian/stretch/stretch-test.cfg ---  initrd=::debian/stretch/amd64/debian-installer/amd64/initrd.gz
/proc/cpuinfo: processor : 0
/proc/cpuinfo: vendor_id : GenuineIntel
/proc/cpuinfo: cpu family : 6
/proc/cpuinfo: model : 94
/proc/cpuinfo: model name : Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
/proc/cpuinfo: stepping : 3
/proc/cpuinfo: microcode : 0x8a
/proc/cpuinfo: cpu MHz : 3700.073
/proc/cpuinfo: cache size : 8192 KB
/proc/cpuinfo: physical id : 0
/proc/cpuinfo: siblings : 8
/proc/cpuinfo: core id : 0
/proc/cpuinfo: cpu cores : 4
/proc/cpuinfo: apicid : 0
/proc/cpuinfo: initial apicid : 0
/proc/cpuinfo: fpu : yes
/proc/cpuinfo: fpu_exception : yes
/proc/cpuinfo: cpuid level : 22
/proc/cpuinfo: wp : yes
/proc/cpuinfo: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp
/proc/cpuinfo: bugs :
/proc/cpuinfo: bogomips : 6816.00
/proc/cpuinfo: clflush size : 64
/proc/cpuinfo: cache_alignment : 64
/proc/cpuinfo: address sizes : 39 bits physical, 48 bits virtual
/proc/cpuinfo: power management:
/proc/cpuinfo:
/proc/cpuinfo: processor : 1
/proc/cpuinfo: vendor_id : GenuineIntel
/proc/cpuinfo: cpu family : 6
/proc/cpuinfo: model : 94
/proc/cpuinfo: model name : Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
/proc/cpuinfo: stepping : 3
/proc/cpuinfo: microcode : 0x8a
/proc/cpuinfo: cpu MHz : 3700.073
/proc/cpuinfo: cache size : 8192 KB
/proc/cpuinfo: physical id : 0
/proc/cpuinfo: siblings : 8
/proc/cpuinfo: core id : 1
/proc/cpuinfo: cpu cores : 4
/proc/cpuinfo: apicid : 2
/proc/cpuinfo: initial apicid : 2
/proc/cpuinfo: fpu : yes
/proc/cpuinfo: fpu_exception : yes
/proc/cpuinfo: cpuid level : 22
/proc/cpuinfo: wp : yes
/proc/cpuinfo: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp
/proc/cpuinfo: bugs :
/proc/cpuinfo: bogomips : 6817.01
/proc/cpuinfo: clflush size : 64
/proc/cpuinfo: cache_alignment : 64
/proc/cpuinfo: address sizes : 39 bits physical, 48 bits virtual
/proc/cpuinfo: power management:
/proc/cpuinfo:
/proc/cpuinfo: processor : 2
/proc/cpuinfo: vendor_id : GenuineIntel
/proc/cpuinfo: cpu family : 6
/proc/cpuinfo: model : 94
/proc/cpuinfo: model name : Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
/proc/cpuinfo: stepping : 3
/proc/cpuinfo: microcode : 0x8a
/proc/cpuinfo: cpu MHz : 3699.865
/proc/cpuinfo: cache size : 8192 KB
/proc/cpuinfo: physical id : 0
/proc/cpuinfo: siblings : 8
/proc/cpuinfo: core id : 2
/proc/cpuinfo: cpu cores : 4
/proc/cpuinfo: apicid : 4
/proc/cpuinfo: initial apicid : 4
/proc/cpuinfo: fpu : yes
/proc/cpuinfo: fpu_exception : yes
/proc/cpuinfo: cpuid level : 22
/proc/cpuinfo: wp : yes
/proc/cpuinfo: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp
/proc/cpuinfo: bugs :
/proc/cpuinfo: bogomips : 6817.05
/proc/cpuinfo: clflush size : 64
/proc/cpuinfo: cache_alignment : 64
/proc/cpuinfo: address sizes : 39 bits physical, 48 bits virtual
/proc/cpuinfo: power management:
/proc/cpuinfo:
/proc/cpuinfo: processor : 3
/proc/cpuinfo: vendor_id : GenuineIntel
/proc/cpuinfo: cpu family : 6
/proc/cpuinfo: model : 94
/proc/cpuinfo: model name : Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
/proc/cpuinfo: stepping : 3
/proc/cpuinfo: microcode : 0x8a
/proc/cpuinfo: cpu MHz : 3699.865
/proc/cpuinfo: cache size : 8192 KB
/proc/cpuinfo: physical id : 0
/proc/cpuinfo: siblings : 8
/proc/cpuinfo: core id : 3
/proc/cpuinfo: cpu cores : 4
/proc/cpuinfo: apicid : 6
/proc/cpuinfo: initial apicid : 6
/proc/cpuinfo: fpu : yes
/proc/cpuinfo: fpu_exception : yes
/proc/cpuinfo: cpuid level : 22
/proc/cpuinfo: wp : yes
/proc/cpuinfo: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp
/proc/cpuinfo: bugs :
/proc/cpuinfo: bogomips : 6817.07
/proc/cpuinfo: clflush size : 64
/proc/cpuinfo: cache_alignment : 64
/proc/cpuinfo: address sizes : 39 bits physical, 48 bits virtual
/proc/cpuinfo: power management:
/proc/cpuinfo:
/proc/cpuinfo: processor : 4
/proc/cpuinfo: vendor_id : GenuineIntel
/proc/cpuinfo: cpu family : 6
/proc/cpuinfo: model : 94
/proc/cpuinfo: model name : Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
/proc/cpuinfo: stepping : 3
/proc/cpuinfo: microcode : 0x8a
/proc/cpuinfo: cpu MHz : 3700.073
/proc/cpuinfo: cache size : 8192 KB
/proc/cpuinfo: physical id : 0
/proc/cpuinfo: siblings : 8
/proc/cpuinfo: core id : 0
/proc/cpuinfo: cpu cores : 4
/proc/cpuinfo: apicid : 1
/proc/cpuinfo: initial apicid : 1
/proc/cpuinfo: fpu : yes
/proc/cpuinfo: fpu_exception : yes
/proc/cpuinfo: cpuid level : 22
/proc/cpuinfo: wp : yes
/proc/cpuinfo: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp
/proc/cpuinfo: bugs :
/proc/cpuinfo: bogomips : 6817.30
/proc/cpuinfo: clflush size : 64
/proc/cpuinfo: cache_alignment : 64
/proc/cpuinfo: address sizes : 39 bits physical, 48 bits virtual
/proc/cpuinfo: power management:
/proc/cpuinfo:
/proc/cpuinfo: processor : 5
/proc/cpuinfo: vendor_id : GenuineIntel
/proc/cpuinfo: cpu family : 6
/proc/cpuinfo: model : 94
/proc/cpuinfo: model name : Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
/proc/cpuinfo: stepping : 3
/proc/cpuinfo: microcode : 0x8a
/proc/cpuinfo: cpu MHz : 3700.280
/proc/cpuinfo: cache size : 8192 KB
/proc/cpuinfo: physical id : 0
/proc/cpuinfo: siblings : 8
/proc/cpuinfo: core id : 1
/proc/cpuinfo: cpu cores : 4
/proc/cpuinfo: apicid : 3
/proc/cpuinfo: initial apicid : 3
/proc/cpuinfo: fpu : yes
/proc/cpuinfo: fpu_exception : yes
/proc/cpuinfo: cpuid level : 22
/proc/cpuinfo: wp : yes
/proc/cpuinfo: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp
/proc/cpuinfo: bugs :
/proc/cpuinfo: bogomips : 6817.10
/proc/cpuinfo: clflush size : 64
/proc/cpuinfo: cache_alignment : 64
/proc/cpuinfo: address sizes : 39 bits physical, 48 bits virtual
/proc/cpuinfo: power management:
/proc/cpuinfo:
/proc/cpuinfo: processor : 6
/proc/cpuinfo: vendor_id : GenuineIntel
/proc/cpuinfo: cpu family : 6
/proc/cpuinfo: model : 94
/proc/cpuinfo: model name : Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
/proc/cpuinfo: stepping : 3
/proc/cpuinfo: microcode : 0x8a
/proc/cpuinfo: cpu MHz : 3699.865
/proc/cpuinfo: cache size : 8192 KB
/proc/cpuinfo: physical id : 0
/proc/cpuinfo: siblings : 8
/proc/cpuinfo: core id : 2
/proc/cpuinfo: cpu cores : 4
/proc/cpuinfo: apicid : 5
/proc/cpuinfo: initial apicid : 5
/proc/cpuinfo: fpu : yes
/proc/cpuinfo: fpu_exception : yes
/proc/cpuinfo: cpuid level : 22
/proc/cpuinfo: wp : yes
/proc/cpuinfo: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp
/proc/cpuinfo: bugs :
/proc/cpuinfo: bogomips : 6817.05
/proc/cpuinfo: clflush size : 64
/proc/cpuinfo: cache_alignment : 64
/proc/cpuinfo: address sizes : 39 bits physical, 48 bits virtual
/proc/cpuinfo: power management:
/proc/cpuinfo:
/proc/cpuinfo: processor : 7
/proc/cpuinfo: vendor_id : GenuineIntel
/proc/cpuinfo: cpu family : 6
/proc/cpuinfo: model : 94
/proc/cpuinfo: model name : Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
/proc/cpuinfo: stepping : 3
/proc/cpuinfo: microcode : 0x8a
/proc/cpuinfo: cpu MHz : 3700.488
/proc/cpuinfo: cache size : 8192 KB
/proc/cpuinfo: physical id : 0
/proc/cpuinfo: siblings : 8
/proc/cpuinfo: core id : 3
/proc/cpuinfo: cpu cores : 4
/proc/cpuinfo: apicid : 7
/proc/cpuinfo: initial apicid : 7
/proc/cpuinfo: fpu : yes
/proc/cpuinfo: fpu_exception : yes
/proc/cpuinfo: cpuid level : 22
/proc/cpuinfo: wp : yes
/proc/cpuinfo: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp
/proc/cpuinfo: bugs :
/proc/cpuinfo: bogomips : 6817.05
/proc/cpuinfo: clflush size : 64
/proc/cpuinfo: cache_alignment : 64
/proc/cpuinfo: address sizes : 39 bits physical, 48 bits virtual
/proc/cpuinfo: power management:
/proc/cpuinfo:
/proc/ioports: 0000-0cf7 : PCI Bus 0000:00
/proc/ioports:   0000-001f : dma1
/proc/ioports:   0020-0021 : pic1
/proc/ioports:   0040-0043 : timer0
/proc/ioports:   0050-0053 : timer1
/proc/ioports:   0060-0060 : keyboard
/proc/ioports:   0064-0064 : keyboard
/proc/ioports:   0070-0077 : rtc0
/proc/ioports:   0080-008f : dma page reg
/proc/ioports:   00a0-00a1 : pic2
/proc/ioports:   00c0-00df : dma2
/proc/ioports:   00f0-00ff : fpu
/proc/ioports:     00f0-00f0 : PNP0C04:00
/proc/ioports:   03c0-03df : vga+
/proc/ioports:   03f8-03ff : serial
/proc/ioports:   0680-069f : pnp 00:04
/proc/ioports:   0800-087f : pnp 00:05
/proc/ioports:   0a00-0a3f : pnp 00:00
/proc/ioports:   0a40-0a7f : pnp 00:00
/proc/ioports: 0cf8-0cff : PCI conf1
/proc/ioports: 0d00-ffff : PCI Bus 0000:00
/proc/ioports:   164e-164f : pnp 00:04
/proc/ioports:   1800-18fe : pnp 00:04
/proc/ioports:     1800-1803 : ACPI PM1a_EVT_BLK
/proc/ioports:     1804-1805 : ACPI PM1a_CNT_BLK
/proc/ioports:     1808-180b : ACPI PM_TMR
/proc/ioports:     1850-1850 : ACPI PM2_CNT_BLK
/proc/ioports:     1854-1857 : pnp 00:07
/proc/ioports:     1880-189f : ACPI GPE0_BLK
/proc/ioports:   d000-efff : PCI Bus 0000:01
/proc/ioports:     d000-efff : PCI Bus 0000:02
/proc/ioports:       d000-dfff : PCI Bus 0000:04
/proc/ioports:         d000-d07f : 0000:04:00.0
/proc/ioports:       e000-efff : PCI Bus 0000:03
/proc/ioports:         e000-e07f : 0000:03:00.0
/proc/ioports:   f000-f03f : 0000:00:02.0
/proc/ioports:   f040-f05f : 0000:00:1f.4
/proc/ioports:   f060-f07f : 0000:00:17.0
/proc/ioports:     f060-f07f : ahci
/proc/ioports:   f080-f083 : 0000:00:17.0
/proc/ioports:     f080-f083 : ahci
/proc/ioports:   f090-f097 : 0000:00:17.0
/proc/ioports:     f090-f097 : ahci
/proc/ioports:   f0a0-f0a7 : 0000:00:16.3
/proc/ioports:     f0a0-f0a7 : serial
/proc/ioports:   ff00-fffe : pnp 00:0a
/proc/ioports:   ffff-ffff : pnp 00:04
/proc/ioports:     ffff-ffff : pnp 00:04
/proc/ioports:       ffff-ffff : pnp 00:04
/proc/iomem: 00000000-00000fff : reserved
/proc/iomem: 00001000-0009c7ff : System RAM
/proc/iomem: 0009c800-0009ffff : reserved
/proc/iomem: 000a0000-000bffff : PCI Bus 0000:00
/proc/iomem: 000c0000-000cffff : Video ROM
/proc/iomem: 000d0000-000d0fff : Adapter ROM
/proc/iomem: 000d1000-000d1fff : Adapter ROM
/proc/iomem: 000e0000-000fffff : reserved
/proc/iomem:   000f0000-000fffff : System ROM
/proc/iomem: 00100000-bc659fff : System RAM
/proc/iomem: bc65a000-bc65afff : ACPI Non-volatile Storage
/proc/iomem: bc65b000-bc6a4fff : reserved
/proc/iomem: bc6a5000-bc6fafff : System RAM
/proc/iomem: bc6fb000-bcefbfff : reserved
/proc/iomem: bcefc000-ca157fff : System RAM
/proc/iomem: ca158000-cb7b0fff : reserved
/proc/iomem: cb7b1000-cb800fff : ACPI Tables
/proc/iomem: cb801000-cbfbafff : ACPI Non-volatile Storage
/proc/iomem: cbfbb000-cc4fefff : reserved
/proc/iomem: cc4ff000-cc4fffff : System RAM
/proc/iomem: cc500000-cc5fffff : reserved
/proc/iomem: cc600000-cdffffff : RAM buffer
/proc/iomem: ce000000-cfffffff : reserved
/proc/iomem: d0000000-f7ffffff : PCI Bus 0000:00
/proc/iomem:   d0000000-dfffffff : 0000:00:02.0
/proc/iomem:   e0000000-e7ffffff : PCI Bus 0000:01
/proc/iomem:     e0000000-e7ffffff : PCI Bus 0000:02
/proc/iomem:       e0000000-e3ffffff : PCI Bus 0000:04
/proc/iomem:         e0000000-e3ffffff : 0000:04:00.0
/proc/iomem:       e4000000-e7ffffff : PCI Bus 0000:03
/proc/iomem:         e4000000-e7ffffff : 0000:03:00.0
/proc/iomem:   ee000000-f50fffff : PCI Bus 0000:01
/proc/iomem:     ee000000-f50fffff : PCI Bus 0000:02
/proc/iomem:       ee000000-f10fffff : PCI Bus 0000:04
/proc/iomem:         ee000000-efffffff : 0000:04:00.0
/proc/iomem:         f0000000-f0ffffff : 0000:04:00.0
/proc/iomem:         f1000000-f101ffff : 0000:04:00.0
/proc/iomem:       f2000000-f50fffff : PCI Bus 0000:03
/proc/iomem:         f2000000-f3ffffff : 0000:03:00.0
/proc/iomem:         f4000000-f4ffffff : 0000:03:00.0
/proc/iomem:         f5000000-f501ffff : 0000:03:00.0
/proc/iomem:   f6000000-f6ffffff : 0000:00:02.0
/proc/iomem:   f7000000-f701ffff : 0000:00:1f.6
/proc/iomem:     f7000000-f701ffff : e1000e
/proc/iomem:   f7020000-f702ffff : 0000:00:1f.3
/proc/iomem:   f7030000-f703ffff : 0000:00:14.0
/proc/iomem:     f7030000-f703ffff : xhci-hcd
/proc/iomem:   f7040000-f7043fff : 0000:00:1f.3
/proc/iomem:   f7044000-f7047fff : 0000:00:1f.2
/proc/iomem:   f7048000-f7049fff : 0000:00:17.0
/proc/iomem:     f7048000-f7049fff : ahci
/proc/iomem:   f704a000-f704a0ff : 0000:00:1f.4
/proc/iomem:   f704b000-f704b7ff : 0000:00:17.0
/proc/iomem:     f704b000-f704b7ff : ahci
/proc/iomem:   f704c000-f704c0ff : 0000:00:17.0
/proc/iomem:     f704c000-f704c0ff : ahci
/proc/iomem:   f704d000-f704dfff : 0000:00:16.3
/proc/iomem:   f704e000-f704efff : 0000:00:16.0
/proc/iomem:   f704f000-f704ffff : 0000:00:14.2
/proc/iomem:   f7fe0000-f7ffffff : pnp 00:08
/proc/iomem: f8000000-fbffffff : PCI MMCONFIG 0000 [bus 00-3f]
/proc/iomem:   f8000000-fbffffff : reserved
/proc/iomem:     f8000000-fbffffff : pnp 00:08
/proc/iomem: fd000000-fe7fffff : PCI Bus 0000:00
/proc/iomem:   fd000000-fdabffff : pnp 00:09
/proc/iomem:   fdac0000-fdacffff : pnp 00:0b
/proc/iomem:   fdad0000-fdadffff : pnp 00:09
/proc/iomem:   fdae0000-fdaeffff : pnp 00:0b
/proc/iomem:   fdaf0000-fdafffff : pnp 00:0b
/proc/iomem:   fdb00000-fdffffff : pnp 00:09
/proc/iomem:   fe000000-fe010fff : reserved
/proc/iomem:   fe036000-fe03bfff : pnp 00:09
/proc/iomem:   fe03d000-fe3fffff : pnp 00:09
/proc/iomem:   fe410000-fe7fffff : pnp 00:09
/proc/iomem: fec00000-fec00fff : reserved
/proc/iomem:   fec00000-fec003ff : IOAPIC 0
/proc/iomem: fed00000-fed003ff : HPET 0
/proc/iomem:   fed00000-fed003ff : PNP0103:00
/proc/iomem: fed10000-fed17fff : pnp 00:08
/proc/iomem: fed18000-fed18fff : pnp 00:08
/proc/iomem: fed19000-fed19fff : pnp 00:08
/proc/iomem: fed20000-fed3ffff : pnp 00:08
/proc/iomem: fed45000-fed8ffff : pnp 00:08
/proc/iomem: fed90000-fed90fff : dmar0
/proc/iomem: fed91000-fed91fff : dmar1
/proc/iomem: fee00000-fee00fff : Local APIC
/proc/iomem:   fee00000-fee00fff : reserved
/proc/iomem: ff000000-ffffffff : reserved
/proc/iomem:   ff000000-ffffffff : INT0800:00
/proc/iomem:     ff000000-ffffffff : pnp 00:08
/proc/iomem: 100000000-82dffffff : System RAM
/proc/iomem:   62ce00000-62d40b1e1 : Kernel code
/proc/iomem:   62d40b1e2-62db1c53f : Kernel data
/proc/iomem:   62dc81000-62dd2cfff : Kernel bss
/proc/iomem: 82e000000-82fffffff : RAM buffer
/proc/interrupts:             CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7      
/proc/interrupts:    0:         24          0          0          0          0          0          0          0  IR-IO-APIC    2-edge      timer
/proc/interrupts:    1:          0          0          0          1          1          0          0          0  IR-IO-APIC    1-edge      i8042
/proc/interrupts:    8:         14          0          1          0          1          0          0          0  IR-IO-APIC    8-edge      rtc0
/proc/interrupts:    9:          0          0          0          0          0          0          0          0  IR-IO-APIC    9-fasteoi   acpi
/proc/interrupts:   12:          1          0          0          0          1          1          0          0  IR-IO-APIC   12-edge      i8042
/proc/interrupts:  120:          0          0          0          0          0          0          0          0  DMAR-MSI    0-edge      dmar0
/proc/interrupts:  121:          0          0          0          0          0          0          0          0  DMAR-MSI    1-edge      dmar1
/proc/interrupts:  123:       1228        228        143        146        245        209        167        143  IR-PCI-MSI 327680-edge      xhci_hcd
/proc/interrupts:  124:      25383       2483       1741       1972       8049       1913       1372        985  IR-PCI-MSI 520192-edge      enp0s31f6
/proc/interrupts:  125:      34350       9598       6968       4670      10178       9950       6414       4032  IR-PCI-MSI 376832-edge      ahci[0000:00:17.0]
/proc/interrupts:  NMI:          1          1          1          2          2          1          1          1   Non-maskable interrupts
/proc/interrupts:  LOC:      57712      36637      35483      34559      37771      34850      35046      33947   Local timer interrupts
/proc/interrupts:  SPU:          0          0          0          0          0          0          0          0   Spurious interrupts
/proc/interrupts:  PMI:          1          1          1          2          2          1          1          1   Performance monitoring interrupts
/proc/interrupts:  IWI:          1          0          0          0          1          0          0          0   IRQ work interrupts
/proc/interrupts:  RTR:          0          0          0          0          0          0          0          0   APIC ICR read retries
/proc/interrupts:  RES:       4014       2448       1658       1198       1185       1028        946        898   Rescheduling interrupts
/proc/interrupts:  CAL:        771        795        803        880        843        815        854        866   Function call interrupts
/proc/interrupts:  TLB:        178        195        219        161        183        123        156        183   TLB shootdowns
/proc/interrupts:  TRM:          0          0          0          0          0          0          0          0   Thermal event interrupts
/proc/interrupts:  THR:          0          0          0          0          0          0          0          0   Threshold APIC interrupts
/proc/interrupts:  DFR:          0          0          0          0          0          0          0          0   Deferred Error APIC interrupts
/proc/interrupts:  MCE:          0          0          0          0          0          0          0          0   Machine check exceptions
/proc/interrupts:  MCP:          4          4          4          4          4          4          4          4   Machine check polls
/proc/interrupts:  ERR:         14
/proc/interrupts:  MIS:          0
/proc/interrupts:  PIN:          0          0          0          0          0          0          0          0   Posted-interrupt notification event
/proc/interrupts:  PIW:          0          0          0          0          0          0          0          0   Posted-interrupt wakeup event
/proc/meminfo: MemTotal:       32813352 kB
/proc/meminfo: MemFree:        31491376 kB
/proc/meminfo: MemAvailable:   32113404 kB
/proc/meminfo: Buffers:           68104 kB
/proc/meminfo: Cached:           997828 kB
/proc/meminfo: SwapCached:            0 kB
/proc/meminfo: Active:           353844 kB
/proc/meminfo: Inactive:         734572 kB
/proc/meminfo: Active(anon):     100472 kB
/proc/meminfo: Inactive(anon):    54508 kB
/proc/meminfo: Active(file):     253372 kB
/proc/meminfo: Inactive(file):   680064 kB
/proc/meminfo: Unevictable:           0 kB
/proc/meminfo: Mlocked:               0 kB
/proc/meminfo: SwapTotal:      63999996 kB
/proc/meminfo: SwapFree:       63999996 kB
/proc/meminfo: Dirty:              1424 kB
/proc/meminfo: Writeback:             0 kB
/proc/meminfo: AnonPages:         22568 kB
/proc/meminfo: Mapped:             4620 kB
/proc/meminfo: Shmem:            132524 kB
/proc/meminfo: Slab:             131372 kB
/proc/meminfo: SReclaimable:     106892 kB
/proc/meminfo: SUnreclaim:        24480 kB
/proc/meminfo: KernelStack:        2992 kB
/proc/meminfo: PageTables:          716 kB
/proc/meminfo: NFS_Unstable:          0 kB
/proc/meminfo: Bounce:                0 kB
/proc/meminfo: WritebackTmp:          0 kB
/proc/meminfo: CommitLimit:    80406672 kB
/proc/meminfo: Committed_AS:     163400 kB
/proc/meminfo: VmallocTotal:   34359738367 kB
/proc/meminfo: VmallocUsed:           0 kB
/proc/meminfo: VmallocChunk:          0 kB
/proc/meminfo: HardwareCorrupted:     0 kB
/proc/meminfo: AnonHugePages:         0 kB
/proc/meminfo: ShmemHugePages:        0 kB
/proc/meminfo: ShmemPmdMapped:        0 kB
/proc/meminfo: HugePages_Total:       0
/proc/meminfo: HugePages_Free:        0
/proc/meminfo: HugePages_Rsvd:        0
/proc/meminfo: HugePages_Surp:        0
/proc/meminfo: Hugepagesize:       2048 kB
/proc/meminfo: DirectMap4k:       78900 kB
/proc/meminfo: DirectMap2M:     5025792 kB
/proc/meminfo: DirectMap1G:    28311552 kB
/proc/bus/input/devices: I: Bus=0003 Vendor=413c Product=2107 Version=0110
/proc/bus/input/devices: N: Name="Dell Dell USB Entry Keyboard"
/proc/bus/input/devices: P: Phys=usb-0000:00:14.0-4.2/input0
/proc/bus/input/devices: S: Sysfs=/devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4.2/1-4.2:1.0/0003:413C:2107.0001/input/input2
/proc/bus/input/devices: U: Uniq=
/proc/bus/input/devices: H: Handlers=sysrq kbd leds
/proc/bus/input/devices: B: PROP=0
/proc/bus/input/devices: B: EV=120013
/proc/bus/input/devices: B: KEY=1000000000007 ff9f207ac14057ff febeffdfffefffff fffffffffffffffe
/proc/bus/input/devices: B: MSC=10
/proc/bus/input/devices: B: LED=7
/proc/bus/input/devices:
/proc/bus/input/devices: I: Bus=0003 Vendor=0461 Product=4d22 Version=0111
/proc/bus/input/devices: N: Name="USB Optical Mouse"
/proc/bus/input/devices: P: Phys=usb-0000:00:14.0-4.1.2/input0
/proc/bus/input/devices: S: Sysfs=/devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4.1/1-4.1.2/1-4.1.2:1.0/0003:0461:4D22.0002/input/input3
/proc/bus/input/devices: U: Uniq=
/proc/bus/input/devices: H: Handlers=mouse0
/proc/bus/input/devices: B: PROP=0
/proc/bus/input/devices: B: EV=17
/proc/bus/input/devices: B: KEY=70000 0 0 0 0
/proc/bus/input/devices: B: REL=103
/proc/bus/input/devices: B: MSC=10
/proc/bus/input/devices:

Reply | Threaded
Open this post in threaded view
|

Re: Problem: UUIDs not being used everywhere for disks in stretch

Vincent McIntyre-4
On Fri, Jul 28, 2017 at 12:28:58PM +1000, Vincent McIntyre wrote:
> the promised attachment, inline

A perusal of the syslog turned up this


A perusal of the syslog turned up this

Jul 28 01:27:32 grub-installer: info: Installing grub on '/dev/sdc'
Jul 28 01:27:32 grub-installer: info: grub-install does not support --no-floppy
Jul 28 01:27:32 grub-installer: info: Running chroot /target grub-install  --force "/dev/sdc"
Jul 28 01:27:32 grub-installer: Installing for i386-pc platform.
Jul 28 01:27:33 grub-installer: Installation finished. No error reported.
Jul 28 01:27:33 grub-installer: info: grub-install ran successfully


In our case, the installer prompted us for the grub device to
install to. We entered /dev/sdc.
However we did not explicitly set the root partition anywhere;
something set it to /dev/sdc1 instead of a UUID= string.

Vince

Reply | Threaded
Open this post in threaded view
|

Re: Problem: UUIDs not being used everywhere for disks in stretch

Vincent McIntyre-4
A discussion with Steve suggested looking at when udev updates
/dev/disk/by-uuid - has something changed that stops that directory
being refreshed after partman-base is done (or at least before
bootstrap-base starts)?


I ran some stretch/jessie comparison installs on the following VM system:
  amd64, 1cpu, 1G memory
  sata port 0 - 2G ssd
  sata port 1 - 64M hot-pluggable device
  sata port 2 - 128G hard disk
  netinst preseeded install

None of the disk devices have partition tables at the start.
The partitioning recipe is:
  1 real partition of size 1G for /
  1 real partition of size 127G for an LVM physical volume
  containing all the other partitions.

(It's important to make sure the hard disk is large enough for
 the expert recipe to fit; otherwise the installer defaults to
  1 real partition for /boot
  1 lvm volume named 'root' for everything else
)

What seems to happen on stretch is /dev/disk/by-uuid NEVER EXISTS
during installation in this circumstance. I did see it in other
installation paths I tried.

Right after all the partitioning is complete and debootstrap
is running, /dev/sd* and /dev/disk looks like this:

# ls -l /dev/sd* /dev/disk /dev/disk/by-uuid 2>/dev/null
brw-------    1 root     root        8,   0 Aug  4 07:08 /dev/sda
brw-------    1 root     root        8,  16 Aug  4 07:08 /dev/sdb
brw-------    1 root     root        8,  32 Aug  4 07:08 /dev/sdc
brw-------    1 root     root        8,  33 Aug  4 07:08 /dev/sdc1
brw-------    1 root     root        8,  34 Aug  4 07:08 /dev/sdc2

/dev/disk:
drwxr-xr-x    2 root     root           140 Aug  4 07:08 by-id
drwxr-xr-x    2 root     root            80 Aug  4 07:08 by-partuuid
drwxr-xr-x    2 root     root           140 Aug  4 07:08 by-path

/dev/disk/by-partuuid:
lrwxrwxrwx    1 root     root            10 Aug  4 07:08 d7e0b3f5-01 -> ../../sdc1
lrwxrwxrwx    1 root     root            10 Aug  4 07:08 d7e0b3f5-02 -> ../../sdc2

After installation the system is unbootable because it specifies
  root=/dev/sdc1
in the boot line rather root=UUID=<some-uuid>

The system can be made to boot by and editing the boot line in grub to be
  root=/dev/sda1

In /etc/fstab the / partition is correctly mounted by UUID;
so after hacking the boot line, the system boots correctly.

So it seems that somewhere in grub-installer, the conversion between
device file and UUID is failing and the code is falling back to the
device file.
Strangely, the fstab comment about which device / was on during
installation correctly says it was /dev/sdc1.

Doing the same install with jessie, the boot line is written correctly
using the root=UUID form. I checked and /dev/disk/by-uuid exists by
the time debootstrap is running, but /dev/disk/by-partuuid is never seen.

# ls -l /dev/sd* /dev/disk /dev/disk/by-uuid 2>/dev/null            
brw-------    1 root     root        8,   0 Aug  4 07:54 /dev/sda
brw-------    1 root     root        8,  16 Aug  4 07:54 /dev/sdb
brw-------    1 root     root        8,  32 Aug  4 07:54 /dev/sdc
brw-------    1 root     root        8,  33 Aug  4 07:54 /dev/sdc1
brw-------    1 root     root        8,  34 Aug  4 07:54 /dev/sdc2

/dev/disk:
drwxr-xr-x    2 root     root           140 Aug  4 07:54 by-id
drwxr-xr-x    2 root     root            60 Aug  4 07:54 by-uuid

/dev/disk/by-uuid:
lrwxrwxrwx    1 root     root            10 Aug  4 07:54 dc5e366d-94f3-4d8b-82df-df40962bb889 -> ../../sdc1


I hope this is some help with moving this problem forward
Vince

Reply | Threaded
Open this post in threaded view
|

Re: Problem: UUIDs not being used everywhere for disks in stretch

Steve McIntyre
In reply to this post by Steve McIntyre
I've let this slip off my radar since, and it's not gone away.

I'm seeing this problem really obviously with live installations now,
as I've just been testing them with Secure Boot.

Hoping to play with this more in the next few days...

On Tue, Jul 25, 2017 at 11:33:36PM +0100, Steve McIntyre wrote:

>Hey folks,
>
>Leif (in CC) pointed this out to me after he did a fresh Stretch
>installation over the weekend. I've just verified the problem
>myself. Our initial thought was that this might be specific to
>installations onto NVME, but I've tested and it's not, it's generic.
>
>Right at the end of a simple installation to a single disk device,
>when we run grub-installer, the generated grub.cfg is using
>root=/dev/XXXX for the kernel command line rather than what it should
>be (root=UUID=YYYY). This bug has managed to slip through our
>installation testing as the resulting system will still boot fine for
>simple single-disk cases...
>
>I've compared this to a jessie installation using the same setup, and
>that did the right thing (i.e. the final grub.cfg used
>root=UUID=YYYY).  I've spent some time tracking down what's going on,
>and I can see the *first* level of problem at least.
>
>In grub-mkconfig, it looks for entries in /dev/disk/by-uuid/ to match
>the UUID for /. If it can't find one, it falls back to using the
>direct /dev/ disk device for the rootfs. Checking back, I can see:
>
> * in jessie, the entries in /dev/disk/by-uuid/ are refreshed after
>   we're finished in partman
>
> * in stretch, they are not. You can see this most obviously - start
>   with a blank disk and the only entry that will show up in there
>   throughout the installation is for the installation medium
>
>Does anybody have any insights as to how this might have
>changed/broken? I'm too tired to dig much further tonight, but I'll
>carry on looking tomorrow.
>
>*Finally* - this is not a critical problem in the long run AFAICS. As
>soon as people update their grub.cfg in their new system (so a new
>kernel, or a new grub, or new versions of various other packages),
>the installed system should generate a fixed UUID-style grub.cfg.
>
>--
>Steve McIntyre, Cambridge, UK.                                [hidden email]
>< Aardvark> I dislike C++ to start with. C++11 just seems to be
>            handing rope-creating factories for users to hang multiple
>            instances of themselves.
--
Steve McIntyre, Cambridge, UK.                                [hidden email]
Welcome my son, welcome to the machine.

Reply | Threaded
Open this post in threaded view
|

Re: Problem: UUIDs not being used everywhere for disks in stretch

Steve McIntyre
On Tue, Jan 15, 2019 at 04:29:36PM +0000, Steve McIntyre wrote:
>I've let this slip off my radar since, and it's not gone away.
>
>I'm seeing this problem really obviously with live installations now,
>as I've just been testing them with Secure Boot.
>
>Hoping to play with this more in the next few days...

OK, I *think* I have worked out the fundamental problem here. I
uploaded an initial fix for #852323 a few weeks back, but it was only
a quick hack (call "udevadm trigger" instead of "udevadm settle")
until I found the time to dig in to the code properly. Now, with a few
hours undisturbed on a long flight, I think I've sussed the root cause
with judicious use of "udevadm monitor", ls and blkid. \o/

It's all down to ordering of events. In /lib/partman/commit.d in d-i,
we have the following ordering at the moment for some of the scripts:

 30parted
 32update-dev <<----- triggers the udev update
 45format_swap
 50format_*fs <<----- responsible for running mkfs

It's quite simple. 32update-dev is asking for udev updates, and that
will cause the various /dev/disk/by-*/ symlinks to be updated or
refreshed. But that's the wrong point. In particular for
/dev/disk/bu-uuid, the UUID values themselves come from the filesystem
headers. We *then* make the filesystems for each block device, and
anything that changes at this point will never be represented in the
by-uuid symlinks.

We need to run update-dev *after* the filesystem creation scripts and
this fixes things. I've just copiet it to 99update-dev locally while
testing and that made all the difference. It could probably also just
be moved instead of copied - at this point I'm not sure if anything in
the other scripts also depend on the udev updates for their
functionality. Fundamentally, it's a fairly harmless thing to run
repeatedly so I'm tempted to just run it twice. Thoughts?

So, the question is - how did this *ever* work on older versions of
d-i (Jessie and earlier)? I honestly can't see how it could, so I'm
going to hand-wave and say "timing". If the udev update code took
longer to run, *maybe* the first bit of filesystem creation steps
would have already run by the time the by-uuid symlinks were
made. After all, it's only looking at the filesystem headers so it
wouldn't matter if a long, slow mkfs for a big device was still
going. I know that the systemd folks have put a lot of effort into
making udev more streamlined over the last few years and *maybe* this
has just exposed an underlying bug we've had for ages.

[ Hitting send on this mail now on the plane while I have all this
  fresh in my head, even if it's not going to hit network for a few
  hours yet! ]

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
"Arguing that you don't care about the right to privacy because you have
 nothing to hide is no different than saying you don't care about free
 speech because you have nothing to say."
   -- Edward Snowden

Reply | Threaded
Open this post in threaded view
|

Re: Problem: UUIDs not being used everywhere for disks in stretch

Steve McIntyre
Actually...

On Sat, Apr 06, 2019 at 04:36:59PM +0100, Steve McIntyre wrote:
>
>We need to run update-dev *after* the filesystem creation scripts and
>this fixes things. I've just copiet it to 99update-dev locally while
>testing and that made all the difference. It could probably also just
>be moved instead of copied - at this point I'm not sure if anything in
>the other scripts also depend on the udev updates for their
>functionality. Fundamentally, it's a fairly harmless thing to run
>repeatedly so I'm tempted to just run it twice. Thoughts?

I think we're definitely going to need this, actually - new device
entries may not show up otherwise.

I'm also seeing in my testing that I *do* need to force a "udevadm
trigger" in the second script. Fundametally, it you don't get new
kernel events when a mkfs happens so udev will never notice.

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
Dance like no one's watching. Encrypt like everyone is.
 - @torproject

Reply | Threaded
Open this post in threaded view
|

Re: Problem: UUIDs not being used everywhere for disks in stretch

Ben Hutchings-3
On Sat, 2019-04-06 at 16:54 +0100, Steve McIntyre wrote:

> Actually...
>
> On Sat, Apr 06, 2019 at 04:36:59PM +0100, Steve McIntyre wrote:
> > We need to run update-dev *after* the filesystem creation scripts and
> > this fixes things. I've just copiet it to 99update-dev locally while
> > testing and that made all the difference. It could probably also just
> > be moved instead of copied - at this point I'm not sure if anything in
> > the other scripts also depend on the udev updates for their
> > functionality. Fundamentally, it's a fairly harmless thing to run
> > repeatedly so I'm tempted to just run it twice. Thoughts?
>
> I think we're definitely going to need this, actually - new device
> entries may not show up otherwise.
>
> I'm also seeing in my testing that I *do* need to force a "udevadm
> trigger" in the second script. Fundametally, it you don't get new
> kernel events when a mkfs happens so udev will never notice.
Closing a block device that is opened for writing should trigger a
change event.  I tested this now with Linux 4.19.28 and it still seems
to happen.

Ben.

--
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.



signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Problem: UUIDs not being used everywhere for disks in stretch

Steve McIntyre
Hey folks,

On Sun, Apr 07, 2019 at 01:01:34AM +0100, Ben Hutchings wrote:

>On Sat, 2019-04-06 at 16:54 +0100, Steve McIntyre wrote:
>> Actually...
>>
>> On Sat, Apr 06, 2019 at 04:36:59PM +0100, Steve McIntyre wrote:
>> > We need to run update-dev *after* the filesystem creation scripts and
>> > this fixes things. I've just copiet it to 99update-dev locally while
>> > testing and that made all the difference. It could probably also just
>> > be moved instead of copied - at this point I'm not sure if anything in
>> > the other scripts also depend on the udev updates for their
>> > functionality. Fundamentally, it's a fairly harmless thing to run
>> > repeatedly so I'm tempted to just run it twice. Thoughts?
>>
>> I think we're definitely going to need this, actually - new device
>> entries may not show up otherwise.
>>
>> I'm also seeing in my testing that I *do* need to force a "udevadm
>> trigger" in the second script. Fundametally, it you don't get new
>> kernel events when a mkfs happens so udev will never notice.
>
>Closing a block device that is opened for writing should trigger a
>change event.  I tested this now with Linux 4.19.28 and it still seems
>to happen.
OK, that's a useful thing to check - thanks!

To see WTF is going om, I've just re-run test installations of both
stretch (9.8.0) and buster (a netinst from last week). In each case,
I've started "udevadm monitor | logger -t udevmon" in the background
in the installer. I've run a basic installation through to completion,
then on first boot I've run:

 # udevadm monitor > log &
 # swapoff -av
 # mkfs.ext4 /dev/vda3

I've grepped out the udev monitor log lines from both the installer
and the installed system - see attached.

*In the installer*, we're not seeing *any* "change" events for the
hard disk (vda in my case), in either stretch or buster. We just get
the "add" and "remove" events. In the buster installer, my temporary
hack of forcing the "udevadm trigger" means that the UUIDs are updated
for Grub to use, but it's clearly not a correct final solution.

Yet... in both cases in the post-installer runtime we're getting the
"change" events when I do the mkfs.

Is udev maybe built differently for the installer, or do we have some
missing config somewhere? Digging there next.

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
"Every time you use Tcl, God kills a kitten." -- Malcolm Ray

buster-normal-udev.log.gz (244 bytes) Download Attachment
buster-installer-udev.log.gz (23K) Download Attachment
stretch-normal-udev.log.gz (248 bytes) Download Attachment
stretch-installer-udev.log.gz (6K) Download Attachment