|
Boot Slackware on NVME SSD?
Hello,
I celebrated the release of 14.2 by building a new PC to run it. It's a mini-ITX board with a Xeon E3-1241, 32G of ECC RAM and a 512G Samsung 950PRO M2 SSD. This last is giving me heartburn. The complete Slackware install happens, but then Lilo refuses to install itself. It complains that it can't handle the SSD device. Somebody else asked similar: https://www.linuxquestions.org/quest...ks-4175567831/ It looks like it ain't gonna work. Anybody know a workaround? Use Slackware with a different bootloader? I downloaded the Lilo source and found the spot where it complains.... I suppose I could try adding that particular major # (259 ) to the "approved" list in geometry.c. If all else fails, I could boot Slackware off a memory stick, and tell it to use the root directory on the fast SSD. Ick. Thoughts? These NVME SSDs are only going to get more & more popular. They're a bit pricy now, but they will come down... And they're over 3 times as fast as SATA SSDs. - Jerryk |
jkaidor --
I agree about the NVMe devices -- they're already here ! I've got a pair of the 500GB Samsung 950 Pros in my Laptop as secondary drives where they work VERY well ( speed wise ). As for booting Slackware from an NVMe ... 1. This guy: https://rlaanemets.com/post/show/computer-upgrade was able to boot an NVMe using syslinux installed in /boot/ on his 'old drive' ... No direct help there but he does show how he used syslinux to 'auto-boot' Slackware installed in /root/ on the NVMe. IOW, you should be able to boot into your new NVMe from a small USB Disk with syslinux to get things going. 2. And here's a question on the Arch Forum where booting directly via the EFI Shell is mentioned for a Non-Dual-Boot System: https://bbs.archlinux.org/viewtopic.php?id=209653 Then, after you're up and running ... 3. This Stack Exchange post: http://unix.stackexchange.com/questi...alling-debiavn has a solution for Debian + grub-efi-amd64 and was adapted from this Debian Wiki Article ( #4 ) : https://wiki.debian.org/InstallingDe...CIe_SSD/jessie Maybe #1 or #2 will get you going where you could explore #3 and #4 ? I am not sure what's contained in grub-efi-amd64.deb nor how entangled it may be with systemd but that is left as an 'exercise for the reader' :) HTH, at least a little bit, I am still trying unlearn my old 1980 IBM-PC BIOS Habits and to wrap my old-fart brain-cells around all the new HW / SW tech :) -- kjh |
This worked:
https://rlaanemets.com/post/show/computer-upgrade The syslinux instructions are near the bottom of the page. After getting dumped into a root command line after setup... I created a text file /boot/extlinux.conf: -------- snip ----------- DEFAULT linux SAY Now booting the kernel from SYSLINUX LABEL linux KERNEL vmlinuz APPEND ro root=/dev/nvme0n1p1 -------- endsnip ------ And ran extlinux --install /boot And then did a magic dd to get the generic syslinux code into the mbr: cd /usr/share/syslinux dd bs=440 conv=notrunc if=mbr.bin of=/dev/nvme0n1 ...and then rebooted, and it Just Worked. Yay! I still have a *lot* of work to do. I have been refining my server for many years, and everything will need to be ported to this new machine. Newer, higher tech makes this server simpler than the old one. I used to do all sorts of tricks with multiple disks and partitions to make things faster. /home on a different device than /bin,/usr/bin etc. None of that is necessary with an SSD. Just one big partition for everything. Except for a swap partition, which I am including out of an abundance of caution, although I do not anticipate running out of physical RAM with 32G. - Jerryk |
I use 14.2 booted from NVMe disk, Samsung 950 in a Lenovo notebook and an Intel disk in a desktop computer (self-assembled).
I use UEFI and elilo. There is a minor problem with the installer that simply doesn't search for a EFI partition on an NVMe disk. I wrote how I worked around this problem here. |
Quote:
Thank you for this. I too just built myself a new machine with a NVME SSD and had the same issue and your post worked like a charm except that your syslinux.conf should be extlinux.conf. Just got Slackware installed and running updates and installing everything I need. |
i did my install by PXE boot from an raspberrry pi ... lol
have had no problems so far ... |
Quote:
- Jerry |
Thanks all !
When I received this new laptop, Sager had installed Win10 on one of the NVMe Cards -- it worked well and was Pretty-Dang-Quick. I hit a wall trying to install to the other NVMe Card, chickened out and installed SlackWare64 Current on one of the Samsung 850 Pro SSDs instead and set up the pair of NVMe Disks as 'secondary'. I now see three ways that I could have booted Slackware Current from an NVMe Card ( syslinux ala jkaidor or elilo ala slalik or PXE boot ala Wiser Slacker ). Thanks again ! This Thread is a 'keeper' -- kjh |
jkaidor --
If you consider your NVMe Install issue solved, it may help other users if you mark the Thread as SOLVED. I usually start my LQ searches for fixes with 'Threads Marked SOLVED' and I'll bet that others do too. Thanks ! -- kjh |
Quote:
|
maybe it helps ...
Hi,
if you want to boot lilo to an nvme - where the other devices are changed, may be you put in some more sata drives - i did it this way: My Problem had been that the device order did change when i put in another hd ... 1. i do install lilo into the mbr of that disk i want to boot from ... 2. give the boot statement by the line below to lilo.conf boot = /dev/disk/by-id/ata-PLEXTOR_PX-G256M6e_Pxxxxxxxxx 3. than you should use the following statement to tell the kernel where the root disk is Code:
lilo.conf4. you should use the form of LABEL= or maybe /dev/disk/by-xxxxyyyyyzzzzz in fstab 5. tell the bios witch device you want to start from now you are total free from any device order the bios tell to your booting os (here slackware ;) ) as i said before - the initial booting could be done by any device (maybe pxe as i do) witch is able to start the installer all needed tools are already in the slackware installer greetings W.Slacker |
Quote:
Code:
root = "PARTUUID=abcdefgh-02" |
i have written:
Quote:
to make it clear DON't use the Quote:
the results are different ! and they may not do what you want or think off !! |
Quote:
|
i have had a look into kernelsource ...
/usr/src/linux/init/do_mounts.c so with this option, i told here before, you don't need any initrd, the needed "device tree" was created by the kernel itself and LILO don't need to interpret any UUID's - the PARTUID is found by the kernel while booting and could be found in any disk partition table - ok. i just try "table msdos" yet ... while lilo did write something like 0810 or 0820 into the kernels head before, for finding its partitions, it don't have to write these infos into the kernel now, but the kernel get its info from command line .... and as i said - lilo seemed not to want your root option ... ok. you know .. to keep it clear - if you tell lilo-instaler to "interpret" what it should write into the boot loader it did that by following the /disk-by/ ... way and found the device ID - that could be wrong (after reboot) if you change any disks in your pc - so the kernel later can't find its root partition ! these are the most misinterpreted problems while booting any os's - the internet is full of those people who can't get its machines to boot ... mostly with windooofs |
The /dev/disk/by-*/ IDs should not change if the underlying hardware or disk order is changed. So, they can be successfully referenced. However, I'm not sure which ones would need initrds.
After further research, I found that PARTUUID and PARTLABEL are only available for disks formatted using GPT. They are not available for disks using MBR. I've only used GPT on disks that are too large for MBR, so I have some disks that support PARTUUID (all my storage drives that are 3TB and larger) and some that don't (including my main 480GB SSD since it was small enough to use MBR). I assumed PARTUUID and PARTLABEL had similar support in lilo, but it seems that is not the case, and lilo only contains support for UUID and LABEL to be called directly under the root option. If you want to use PARTUUID or PARTLABEL, you will need to use the addappends option as in your example. So, if your primary boot drive and root OS drive are using the MBR partition table, you can't use PARTUUID without converting your disk to GPT. UUID will work regardless of the partition table, although, as has been discussed previously, it does require an initrd. |
sorry but you do make the same error like many people around too,
Quote:
Quote:
Quote:
1. i never ever have formated any disk knowingly with gpt ... 2. you may try this on the oldest lilo you have ... Quote:
to know that the symlinks always point to the same point is no help when detecting the root device while booting, because these first numbers may change ! only the second two numbers dont change ... these numbers do the kernel itself could use to deteckt its root filesystem. lilo standard just uses 0x80 or 0x81 to give them to kernel because these numbers came from bios these could change ... lilo cant know of what number it is next time, and if you give that to kernel the kernel dont know either ! please read the lilo manual carefuly, and maybe the kernel docs, the safest way to boot to the paritions you want is posted in my example above ;) and as i said before this is the reason for the most boot problems out there !! |
Quote:
Quote:
Code:
jbhansen@craven-moorhead:~$ ls -la /dev/disk/by-partuuid/Apologies... apparently, while PARTUUID (and PARTLABEL) is only part of the GPT spec, the kernel will generate a PARTUUID for non-GPT partitions too (just as UUIDs are not part of the NTFS spec, but they're still provided). This ability to provide MBR partitions with PARTUUIDs was added in the 3.8 kernel. That is why when you view blkid, the MBR partitions' PARTUUID is much shorter than the GPT partitions, because it isn't a real UUID. Luckily, it doesn't change (without changing the partitions), so it should still be fine to use as a reference. Code:
root@craven-moorhead:~# blkidCode:
jbhansen@craven-moorhead:~$ sudo fdisk -l /dev/sda | grep identifierTL;DNR It used to be required to use UUIDs or LABELs, in conjunction with an initrd, to boot a system that might have disks devices changing order. GPT added PARTUUID and PARTLABEL within its spec that allows referencing the disk without requiring an initrd. The 3.8 kernel added generated PARTUUIDs based on the Disk Identifier and partition number for non-GPT partitions. So, any system using 3.8 and newer can boot using PARTUUIDs without requiring an initrd. :thumbsup: @Wise Slacker, thanks for the nudge for me to fully research this and figure out what is going on. |
ok. ;)
hope you get it now ... it took me one day to let lilo do what i want it to do - so i now can put my 4x1Terra => Raid5 disks into the new machine when i need it ... while my boot disk (nvme) seemed always be the last one in system, because it is bound by pci to the system and would be discovered at last ... there in no switch like "pci first" in the bios anymore ... i have always had different disks for system and data since they are "so cheap" - lol |
I think the big issue is people have been using UUIDs for years, and PARTUUID is a relatively new addition to Linux. I don't know when GPT was introduced, but, for most, it wasn't really needed until drives surpassed the 2TB mark. And the first 3TB drive wasn't introduced until 2010. Even then, it probably wasn't likely that people were using them for their boot drives, so they wouldn't even need to know about it. Then, to add "PARTUUID" support for MBR devices, the 3.8 kernel wasn't released until 2013, only 9 months before 14.1 was released.
So, PARTUUIDs are still relatively new to the Linux world, and it seems like a lot of documentation hasn't properly caught up to provide the right info (at least, not completely). I had to go to several sites and try several different commands on my computer to determine the information provided above. (I may try and generate a page on the slackwiki for it.) But, PARTUUIDs are not part of the MBR, it is just something generated by the kernel using the Device Identifier, so I was correct that MBR devices don't support it. We're just lucky that the kernel developers found a way around it :) |
Documentation
Quote:
I encourage you to document this recently gained knowledge in the online Slackware docs. Many of us will appreciate the time you spend to do this. Of course Wiser Slacker and others contributed to the information in this thread. I'm just encouraging bassmadrigal to document it as he indicated he may be inclined to do so. |
Please note that PARTUUID on MBR disk:
1) can help with disk order changes (disk has the ID) 2) cannot help with reordered partitions on the disk (they uses numbers and not IDs) Second scenario may be actual for Win10 August 2016 anniversary update. |
@Wiser Slacker, do you use lilo? If so, how do you manage the "boot" variable. Since this references the drive itself and not a partition, UUIDs, labels, PARTUUIDs, and PARTLABELs won't work. Do you just use /dev/disk/by-id/? If so, does that not require an initrd?
I'm trying to compile information for a wiki article covering this topic. |
Quote:
is actual only at moment when "lilo" command is running. It points the device where lilo will write boot code. So when a machine boots it selects boot device, loads boot code from mbr (written there by lilo command), boot code loads a kernel and initrd and transfers control to kernel, when kernel gets control the bootloader code has done. So boot sequention have no time for "boot =" :-) |
Quote:
If that's the case, thanks! |
re: Hi,
Quote:
'root = ' statement not inside the kernel commandline, it "maybe" just point to the rigt point when INITIALISING the bootloader, it maybe wrong when the bootloading process itself is running. you may be right that the form of what (UUID , PARTUID , or others, .. ) the kernel commandline can detect without an initrd, ramdisk, or else, - has been changed in the last years ... but the bootloading process was always the same (till ueffi) ... the bootloader can only give a statical value to the starting kernal or os, it is known as devise id and is build out of to bytes - major and minor numbers ... hope it helps ... |
Quote:
and in fstab also - like other distributions do |
Quote:
How to configure lilo.conf and fstab with persistent naming |
Quote:
after reading your howto - i have seen that you have not totaly understand the thing ... the importent thing is to place the statement INTO or OUTSIDE of the kernel commandline ... NOT it's NAMES ... it will give you different results !!! you can test that by looking into cat /proc/cmdline Quote:
or this cat /proc/cmdline Quote:
Quote:
/usr/src/linux/init/do_mounts.c Quote:
;) |
Quote:
|
wrong
Quote:
Quote:
right Quote:
Quote:
|
I am thinking you're not understanding things. The way I put UUIDs is the correct way to do it with lilo.conf. I am successfully using it in my computer right now. Others have successfully done it with labels. I've helped several people set up their lilo.conf files with UUIDs. As I wrote in the article, PARTUUIDs are not properly supported in lilo (unlike regular UUIDs), so you need to use the addappend option, but you do not need it for UUIDs (if you're using an initrd). If you're trying to do it without an initrd, it might be completely different (and might get the output you found), but the way I wrote it there most definitely works.
There is even a perl script included with lilo called lilo-uuid-diskid (it's under /sbin/) that will go through and convert your lilo.conf to use UUIDs in the format I listed. You can view the script here and between lines 443 and 447 it will show an example of what it does, which is the format I provided. Also, to further iterate that this method works (without an append), if I view my /proc/cmdline, I get: Code:
BOOT_IMAGE=Slack-4.4.13 ro root=UUID=23bce2c2-996d-449e-89cc-0e5029cc6d8d vt.default_utf8=0Code:
image = /boot/vmlinuz-generic-4.4.13What you're probably seeing is when you use UUIDs without an initrd, which isn't supported. I specifically mentioned in the article that an initrd is required if using LABEL or UUID. The reason an initrd is required is because of what you quoted out of /usr/src/linux/init/do_mounts.c. As you can see, it doesn't support using UUIDs specifically (the only mention of UUID is under the PARTUUID section). It needs the environment provided by the initrd to use the UUID. If the environment isn't there, the kernel doesn't know what to mount and you end up with a kernel panic. Quote:
This whole thing is just like how the NTFS "UUID" is not an actual UUID, but is still able to be referenced as one. |
re: Hi, ;)
Quote:
Quote:
Code:
if ((root = cfg_get_strg(cf_kernel,"root")) || (root = cfg_get_strg(so i have learned it today ... ;) thank you |
may be simple patch for bsect.c is a good idea
Code:
if ((root = cfg_get_strg(cf_kernel,"root")) || (root = cfg_get_strg( |
Quote:
EDIT: I wonder if support could be added for PARTLABEL as well (I am not good enough with C to know how to add it), although, that is limited to solely GPT partitioned drives. |
Quote:
Code:
# zcat lilo.root.partuud.diff.gzCode:
# diff -u lilo.SlackBuild{.orig,} |
Quote:
I think I just figured it out. First it's checking if the string is longer than the characters used for the definition (in PARTUUID=, it is 9 characters, plus the actual UUID after), then it checks if the first 9 characters actually equals PARTUUID= (if it doesn't, it moves on to the next else if statement). Thanks for making me continue to learn on this thread ;) |
Good Stuff !
These are excellent enhancements for LILO. This Arch Doc helped me 'get it' Arch Persistent block device naming Thanks for helping make Slackware better for all ! -- kjh |
Quote:
|
sorry for disturbing your party ...
Quote:
maybe with an initrd - i dont know - i have never used that. ok. i shut up now |
Quote:
|
@bassmadrigal,
as I can see for now 'PARTLABEL=' 1) is unusable by kernel itself (see name_to_dev_t() from kernel's init/do_mounts.c), as "LABEL=" and "UUID=" too, and 2) is unusable by initrd. initrd's init script uses sbin/findfs to resolve "LABEL=" and "UUID=" to device name. As for 14.2 mkinitrd 1.4.8 uses BusyBox v1.20.2. It's findfs says: Code:
BusyBox v1.20.2 (2016-06-20 15:25:34 CDT) multi-call binary.So, for now "PARTLABEL=" is unusable by the kernel itself and by the initrd's init. |
Sounds good. Where would we look to see if the fstab still supports it?
|
@bassmadrigal,
/etc/fstab is a config file of mount command, so man mount -- for commandline support, man fstab -- for support in /etc/fstab. They (LABEL=, UUID=, PARTLABEL=, PATUUID=) are mentioned there. |
Quote:
|
Just out of curiosity for those who have the Samsung 950 Pro M.2. These things are ridiculously fast spec wise but on a regular desktop machine do you notice a real difference from a standard SSD?
|
Quote:
Yes, for our IO-Bound Data Conversion Scripts I do see a difference between the Samsung SM951 M.2 and the Samsung 850 Pro. Our Data Conversion App is nothing more than a set of sequential scripts that prepare a series of Delimited Text Files from a Legacy Business Basic System, then do Field-by-Field diffs on the sets of Current-vs-Previous Files ( pretty IO-Intensive ). I've got a pair of NVMe's and another pair of SSD's on my Laptop but I've never installed the App on one-of-each to benchmark the difference. My development instance of the App is installed and runs on an NVMe and it certainly finishes more quickly on my Laptop's NVMe Drive than 'anywhere else' even where they're running SSD Drives and especially on Boxes with Mechanical Drives . I've noticed that there is not much difference between I3, I5, I7 CPUs but the HDD interface makes a HUGE difference. One thing on 'my list' is to benchmark our DataFlow App on SATA HDD, SATA SSD, PCIe SSD, and NVMe SSD with similar CPUs to see what I really gain. But that list is long and it seems to grow with time rather than shrink :) Anyhow, anecdotally, yes they do run faster, depending on what you're doing. And the way things are going, the PCIe / NVMe interface is coming soon to a Laptop near you :) -- kjh |
Ok, sorry for the delay, but I have finally finished the article. I will leave the FIXME portion at the top for a day or two to give you guys (and gals) an opportunity to go through and make any suggestions and/or corrections.
I welcome any feedback, either good or bad, on the article. How to configure fstab and lilo.conf with persistent naming |
bassmadrigal --
I looked at your new HowTo this morning. Very nice ! Thank you. -- kjh |
| All times are GMT -5. The time now is 07:30 AM. |