SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
For what it's worth, gdisk (available on slack ISO) has a 'zap' feature that blows away the GPT partition table and the protective MBR. This is a very quick way to return a drive to a clean state without zeroing the whole thing.
Code:
gdisk /dev/sd[]
x (for expert mode)
z (to zap)
follow prompts
gdisk will exit back to command line, but then run it again to make a clean GPT with protective MBR.
From there, cfdisk (as discussed above) is a really easy partition tool and will recognize GPT and give you the option to make an EFI partition.
Also, these changes are not always gracefully updated on a running system, so using lsblk may not report the changes. My solution is to reboot and continue with the install.
Also, these changes are not always gracefully updated on a running system, so using lsblk may not report the changes. My solution is to reboot and continue with the install.
Easier, run as root:
Code:
partprobe
This informs the kernel of partition table changes, so no need to reboot after that, lsblk will display an up to date information.
Also, to wipe the partition table you can use the command wipefs.
EDIT Despite its name wipefs does not modify the file systems in any way.
Last edited by Didier Spaier; 01-30-2020 at 02:19 AM.
Reason: EDIT added and typo fixed.
boot parameter does override whatever I have in my initrd. The only thing I can think of, if after switching your
Code:
/etc/fstab
to use PARTUUID instead of the device nodes and editing
Code:
/boot/efi/EFI/Slackware/elilo.conf
system does not always boot, is that you are still running eliloconf after editing elilo.conf.
DO NOT do that and the system should boot using the new config file. Works here without fail, and that on a usb drive used on different machines with different drive configuration, albeit with extra modules in initrd and "rootwait" commandline parameter.
The possibility is a big if here. Keyword was "sufficiently unique". I include the last 3 or 4 characters of the HD or SSD serial number as well as what I typed. Sometimes I leave out the P, sometimes I put the P# first, sometimes last, so uniqueness is quite sufficient.
Yes, of course. Unique LABELs [devices, files, directories, nodes, etc.] are prudent, if not required, in any and all cases. If one had planned for this eventuality then LABELs might be sufficient. I feel that in my situation it's better to use an element where there is no risk, or chance, of polluting the LABEL ID structure - such as PARTUUID, or UUID.
Quote:
Originally Posted by mrmazda
If and when there is a conflict, you'll see so in a boot message, dmesg or journal. I've tested. IIRC mounts will be RO or fail entirely. The "trouble" need be no more than a temporary nuisance, until the duplication can be corrected.
If and when I can avoid any conflict(s) then I will take the route that's conducive towards that end. Ergo, LABELs are not nearly as adequate and sufficient as PARTUUID or UUID for this reason and purpose. There are better alternatives than LABEL, for many more reasons than stated here, and I'm really wasting your time by pursuing any further thoughts on the idea. I'm emphatic that PARTUUID or UUID is the way to go.
boot parameter does override whatever I have in my initrd. The only thing I can think of, if after switching your
Code:
/etc/fstab
to use PARTUUID instead of the device nodes and editing
Code:
/boot/efi/EFI/Slackware/elilo.conf
system does not always boot, is that you are still running eliloconf after editing elilo.conf.
DO NOT do that and the system should boot using the new config file. Works here without fail, and that on a usb drive used on different machines with different drive configuration, albeit with extra modules in initrd and "rootwait" commandline parameter.
Thanks for your reply and testing. I am not using 'eliloconfig'. One of the questions in my OP is, "can I not use 'eliloconfig' at all and retain the PARTUUID settings in my /boot/efi/EFI/Slackware/elilo.conf file which I set manually?" because I do not want to overwrite my elilo.conf settings. Once I figured out that 'eliloconfig' was replacing my elilo.conf settings I stopped using it altogether.
If 'root=' boot parameter in elilo.conf overrides whatever is set in the initrd then I am unsure why my existing settings are not taking effect because that's exactly how my system is configured right now.
However, I cannot account for how much the ASRock "UEFI Legal" [citation needed] onboard shizzle might be contributing towards this problem.
If you run the /usr/share/mkinitrd/mkinitrd_command_generator.sh command, it will spit out a long command. What you want to adjust is the -r option. You'll want to change the -r /dev/sdb4 to -r "PARTUUID=7fdc1b32-70e8-42eb-a3a0-b24851c28fa8" and keep the rest of the command the same (unless you want to change the name of the output file at the end). Then make sure that initrd is copied to /boot/efi/EFI/Slackware/ and is referenced properly in your elilo.conf.
Code:
root@spex:~# /usr/share/mkinitrd/mkinitrd_command_generator.sh -k 5.4.15
#
# mkinitrd_command_generator.sh revision 1.45
#
# This script will now make a recommendation about the command to use
# in case you require an initrd image to boot a kernel that does not
# have support for your storage or root filesystem built in
# (such as the Slackware 'generic' kernels').
# A suitable 'mkinitrd' command will be:
mkinitrd -c -k 5.4.15 -f ext4 -r /dev/sdb4 -m xhci-pci:ohci-pci:ehci-pci:xhci-hcd:uhci-hcd:ehci-hcd:hid:usbhid:i2c-hid:hid_generic:hid-asus:hid-cherry:hid-logitech:hid-logitech-dj:hid-logitech-hidpp:hid-lenovo:hid-microsoft:hid_multitouch:jbd2:mbcache:ext4 -u -o /boot/initrd.gz
WOW! That's some mkinitrd command!!! What the hell???
Then after it's been built I move/copy it to the /boot/efi/EFI/Slackware/ dir - ** but rename/backup original initrd.gz first. No need to modify elilo.conf because the ram disk filename is the same.
So that's the plan.
Last edited by Exaga; 01-30-2020 at 02:37 AM.
Reason: yes
There is nothing wrong with using PARTUUID ... using UUID or PARTUUID is a one time configuration option I use ... using UUIDs in my case prevent issues if I happen to plug in an older drive that has the same label as its replacement.
bassmadrigal sir, you are a certified LEGEND!
I built an initrd which included the UUID, as you advised, while loosely referring to this Slackdocs page for guidance.
OK. So, after studying the ins and outs of this a little and recollecting your words above, I decided to drop PARTUUID and implement UUID only. Why? Because the initrd I have just built now uniquely supports the UUID of my '/' partition so it makes sense to use UUID explicitly for this purpose. I set about revising my config files and settings...
I backed-up the existing /boot/efi/EFI/Slackware/initrd.gz and copied it to /boot/OLD_initrd.gz - then copied the new /boot/initrd.gz I'd just built to /boot/efi/EFI/Slackware/initrd.gz - I then power-off the system and connected my old SATA "/home" HDD that has exactly the same LABEL as my new SATA "/home" HDD. Then I powered the system on and...
OMG!!!!!!! - the system booted as expected and Slackware64-current loaded with orchestral harmony and precision. This is now a "1st" for me in that all my storage device partitions are where they should be and identified correctly - with an additional storage drive connected. Simply building an initrd to accommodate the UUID in the way you advised was the deciding factor. I can now connect ANY storage device [with the same LABEL or not!] and the system will retain the current configuration.
Thank you. Thank you. Thank you.
Last edited by Exaga; 01-30-2020 at 05:29 AM.
Reason: addiitonal description
Well, I don't think that elilo supports PARTUUID. Its config file is similar to that of lilo, which doesn't.
Grub now does, and support for PARTUUID in case of a dos partition table was added recently. This is what is set by default in /etc/default/grub in the grub package for Slint.
Caveat: this works only for grub recently built from the git repository.
Last edited by Didier Spaier; 01-30-2020 at 06:37 AM.
Well, I don't think that elilo supports PARTUUID. Its config file is similar to that of lilo, which doesn't.
Grub now does, and support for PARTUUID was added recently to it. This is what is set by default in /etc/default/grub in grub package for Slint.
Caveat: this works only for grub recently built from the git repository.
Thanks Didier. I'll certainly bear that in mind. I've used 'lilo' all my Slackware days and now having gained some experience with 'elilo' there doesn't seem to be a great deal of difference in code/setting requirements. 'grub' is not familiar to me at all.
I read that PARTUUID was available to use without the need to build and initrd but, seeing as it wasn't working on my setup, I now realise that UUID with a purpose-built initrd is a much better option for me.
Thanks also for the 'partprobe' tip. I will be sure to remember that one for future reference.
Last edited by Exaga; 01-30-2020 at 05:56 AM.
Reason: ()
I built an initrd which included the UUID, as you advised, while loosely referring to this Slackdocs page for guidance.
I'm glad that guide was helpful. I'm the one that wrote it a few years ago. I guess I had incorrectly assumed that with elilo being made to support UEFI firmware that it would support PARTUUID, so I didn't think to mention switching to UUID in my posts.
I'm glad that guide was helpful. I'm the one that wrote it a few years ago. I guess I had incorrectly assumed that with elilo being made to support UEFI firmware that it would support PARTUUID, so I didn't think to mention switching to UUID in my posts.
Yes, so you did. I've just realised.
I referred to the guide so I didn't miss anything out that we might not have discussed. It made sense to me to use UUID and not PARTUUID because i was using the UUID within the mkinitrd command.
I guess I had incorrectly assumed that with elilo being made to support UEFI firmware that it would support PARTUUID, so I didn't think to mention switching to UUID in my posts.
I just tried using elilo and huge kernel (hence, no initrd used) with kernel parameter root=PARTUUID=<my-root-PARTUUID>. It booted up correctly and no errors. I even tried adding resume=PARTUUID=<my-swap-PARTUUID> to the kernel parameter and it also worked.
Also, looking at the init/do_mounts.c source code of the linux kernel, there are some comments related to what is permitted for root=
Code:
/*
* Convert a name into device number. We accept the following variants:
*
* 1) <hex_major><hex_minor> device number in hexadecimal represents itself
* no leading 0x, for example b302.
* 2) /dev/nfs represents Root_NFS (0xff)
* 3) /dev/<disk_name> represents the device number of disk
* 4) /dev/<disk_name><decimal> represents the device number
* of partition - device number of disk plus the partition number
* 5) /dev/<disk_name>p<decimal> - same as the above, that form is
* used when disk name of partitioned disk ends on a digit.
* 6) PARTUUID=00112233-4455-6677-8899-AABBCCDDEEFF representing the
* unique id of a partition if the partition table provides it.
* The UUID may be either an EFI/GPT UUID, or refer to an MSDOS
* partition using the format SSSSSSSS-PP, where SSSSSSSS is a zero-
* filled hex representation of the 32-bit "NT disk signature", and PP
* is a zero-filled hex representation of the 1-based partition number.
* 7) PARTUUID=<UUID>/PARTNROFF=<int> to select a partition in relation to
* a partition with a known unique id.
* 8) <major>:<minor> major and minor number of the device separated by
* a colon.
* 9) PARTLABEL=<name> with name being the GPT partition label.
* MSDOS partitions do not support labels!
* 10) /dev/cifs represents Root_CIFS (0xfe)
*
* If name doesn't have fall into the categories above, we return (0,0).
* block_class is used to check if something is a disk name. If the disk
* name contains slashes, the device name has them replaced with
* bangs.
*/
I also tried booting the generic kernel using initrd and the same PARTUUID kernel parameter as before, then the system couldn't boot properly. I guess it's because of the initrd's init script that doesn't properly handle root=PARTUUID=* kernel parameter. So, with some modification to initrd's init script I was able to boot properly using root=PARTUUID=* kernel parameter.
Last edited by mumahendras3; 01-30-2020 at 04:26 PM.
Reason: Added some other testing results
I just tried using elilo and huge kernel (hence, no initrd used) with kernel parameter root=PARTUUID=<my-root-PARTUUID>. It booted up correctly and no errors. I even tried adding resume=PARTUUID=<my-swap-PARTUUID> to the kernel parameter and it also worked.
Thanks for the confirmation! I've never tried using PARTUUID, as I started with UUID and have been happy with using that. It'd definitely be interesting to find out what the issue was with Exaga situation, but at least it is resolved and the system is booting.
Quote:
Originally Posted by mumahendras3
Also, looking at the init/do_mounts.c source code of the linux kernel, there are some comments related to what is permitted for root=
Code:
/*
* Convert a name into device number. We accept the following variants:
*
* 1) <hex_major><hex_minor> device number in hexadecimal represents itself
* no leading 0x, for example b302.
* 2) /dev/nfs represents Root_NFS (0xff)
* 3) /dev/<disk_name> represents the device number of disk
* 4) /dev/<disk_name><decimal> represents the device number
* of partition - device number of disk plus the partition number
* 5) /dev/<disk_name>p<decimal> - same as the above, that form is
* used when disk name of partitioned disk ends on a digit.
* 6) PARTUUID=00112233-4455-6677-8899-AABBCCDDEEFF representing the
* unique id of a partition if the partition table provides it.
* The UUID may be either an EFI/GPT UUID, or refer to an MSDOS
* partition using the format SSSSSSSS-PP, where SSSSSSSS is a zero-
* filled hex representation of the 32-bit "NT disk signature", and PP
* is a zero-filled hex representation of the 1-based partition number.
* 7) PARTUUID=<UUID>/PARTNROFF=<int> to select a partition in relation to
* a partition with a known unique id.
* 8) <major>:<minor> major and minor number of the device separated by
* a colon.
* 9) PARTLABEL=<name> with name being the GPT partition label.
* MSDOS partitions do not support labels!
* 10) /dev/cifs represents Root_CIFS (0xfe)
*
* If name doesn't have fall into the categories above, we return (0,0).
* block_class is used to check if something is a disk name. If the disk
* name contains slashes, the device name has them replaced with
* bangs.
*/
The issue with looking into what the kernel supports for the root= parameter is that parameter may not be supported/recognized by the bootloader. The original lilo would not support a PARTUUID if placed in the root= field in a stanza. You had to use a global append or an addappend in the stanza and specify the root portion directly to the kernel. So, even if the kernel supports it, you may have to do some funky methods to get it working in your specific bootloader.
Thanks for the confirmation! I've never tried using PARTUUID, as I started with UUID and have been happy with using that. It'd definitely be interesting to find out what the issue was with Exaga situation, but at least it is resolved and the system is booting.
TBH your next paragraph might answer what my individual problem might have been with PARTUUID not working as expected...
Quote:
Originally Posted by bassmadrigal
The issue with looking into what the kernel supports for the root= parameter is that parameter may not be supported/recognized by the bootloader. The original lilo would not support a PARTUUID if placed in the root= field in a stanza. You had to use a global append or an addappend in the stanza and specify the root portion directly to the kernel. So, even if the kernel supports it, you may have to do some funky methods to get it working in your specific bootloader.
I put a straight 'root=PARTUUID=' in the stanza and not as a global 'append' or an 'adddappend'. That's a habit from my 'lilo' days and I guess it's a bad habit now with 'elilo'? Bearing in mind it's very possible that my ASRock motherboard is the culprit and not Slackware!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
That's some mkinitrd command!!! What the hell??? 
