SlackwareThis Forum is for the discussion of Slackware Linux.
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Yup - I saw that thread and he solved it with increasing the rootdelay.
However, he also used grub2 which is a bit more clever at sorting out stuff ...
I have tried several values for rootdelay - to no avail (unless I use /dev/sdb3, in which case a root delay of 3 secs was more than sufficient.
Yes, I tried with root-LABEL=... as well - didn't work for me. Though, both UUID= and LABEL= worked fine in /etc/fstab (as well it should).
As for the rest of you - and thank you for all ditching in - appreciated!
I tried root=/dev/disk/by-uuid/... (as suggested earlier), but this didn't work either - alas. Obviously, there is no /dev/disk/by-uuid available before the root filesystem is mounted.
So - next was to try an initrd - I first tried an initrd with only jfs as a module and the generic kernel - bad idea!! *chuckles* much too much was missing. So, I used the same initrd.gz (with only jfs as a module) _and_ the huge kernel (inspite of the kernel allready having jfs-support). This booted perfectly on my laptop (where I generated the initrd.gz). Then I put my stick into one of my desktops (with two disks) where it almost made it ;-). When I'm saying 'almost' it's because it didn't actually boot, but I got further and it didn't complain about not being able to mount the root filesystem on unknown block ... instead it found my usb-stick with its partitions - and then just hang there - darn it!
I'm not quite sure what the next step will be - it would seem that legacy grub may not be the best to use. I must admit I hate grub2 so I'm not going that route. From the post above, it seems lilo might do it, so I'll try that. Also, syslinux ought to be able to do it as well - heck, most distros use syslinux for their installation.
The reason I started all this *lol* - just got myself a brand new 32-gig usb stick for $18!! I thought it would be just perfect for carrying my own, personal slackware around in my pocket.
Thanks for the links - it would seem that I did not search very well :-(
So, lilo obviously is able to do it, so I guess that will be the way to go.
I don't really like syslinux either - it brings in too much 'gruff' - and lilo always catches me out because I forget to run lilo after a change - which is why I haven't used it for years and years. grub (for me anyway) was always the almost perfect bootloader inasmuch as you could interactively change the way it boots ... which *chuckles* is the way I use the usb-stick at the moment ... letting it boot and fail and paying attention to the device name of my usb-stick - then rebooting and changing to the correct device on the fly. Dirty, yes - but it works.
To me - the problem with an initrd.gz is that it may work well for one machine but not for another - it all depends on the hardware (which is really why I would like to use the huge kernel) I might have screwed up summat with making an initrd only containing jfs (which is allready in the kernel) - guess I better find some module that is _not_ in the huge kernel ..
I always really liked Grub too, but LILO is pretty straightworard and I grew to appreciate it. Reading those links I got a different idea of initrd usage. It sounds like we were thinking the same way in that an initrd is just for when you want to use modules instead of a static kernel but in this case I don't see why you wouldn't just use the huge kernel for hardware support while using the initrd to get the whole thing moving, just grab the .config for the huge kernel, make the changes for the initrd and go from there. I think Eric's way of doing things with syslinux for the usb installer would be more elegant as it seems to just boot and mount the other partition (which is what I experienced recently when I had to go the usb route), but I got lost in the explanations and it seemed that even if it was the long way around, the clear cut instructions for LILO would be easier to follow.
Please do follow up on this, as I intend on attempting this this week as soon as I get paid and can get a good 3.0 flash drive. I don't have much use for a rescue system these days as I'm not in a position to be doing much support anymore, but I do have some friends who I would really like to show Slackware to, and the persistant USB will be a good bit of showmanship I think
Last edited by damgar; 10-01-2012 at 12:45 AM.
Reason: too is to too, but not when it's to
*chuckles* Great minds think alike!! (must be the tx-touch ?!)
Unfortuneately, I'll be away for 3 weeks come Monday - and an awful lot on my plate before that (and no internet while away - *gasp*)
I'll try to get it finished before then, but don't hold me to it ...
And yeah - I'm not doing as much 'support' as I used to - but with the rest of the family using 'that other OS' - you just never know when the proverbial sh?t will hit the fan! I must admit I'm a great fan of 'grml' - that has always been my tool-of-choice - but when push comes to shove, I'd far rather have my very own, persistant slackware ;-)
Keep your fingers crossed for me - I have just generated an initrd.gz with _one_ module - namely 'cpuid'. It was one fairly innocent module I could add (and fyi - the huge kernel does support initrd)
May I ask what procedure you followed to get your Slackware USB Flash Drive install to install & boot?
Can you please give specifics, and if you found a guide or tutorial I'd appreciate the URL.
I've tried installing to a 32G CENTON USB Flash Drive and I can't make it boot. In fact I can't get
Lilo installed either. And I keep getting Kernel Panic Errors.
*big sigh* well now - my latest effort didn't work out too well. I'm not quite sure as to the succession things happen - but inasmuch as having an initrd.gz, it would seem that the initrd does not contain sufficiently to have the root filesystem mounted - it complains about not being able to mount the root filesystem, but nothing like the 'unknown block on device (0,0)'. I'm not sure exactly _when_ initrd is invoked from the booting kernel, but it must be about the time it attempts to mount the root filesystem. It's almost like the booting kernel expects the initrd to supply sufficient information, but this is obviously not happening ... :-(
I'm somewhat surprised that the kernel itself doesn't realize it has got everything it needs ...
So - unless someone (hello Alien Bob!!!) can supply me with some more information, I'm going to give up on it and use my 'cheating ways' - ie booting knowing well that it will fail, but taking a note of of the device name. Then booting again and editing the kernel line in grub to use the correct device name ... at least I _know_ that will work.
I believe I indicated sufficiently in my initial post. You boot up with your slackware-install cd _and_ the usb-stick - making sure (in the bios) that it doesn't try to boot from the usb. Whenever it boots up, you log in as root and you can partition the usb-stick from there (or you can do that through another machine/distro). Then you select your swap and root filesystem on the usb-stick and continue like in any 'normal' install. What I did to install grub is fairly well explained in the first post. Obviously, you can also use the slackware install to install lilo if you so prefer.
Oh - you also have to remember to edit /etc/fstab to use LABEL= or UUID= instead of the device-name(s) - obviously this must be done through another working linux.
Just a li'l *sigh* here ...
I really think that all this should have been solved in the kernel itself - ie. that the kernel would support UUID (or even LABEL) out of the box. It would seem such a logical thing to have ... and even though I'm a hardcore programmer, I'm not gonna play around with the kernel stuff - not enough time/knowledge when others can do it a lot easier ... but heck, I'll be more than willing to use it!! ;-)
Actually, I'm having one more try - with the 2nd link you gave ... only *sigh* it takes forever to compile the friggin' thang (and that's on a dual quad-core blade with 8 gigs of memory and 15000 rpm scsi-disks!)
Well I got paid today, and since the machine that I had been waiting to install 14.0 died the same day 14.0 was release, I have decided to celebrate by attempting this myself. I am currently installing packages to a 32GB USB flash drive, oddly enough off of a 4GB USB installer that I made. I am going to try the syslinux approach although I've found tutorials for LILO as well as GRUB. I will post hopefully tonight after I get this working, or later maybe after I have failed! LOL
GOT IT! Wow that took a LOT of rebooting! lol I wound up just using LILO. The references to /dev/sdb and /dev/sdb2 are immaterial because they are only referencing the configuration of the usb stick when I was actually working on them, such as when lilo is run. Once the configuration is written and lilo is installed in it's final iteration, the UUID is what matters. The sdX bits seemed to be neccessary temporarily.
# LILO configuration file
# generated by 'liloconfig'
# Start LILO global section
boot = /dev/sdb
compact # faster, but won't work on all systems.
# Boot BMP Image.
# Bitmap in BMP format: 640x480x8
bitmap = /boot/slack.bmp
# Menu colors (foreground, background, shadow, highlighted
# foreground, highlighted background, highlighted shadow):
bmp-colors = 255,0,255,0,255,0
# Location of the option table: location x, location y, number of
# columns, lines per column (max 15), "spill" (this is how many
# entries must be in the first column before the next begins to
# be used. We don't specify it here, as there's just one column.
bmp-table = 60,6,1,16
# Timer location x, timer location y, foreground color,
# background color, shadow color.
bmp-timer = 65,27,0,255
# Standard menu.
# Or, you can comment out the bitmap menu above and
# use a boot message with the standard menu:
#message = /boot/boot_message.txt
# Append any additional kernel parameters:
timeout = 50
# Normal VGA console
vga = normal
# End LILO global section
# Linux bootable partition config begins
image = /boot/vmlinuz
label = usb_root
initrd = /boot/initrd.gz
read-only # Partitions should be mounted read-only for checking
# Linux bootable partition config ends
Where /dev/sdb2 and the UUID that's given are both my ext4 / partition. I had to jump through some hoops and actually created the initrd on my installed rc4 system and then just copied them over and ran lilo with something like
lilo -r -v /dev/sdb2 /slack # where /slack is where I temporarily mounted my USB's installation's / and /dev/sdb2 was how the usb partition was numbered at the time I was running the command
EDIT: I am posting this edit as a confirmation. I put my usb installer into the machine and booted to confirm that my persistent USB install was now read as sdc instead of sdb. It booted just fine. It really seems to be a matter of just a few things. Using the right mkinitrd command, using UUID (or presumably LABEL) in lilo and /etc/fstab, editing /boot/initrd-tree/wait-for-root to read 10 instead of 1 and remaking the initrd.
EDIT EDIT: I didn't have to recompile any kernels. The huge kernel, an initrd, and LILO are sufficient to get this done.